Сетевая плата. Сервер должен обеспечивать надежное сетевое соединение с десятками и сотнями пользователей. Нельзя сказать, что дорогие сетевые платы, рекламируемые производителями как "специальные серверные решения", будут работать заметно быстрее обычных сетевых плат, установленных на клиентах Сложно утверждать конкретно, в чем они надежнее обычных сетевых плат. В этой области рынка аппаратною обеспечения слишком много рекламного тумана, в котором спрятаны реальные преимущества серверных сетевых плат. Собственно, почти во всех случаях достаточно будет поставить на сервер, выделенный под InterBase, обыкновенную качественную сетевую плату - возможно, ту же, которая применяется на клиентах.

В настоящее время стандартом для корпоративных и офисных сетей является 100-Мбит Ethernet-сеть, основанная на витой паре (100Base-T). Она обеспечивает пропускную способность 3-10 Мбайт/с. 100-Мбит сеть достаточна для большинства клиент/серверных-приложений, в том числе и для приложений, использующих InterBase.

Обычно для организации сетевого общения InterBase и клиентов используется протокол TCP/IP, который является наиболее универсальным и масштабируемым сетевым протоколом. Практически все примеры в книге основываются на применении протокола TCP, хотя InterBase позволяет связываться и по протоколам Named Pipes и IPX.

Надо сказать, что неустойчиво работающая сеть, в которой часто теряются пакеты, является причиной возникновения ошибок InterBase 10054, загромождающих файл протокола InterBase.log. Поэтому, хотя вопросы настройки и обслуживания сети выходят за рамки данной книги, необходимо обратить особое внимание на обеспечение работы сети.

Требования к компьютерам-рабочим станциям, на которых исполняются клиентские части приложений базы данных на базе InterBase, определяются в основном требованиями ОС. Клиентская часть приложения базы данных InterBase не требует большего, чем обычные офисные программы. Клиентская же часть самого InterBase весьма легковесна, не требует много ресурсов и состоит всего из трех файлов (см. ниже главу "Состав модулей InterBase"). Можно с уверенностью сказать, что большинству приложений баз данных InterBase будет более чем достаточно для выполнения компьютера офисного класса - например, Celeron с 256 Мбайт ОЗУ. Нижним пределом (для небольшого клиентского приложения) является компьютер класса Pentium-100 с 16 Мбайт ОЗУ.

Сначала мы рассмотрим те параметры настройки InterBase, которые часто изменяют для настройки производительности InterBase. Рекомендации по улучшению производительности не только затрагивают те параметры, которые есть в конфигурационном файле ibconfig, но также рассматривают различные аспекты разработки программного обеспечения. Желающие разобраться во всех параметрах конфигурационного файла ibconfig могут обратиться к справочному материалу в приложении "Параметры конфигурационного файла InterBase".

Кеш базы данных служит для хранения наиболее часто используемых страниц из базы данных. Его размер исчисляется в страницах и может быть установлен тремя разными способами:

* Заданием параметра файла конфигурации ibconfig DATABASE CASHE PAGES. При этом устанавливается значение кеша для каждой базы данных, обслуживаемой данным сервером; это означает, что для каждой подключенной базы данных будет распределен кеш указанного в данном параметре размера. Это не слишком гибкий способ, поэтому им обычно не пользуются, если компьютер-сервер обслуживает более одной базы данных. Этот параметр имеет следующие значения по умолчанию: InterBase 6 Classic (Linux) - 75, InterBase 6 SuperServer (Windows) - 2048, a InterBase 5.x - 256. Причем надо отметить, что для Classic устанавливается размер кеша для КАЖДОГО клиентского соединения.

* Установкой количества страниц для каждой индивидуальной базы данных с помощью инструмента gfix. Например, выполнение команды gfix -buffers 8192 для какой-либо базы данных приводит к тому, что все соединения к этой базе данных будут использовать кеш размером 8192 страницы. Помните, что версия Classic использует значение размера кеша для каждого клиентского соединения; поэтому не стоит устанавливать размер кеша в Classic более 2048 страниц (даже если у вас несколько гигабайтов ОЗУ). Необходимо отметить, что при создании базы данных задать размер кеша на уровне базы данных невозможно, - он устанавливается позже с помощью gfix.

* Установкой параметра функции InterBase API isc_dpb_num_buffers при соединении с базой данных.

Перечисленные способы установки идут в порядке возрастания приоритета, т. е. значения последних вариантов на практике надо использоваться в первую очередь. Тем не менее известный разработчик InterBase Ivan Prenosil вносит поправки в это утверждение, считая, что установка кеша на уровне базы данных имеет наивысший приоритет и не может быть переопределена даже на уровне соединения.

Теперь о конкретных цифрах. Размер кеша может принимать значения от 50 до 65535 страниц. Чтобы посчитать, как много оперативной памяти потребует кеш базы данных, надо умножить размер страницы базы данных на размер кеша. Например, если страница имеет размер 8192 байта, а кеш имеет размер 5000 страниц, то потребуется 40960000 байт ОЗУ (около 40 Мбайт), чтобы вместить этот кеш. Несмотря на то что сейчас ОЗУ стоит достаточно дешево и экономить на нем не стоит, устанавливать размер кеша базы данных более 10000 страниц не следует, это вытекает из тестов, которые показывают уменьшение производительности InterBase при большом размере кеша. Помимо тестов, с результатами которых вы можете познакомиться на сайте www.ibase.ru. Ivan Prenosil указывает на малоизвестный факт: большой размер кеша заметно увеличивает время соединения с базой данной, и чем больше кеш, тем больше времени затрачивается на установку соединения. Правда, в Yaffil эта проблема решена.

Forced Writes - это режим записи данных на диск. Существует два режима - синхронный и асинхронный, которым соответствуют значения Forced Writes ON и OFF. При асинхронном режиме записи данных на диск (т. е. при FW OFF) данные пишутся в файловый кеш ОС, в результате чего ускоряются операции с ке- шированными данными. При синхронном режиме (FW ON) процесс, который изменяет данные, ожидает, пока они пишутся на диск, это позволяет помещать данные на диск гораздо надежнее, чем при асинхронной записи. Правда, стоит отметить, что обращения к диску производятся не после изменения каждой записи (это бы катастрофически снизило производительность), а в следующих случаях: