CC BY
17
УДК 004.422.8
М. В. Рутман, Д. А. Соловьев, А. П. Фалалеев
ООО «Параллелз» ул. Октябрьская магистраль, 4, Новосибирск, 630007, Россия
nsu-mrootman@odin.com, dsolovyev@odin.com, afalaleev@odin.com
КАК ОБЕСПЕЧИТЬ МИНИМАЛЬНОЕ ВРЕМЯ ДОБАВЛЕНИЯ 10 001 ВЕБ-САЙТА
В APACHE *
При обслуживании большого количества сайтов (10 000 и более) кластером сервисных узлов под управлением веб-сервера Apache возникает проблема изменения конфигурации (удаления / добавления / изменения настроек сайтов). Проблема заключается в том, что стандартное конфигурирование Apache с использованием конфигурационного файла, в который занесена информация обо всех обслуживаемых сайтах, является неприемлемым с точки зрения потребления оперативной памяти и времени изменения конфигурации. В статье предлагается решение, основанное на хранении и восстановлении бинарной конфигурационной информации, сгенерированной в оперативной памяти веб-сервера Apache после обработки конфигурационного файла.
Ключевые слова: веб-хостинг, Apache, реконфигурация.
Введение
Предмет рассмотрения данной статьи относится к области веб-хостинга, а именно к системам массового виртуального хостинга под управлением веб-сервера Apache \ Начиная с 1995 г. и до настоящего времени этот сервер является самым популярным HTTP-сервером в Интернете. Ближайшие конкуренты - веб-серверы IIS 2, Nginx 3 уступают как по функциональным характеристикам веб-серверу Apache, так и по распространенности в среде Интер-
4
нет .
Одним из подходов к балансировке загрузки кластера сервисных узлов под управлением веб-сервера Apache является обеспечение исполнения любого веб-сайта на любом из сервисных узлов, обслуживаемых кластером. В этом случае должна быть обеспечена возможность формирования конфигурации веб-сервера Apache на основе объединенной конфигурационной информации всех веб-сайтов, обслуживаемых кластером.
С увеличением количества обслуживаемых виртуальных хостов увеличивается время, затрачиваемое на изменение конфигурации веб-сервера Apache, в течение которого этот сервер становится недоступным для работы. При обслуживании 10 000 и более виртуальных хостов это время возрастает до значения, неприемлемого для пользователей крупных коммерческих сайтов.
* Работа выполнена в ООО «Параллелз» в рамках проекта по договору № 02.G25.31.0054 от 12 февраля 2013 г. с Минобрнауки России.
1 http://ru.wikipedia.org/wiki/Apache (дата обращения 07.04.2015).
2 http://www.microsoft.com/web/platform/server.aspx?templang=ru-ru (дата обращения 07.04.2015).
3 http://nginx.org/ru/ (дата обращения 07.04.2015).
4 http://news.netcraft.com/archives/2014/05/07/may-2014-web-server-survey.html (дата обращения 07.04.2015).
Рутман М. В., Соловьев Д. А., Фалалеев А. П. Как обеспечить минимальное время добавления 10 001 веб-сайта в Apache // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2015. Т. 13, вып. 2. С. 76-85.
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2015. Том 13, выпуск 2 © М. В. Рутман, Д. А. Соловьев, А. П. Фалалеев, 2015
Использование веб-сервера Apache, управляющего большим количеством виртуальных хостов, приводит к снижению производительности сервисного узла вследствие действия следующих факторов:
• изменение (перезагрузка) конфигурации веб-сервера Apache (чтение и обработка конфигурационных файлов) является длительным процессом с потреблением большого объема оперативной памяти;
• в условиях большого количества виртуальных хостов часто возникает необходимость перезагрузки конфигурации веб-сервера, так как модификация конфигурации какого-либо из виртуальных хостов требует перезагрузки всей конфигурации целиком.
В результате действия этих факторов общая нагрузка на веб-сервер значительно возрастает, и использование Apache в классическом виде для 10 000 и более виртуальных хостов становится практически невозможным. Указанный недостаток в наибольшей степени проявляется в случае использования кластера веб-серверов Apache с объединенной конфигурацией.
Одним из известных методов снижения нагрузки на веб-сервер под управлением Apache является метод, основанный на задержке изменения конфигурации виртуальных хостов, накоплении изменений и отложенном их исполнении, что приводит к ухудшению удобства управления веб-сервером и не позволяет сократить потребление им оперативной памяти.
Например, в Parallels Plesk Panel 5 реализована функциональность «Интервал перезагрузки сервера Apache», которая устанавливает минимальный интервал между перезагрузками конфигурации Apache.
Также к известным методам снижения нагрузки на веб-сервер во время изменения конфигурации следует отнести метод, основанный на использовании следующих модулей, поставляемых в составе веб-сервера Apache:
• mod_rewrite 6;
• mod_vhost_alias 7.
Подключение этих модулей к веб-серверу Apache позволяет значительно снизить расход ресурсов сервера, связанных с изменением конфигурации, в случае одинаковой настройки основной массы виртуальных хостов. Особенность метода состоит в параметризации конфигурационной информации на основе имени веб-сайта или его IP-адреса. Конфигурация вебсервера не меняется при добавлении нового виртуального хоста.
Недостатками метода являются ограничение индивидуальности настроек и необходимость разделения протокола исполнения запросов по разным сайтам (фактически протокол ведется для одного сайта, конфигурация которого является общей для хостов с одинаковыми настройками).
Решение, предлагаемое авторами данной статьи, заключается в создании нового способа хранения и модификации конфигурации веб-сервера Apache (включая объединенную конфигурацию кластера веб-серверов Apache). Данный способ приводит к уменьшению времени изменения конфигурации веб-сервера Apache и уменьшению потребления оперативной памяти сервера.
Наибольший эффект экономии ресурсов сервера наблюдается при наличии большого количества малоактивных сайтов, размещенных в виртуальных хостах под управлением Apache. Такой результат достигается принципиальным изменением схемы работы с конфигурационной информацией веб-сервера Apache. Схема работы, предлагаемая в данной статье, основана на использовании бинарной конфигурационной информации, сгенерированной в оперативной памяти веб-сервера после анализа конфигурационного файла.
Схема работы с конфигурационной информацией веб-сервера Apache
Предлагаемая схема позволяет увеличить количество виртуальных хостов, обслуживаемых веб-сервером, и улучшить функциональные характеристики веб-сервера Apache:
5 http://www.odin.com/products/plesk/ (дата обращения 07.04.2015)
6 http://httpd.apache.org/docs/2.4/rewrite/vhosts.html (дата обращения 07.04.2015).
7 http://httpd.apache.org/docs/2.4/mod/mod_vhost_alias.html (дата обращения 07.04.2015).
Управляющий узел
http/https запросы
Рис. 1. Структурная схема кластера веб-серверов Apache
• уменьшить потребление оперативной памяти;
• уменьшить потребление процессорных ресурсов при изменении конфигурации;
• сократить длительность изменения конфигурации (не зависит от количества обслуживаемых виртуальных хостов);
• выполнять операции изменения конфигурации веб-сервера без прерывания обслуживания http/https-запросов пользователей.
Предлагаемое решение реализуется путем создания подключаемых модулей Apache, которые меняют схему работы с конфигурацией веб-сервера Apache принципиальным образом: вместо ресурсоемкой и длительной операции анализа и обработки текстового конфигурационного файла выполняется чтение из внешнего хранилища бинарной конфигурационной информации и занесение ее в оперативную память веб-сервера. При этом код веб-сервера Apache остается неизменным.
Решение основано на использовании бинарной конфигурационной информации, сгенерированной в оперативной памяти веб-сервера после анализа конфигурационного файла. Конфигурационная информация переносится из оперативной памяти веб-сервера во внешнее хранилище «ключ-значение» с целью изолированного хранения, изменения и восстановления конфигурационной информации каждого виртуального хоста.
Таким образом, изменяется процесс обработки конфигурационной информации - вводится дополнительный шаг обработки информации. Вместо операции
файл ^ память Apache
выполняется операция
файл ^ хранилище ^ память Apache.
Предлагаемая схема позволяет:
• оптимизировать изменение конфигурации на этапе «хранилище ^ память Apache», так как изменение информации в хранилище работает намного быстрее, чем изменение конфигурационной информации в Apache;
• оптимизировать рабочий цикл веб-сервера Apache по обслуживанию http/https-запро-сов пользователей, так как трудоемкая процедура изменения конфигурации выносится в отдельный независимый цикл функционирования веб-сервера;
• оптимизировать изменение конфигурации на этапе «файл ^ хранилище», так как каждый виртуальный хост хранится в виде отдельной записи во внешнем хранилище, которое предоставляет быстрые атомарные операции по получению и изменению хранимых записей (а не в виде одного общего конфигурационного файла для всех виртуальных хостов при классическом использовании веб-сервера Apache);
• оптимизировать скорость обработки http/https-запросов пользователей, так как внешнее хранилище предоставляет быстрые атомарные операции по поиску и выдаче хранимых записей конфигурационных данных виртуальных хостов по ключу;
• оптимизировать потребление памяти благодаря процедуре автоматической дефрагмен-тации используемой памяти при сохранении конфигурации в хранилище.
Для централизованного хранения конфигурационной информации предлагается использовать быстрое хранилище «ключ-значение», например, NoSQL базу данных Redis 8.
В момент обращения к виртуальному хосту под управлением Apache конфигурационная информация, относящаяся к данному виртуальному хосту, извлекается из хранилища и заносится в оперативную память веб-сервера. Конфигурационная информация неактивных виртуальных хостов не заносится в оперативную память.
Предлагаемое решение может быть применено в рамках кластера веб-серверов Apache с единой конфигурационной информацией (рис. 1), что позволяет балансировать загрузку узлов кластера путем перенаправления трафика виртуального хоста на любой из узлов кластера с обеспечением синхронизации конфигурационной информации на узлах кластера средствами репликации NoSQL базы данных Redis. Для обеспечения синхронизации в кластере на каждом узле расположена своя локальная база данных Redis, одна из которых (Master) работает и на чтение, и на запись, а остальные (Slave) - реплицируют данные базы Master и предоставляют локальную базу данных для каждого узла, доступную только на чтение.
Описание экспериментальной реализации предлагаемого решения
Для решения задачи хранения и модификации бинарной конфигурационной информации необходимо знать формат структур данных, размещенных в оперативной памяти после анализа конфигурационного файла веб-сервером.
Каждый модуль веб-сервера Apache самостоятельно решает, в виде какой структуры ему хранить свою конфигурацию, т. е. не существует стандартного формата конфигурационных данных любого модуля. Для самого веб-сервера модуль предоставляет лишь набор функций по манипулированию его конфигурацией.
Модули написаны на языке C, это приводит к отсутствию в коде модуля метаинформации о структуре данных, хранимых в оперативной памяти.
После обработки конфигурационного файла веб-сервером в оперативной памяти хранятся только указатели на тип void, за которыми скрываются цепочки участков памяти, имеющие ссылки между собой (рис. 2).
8 http://redis.io/ (дата обращения 07.04.2015).
Рис. 2. Схематичная разметка оперативной памяти, отведенной модулями Apache для хранения конфигурационной информации
На рис. 2 представлена общая схема разметки памяти, сгенерированной компилятором на основе исходного кода модуля веб-сервера Apache на языке программирования C. Из приведенной схемы видно, что в оперативной памяти хранятся только сами данные и полностью отсутствует какая-либо метаинформация, описывающая взаимные связи между отдельными участками памяти.
Предлагается перехватывать обращения веб-сервера к функциям распределения памяти (malloc / realloc / free / apr_palloc) для получения информации о размере выделенного / освобожденного участка памяти.
Для решения задачи анализа структуры управляющих данных предлагается использовать извлечение информации о структуре данных из отладочной информации модулей.
Исполняемый код веб-сервера и подключаемых модулей необходимо собрать с включенной генерацией отладочной информации. Отладочная информация содержит полное описание структур, полученное после обработки всех макросов, применения всех дополнительных атрибутов по выравниванию данных (pragma pack, attribute_((aligned)) и проч.). Эти описания будут использованы в качестве метаинформации для анализа структур данных модулей.
Для извлечения отладочной информации предлагается использовать библиотеки, развиваемые в рамках проекта LLVM 9.
Для подтверждения целесообразности предлагаемого решения задачи хранения и модификации бинарной конфигурационной информации была выполнена экспериментальная реализация следующих модулей, подключаемых к веб-серверу Apache:
moddetectcfg - модуль генерации вспомогательной информации (список возможных структур, правила выбора структур), необходимой для анализа конфигурационных данных, расположенных в оперативной памяти веб-сервера после обработки конфигурационного файла;
mod_bundle_cfg - модуль анализа конфигурационных данных, расположенных в оперативной памяти веб-сервера после обработки конфигурационного файла, последующей сериа-лизации (упаковки) конфигурационных данных и занесения упакованной информации в базу данных Redis;
9 http://ru.wikipedia.org/wiki/Low_Level_Virtual_Machine (дата обращения 07.04.2015).
mod_unbundle_cfg - модуль извлечения конфигурационной информации из базы данных Redis, десериализации (распаковки) конфигурационных данных и простановки ссылок на объекты в оперативной памяти веб-сервера (дескрипторы файлов, указатели на статические переменные и функции).
Процесс функционирования описываемого способа хранения и модификации бинарной конфигурационной информации можно разделить на 3 этапа.
1. Предварительный этап - генерация вспомогательной информации путем анализа отладочной информации модулей веб-сервера Apache.
2. Генерация конфигурационной информации веб-сервера Apache в оперативной памяти, ее анализ с помощью вспомогательной информации, полученной на предварительном этапе, упаковка и занесение в базу данных Redis.
3. Восстановление конфигурационной информации веб-сервера Apache в оперативной памяти из базы данных Redis.
Этап 1 - генерация вспомогательной информации. Предварительный этап (рис. 3, 4) - генерация вспомогательной информации (набора возможных структур для помощи в процессе сериализации (упаковки) конфигурационных данных модулей). Осуществляется при переходе на новую версию веб-сервера Apache или добавлении нового модуля.
Как правило, эти действия выполняются только при настройке веб-сервера. В дальнейшей работе веб-сервера (добавлении, удалении, изменении конфигурации) выполнение этих действий не требуется. Для исполнения этого этапа собирается код ядра веб-сервера Apache и его модулей с отладочной информацией. Набор возможных структур модуля извлекается из отладочной информации специальной утилитой, реализованной на базе библиотек из LLVM, и сохраняется в файле в бинарном формате. Управление утилитой осуществляется модулем mod_detect_cfg.
Результаты обработки отладочной информации помещаются в три набора файлов (по именам модулей и типу конфигурации Server/Directory):
1) <имя_модуля>.dwp - список первоначальных структур модуля в бинарном формате;
2) <имя_модуля>_<тип_конфигурации>.г^ - список правил выбора для модуля;
3) <имя_модуля>_<тип_конфигурации>.dwp - список возможных структур модуля с дополнительной информацией.
На каждый м^уль создается отдельный файл со структурами, которые могут использоваться WQflVtW ДйЧ »ранения конфигурационных да инь ;■:
Нзоор файлов ссписаьием
итоговых структур кои фигурацион ны л да hhbiK (эти файлы войд/те поставляемый продлит!
Правила выбора структур (им можно использовать np*i üípíwaí на нору в sípíwn Apacnel вкодят g состав продукта
Рис. 3. Определение структур конфигурационных данных модулей на этапе подготовки вспомогательной информации
- Начальный указатель
- Набор возможных структур
- Набор правил выбора
Получить размер участка памяти
Список возможных правил выбора
Сформировать наборы правил выбора структур
Выбрать структуру
Структуры кончились Анализ полученных структур
Найти в правилах структуру с учетом относительного и полного путей
Анализ указателя:
-Указывает на структуру? -Имеется набор правил?
)
Анализ элементов структуры
_)
Анализ элемента 'enum' noj " Анализ указателя на
f Анализ структуры 1
Рис. 4. Алгоритм работы модуля mod_detect_cfg
Этап 2 - генерация конфигурационной информации веб-сервера Apache в оперативной памяти, ее анализ, упаковка и занесение в базу данных Redis. Этот этап запускается при добавлении новых виртуальных хостов. Для нового хоста выполняются следующие действия:
• создается набор текстовых конфигурационных файлов;
• запускается веб-сервер Apache, включающий специальный модуль mod_bundle_cfg для обработки этого набора;
• модуль mod_bundle_cfg сериализует (упаковывает) бинарные конфигурационные данные нового виртуального хоста, размещенные в оперативной памяти;
• подготовленные таким образом бинарные конфигурационные данные заносятся в базу данных Redis.
Анализ конфигурационной информации, расположенной в оперативной памяти вебсервера Apache, выполняется с помощью вспомогательной информации, полученной на первом этапе, а именно: для анализа данных каждого модуля используется файл <имя_модуля>_<тип_конфигурации>.dwp (список возможных структур модуля с дополнительной информацией), сгенерированный на первом этапе.
Сериализованная структура конфигурационных данных нового виртуального хоста сохраняется в базе данных Redis в бинарном формате. Состоит из следующих частей.
• Собранные в единый большой блок все цепочки участков памяти (см. рис. 2). Удалена вся лишняя и неиспользуемая информация.
• Набор операций, которые нужно совершить над этим блоком (инициализация значений):
^ динамических указателей; ^ статических указателей;
^ файлов (смещение, имя файла, флаги открытия);
^ mutex (mutual exclusion lock file - файл блокировки взаимного исключения) - смещение;
^ server_rec (начальная структура, в которой хранится конфигурация виртуального хоста) - смещение;
^ apr_pool_t (область памяти, созданная Apache для обработки запроса) - смещение.
• Набор упакованных конфигурационных данных модулей, сопровождаемых флагами, отображающими наличие различных типов конфигураций, которые существуют у модуля в сериализованной структуре. Наличие флагов необходимо для случая, когда в сериализо-ванной структуре указано, что у модуля существует тип конфигурации «Server», но отсутствует тип конфигурации «Directory», тогда как в действительности на хосте обнаруживается, что тип конфигурации «Directory» у модуля существует. В этом случае тип конфигурации «Server» модуля будет взят из сериализованной структуры, а тип конфигурации «Directory» будет взят с хоста.
• Конфигурация виртуального хоста. Здесь хранится идентификатор хоста, тип конфигурации, местоположение в структуре конфигурации, смещение начального указателя в упакованных цепочках памяти.
Этап 3 - восстановление конфигурационной информации веб-сервера Apache в оперативной памяти из базы данных Redis. Эта операция выполняется в автоматическом режиме. При получении http/https-запроса пользователя к нужному виртуальному хосту веб-сервер Apache запускает дополнительный модуль mod_unbundle_cfg, формирующий в оперативной памяти веб-сервера бинарную конфигурационную информацию виртуального хоста из базы данных Redis в следующей последовательности.
1. Из базы данных Redis считывается сериализованная (упакованная) запись «server_rec» (структура, в которой хранится вся бинарная конфигурационная информация виртуального хоста) в буфер запроса apr_pool_t (динамически выделяемый веб-сервером блок памяти).
2. В этом буфере выполняются следующие действия:
^ установка новых значений указателей, использующих адрес начала блока и смещения внутри блока;
^ подстановка значений из поля http/https-запроса (*request).pool вместо указателей на apr_pool_t;
^ подстановка значений указателей с учетом базового адреса загружаемых библиотек вместо указателей на статические переменные и функции;
^ установка нового значения поля http/https-запроса (*request). server (выполняется в случае исполнения на кластере веб-серверов - см. рис. 1).
По завершении обработки http/https-запроса область памяти apr_pool_t, содержащая сформированную бинарную конфигурационную информацию виртуального хоста, освобождается.
Эксперименты и результаты
Для обоснования вышеописанного технического решения была выполнена экспериментальная реализация модулей mod_detect_cfg, mod_bundle_cfg, mod_unbundle_cfg для вебсервера Apache и проведено тестирование потребления оперативной памяти веб-сервером Apache и модулем mod_unbundle_cfg для конфигурации из 1 000 обслуживаемых сайтов, в каждый из которых включено 48 модулей.
Для проверки эффективности предложенного решения было проведено экспериментальное тестирование на оборудовании с конфигурацией:
• процессор CPU Intel Core í7-960, 3.20 ГГц;
• оперативная память RAM 2 Гб;
• дисковая память HDD 500 Гб, 7200 об./мин.
Тестирование проводилось на OS Linux CentOS 6.5 x86_64 (64-битный вариант). Все пакеты 64-битные и ставились из стандартного репозитория):
• веб-сервер Apache 2.2.15;
• модуль Apache с поддержкой языка PHP 5.3.3;
• модуль Apache с поддержкой языка Python - mod_python 3.3.1;
• модуль Apache с поддержкой языка Perl - mod_perl 2.0.4;
• NoSQL база данных сервер Redis 2.6.13 - база данных, которая используется для хранения конфигураций сайтов;
• модуль Apache для генерации конфигурационной информации;
• модуль mod_unbundle_cfg - экспериментальная реализация.
Возможные конфигурации сайтов Apache:
1) SCRIPT OFF - отключены модули с поддержкой скриптовых языков (mod_perl OFF, mod_python OFF, mod_php OFF);
2) SCRIPT ON - включены модули с поддержкой скриптовых языков (mod_perl ON, mod_python ON, mod_php ON).
При сохранении конфигурации в базе данных включалось и выключалось обрезание участков памяти, которые оставались после прочтения конфигурации из файлов Apache и не использовались в работе:
• FULLMEM - все участки памяти упаковывались;
• SHRINKMEM - участки памяти, не используемые в работе, не упаковывались.
В базе данных сохранялись конфигурации всех модулей Apache, т. е. дополнительная возможность по оптимизации потребления памяти, которая заключается в вынесении общей конфигурации всех сайтов на сервисные узлы, не была задействована в связи с тем, что модулей 48 и необходимо было собрать статистику по всевозможным комбинациям, так как в каждом отдельном случае мог быть применен свой вариант.
В табл. 1 приведены объемы потребления оперативной памяти веб-сервером Apache в стандартной конфигурации (второй столбец) и в конфигурации с использованием модулей экспериментальной реализации (третий и четвертый столбцы).
Данные, представленные в таблице, показывают, что на конфигурации в 1 000 сайтов в режиме SCRIPT ON, SHRINKMEM потребление памяти в конфигурации с использованием модулей экспериментальной реализации уменьшилось в 4,9 раза (199,892 / 40,512 = 4,9).
С увеличением количества сайтов соотношение будет улучшаться, поскольку 15 мегабайт из 40 заняты базовой конфигурацией Apache и базой данных Redis.
Далее измерялась длительность выполняемых операций. В рамках предлагаемого решения нам важны два параметра:
• длительность инициализации Apache - это интервал времени, в течение которого вебсервер Apache разбирает свой конфигурационный файл. При классическом использовании всё множество сайтов хранится в едином конфигурационном файле и для изменения конфигурации одного из сайтов веб-серверу Apache необходимо проанализировать весь конфигурационный файл;
• длительность обработки http/https-запроса от пользователя. Данная характеристика важна, поскольку в случае использования модуля mod_unbundle_cfg конфигурация сайта формируется из базы данных Redis на каждый http/https-запрос пользователя.
В табл. 2 представлены результаты измерения длительности выполняемых операций для двух возможных вариантов:
• Apache - стандартный Apache с конфигурационным файлом на 1 000 сайтов;
• Redis + Apache + mod_unbundle_cfg - экспериментальная реализация (Apache с подключенным модулем mod_unbundle_cfg и конфигурацией на 1 000 сайтов, сохраненной в базе данных Redis).
Как видно из табл. 2, время инициализации для варианта экспериментальной реализации резко уменьшилось, из чего можно сделать вывод об успешном решении задачи сокращения времени изменения конфигурации веб-сервера Apache.
Таблица 1
Потребление памяти на конфигурации в 1 000 сайтов, Мб
Режимы функциони- Apache Redis + Apache + mod unbundle cfg
рования FULLMEM SHRINKMEM
SCRIPT OFF 79,464 35,488 28,160
SCRIPT ON 199,892 71,833 40,512
Таблица 2
Длительность операций для конфигурации на 1 000 сайтов, с
Варианты использования Apache Инициализация Apache Обработка 100 000 http/https-запросов
Apache 95 624
Redis + Apache + mod unbundle cfg < 1 627
В то же время разница между длительностями обработки http/https-запросов от пользователя для двух вариантов (стандартного и экспериментального) меньше 1 %, что можно отнести к статистической погрешности. Исходя из представленных результатов, можно сделать вывод, что для экспериментального варианта изменение конфигурации сайта на каждый http/https-запрос пользователя не добавляет существенных накладных расходов.
Заключение
В статье предложен новый способ изменения конфигурации веб-сервера Apache, основанный на хранении и восстановлении бинарной конфигурационной информации.
Для обеспечения решения задачи хранения и модификации бинарной конфигурационной информации была выполнена экспериментальная реализация дополнительных модулей, подключаемых к веб-серверу Apache (mod_detect_cfg, mod_bundle_cfg, mod_unbundle_cfg).
Экспериментально показано, что предлагаемый способ позволяет значительно сократить время выполнения и уменьшить потребление памяти в процессе изменения конфигурации веб-сервера Apache.
Материал поступил в редколлегию 20.04.2015
M. V. Rootman, D. A. Solovyev, A. P. Falaleev
Parallels Ltd
4, Oktyabr'skaya magistral', Novosibirsk, 630007, Russian Federation nsu-mrootman@odin.com, dsolovyev@odin.com, afalaleev@odin.com
HOW TO ENSURE A MINIMUM TIME OF ADDING 10,001 WEB SITES
IN APACHE
The article deals with a new method of changing the configuration web server Apache, based on the storage and recovery of the binary configuration information. It is experimentally shown that the proposed method can significantly reduce the execution time and reduce memory consumption in the process of changing the configuration of the web server Apache.
Keywords: web hosting, Apache, reconfiguration.
