Диссертация (1090660), страница 20
Текст из файла (страница 20)
Таким образом, каждоеновое обращение пользователя к серверу создает дополнительные накладные расходы, что может сказаться (и сказывается) на производительности.1214.0.3Анализ динамической платформы FastCGIВ FastCGI [47] решены проблемы предыдущей технологии. Процессы теперь непорождаются при каждом новом соединении, а создаются при запуске Web-сервераи находятся в памяти, ожидая входящих подклюнений. Когда Web-сервер получает новый запрос, требующий динамической обработки, он инициирует соединение спроцессом FastCGI и перенаправляет ему все запрашиваемые данные.
По завершении обработки запроса процесс отправляет данные обратно Web-серверу по тому жесоединению, которое, в свою очередь, отдает их браузеру. Web-сервер закрывает соединение, и процесс FastCGI возвращается в пул, ожидая нового подключения. Такимобразом, технология FastCGI сводит к нулю накладные расходы на порождение новыхпроцессов, улучшая производительность в сравнении с CGI.4.0.4Нагрузочное тестирование динамических платформИмитационные испытания проводятся с целью воспроизведения реальных условий эксплуатации разрабатываемой системы. В контексте рассматриваемой предметной области подразумевается нагрузочное тестирование.
В нашем случае при проведении испытаний выявляется наиболее эффективная динамическая Web-платформа врамках решения поставленной задачи. Предлагается провести два нагрузочных тестирования: со статическим выводом контента и с динамической генерацией. Испытаниябудут проводиться на сервере под управлением FreeBSD 8.2 amd64 со следующими техническими характеристиками: четырехъядерный процессор Intel Xeon E5640 стактовой частотой 2,66 ГГц, объемом ОЗУ 1 Гб и объемом жесткого диска 250 Гб.На испытываемом оборудовании установлен Web-сервер nginx 0.8.54, работающийпо принципу конечного автомата (FSM).
Как и в большинстве Web-серверов, в nginxимеется поддержка CGI и FastCGI. Для проведения дополнительного эксперимента сдинамической генерацией данных на испытуемой машине использовался также интерпретатор скриптового языка PHP 5.3.28. Все тестовые программы, написанные наC/C++, были собраны компилятором gcc/g++ 4.2.1.Для выявления наилучшего решения по выбору Web-платформы мы будем использовать утилиту нагрузочного тестирования Siege [15], имитирующую приток пользователей на сервер. Режимы работы и количество имитируемых пользователей задаются через командную строку при запуске.
Запуск утилиты будет проводиться на той жемашине, где установлен сервер. Это исключит дополнительные расходы, вызываемыезадержкой сети при удаленном взаимодействии с сервером.122В первом испытании будет проведено нагрузочное тестирование сервера, возвращающего статическую страницу в формате HTML фиксированного размера — около16 Кб. Тестирование выявит объем прямых накладных расходов при работе в различных режимах. Статический контент будет отправляться с использованием FastCGI иCGI, а также интерпретатора PHP, исполняемого через модуль Web-сервера Apache.Кроме того, в качестве эталона будет использован реально существующий файлHTML, расположенный на физическом носителе сервера и отправляемый напрямуюWeb-сервером без использования сторонних интерфейсов.
Испытание покажет ростнакладных расходов, возникающих при использовании динамических Web-платформотносительно эталона. Любое кэширование, как на стороне клиента, так и на сторонесервера, будет отключено. Результаты тестирования показаны на рис. 4.1.Производительность, запросы всекундуЗапросы статического содержимого1800160014001200HTML1000800PHP600Static CGI400Static FastCGI2000102050100150Количество пользователейРисунок 4.1. Испытание Web-платформ со статическим содержимымИспытания проводились для различного количества одновременно подключаемыхпользователей от 10 до 150.
Это отражено на диаграмме по оси абсцисс. На осиординат указано максимальное количество потенциальных клиентов, обслуживаемыхза единицу времени, равную одной секунде.Как и ожидалось, статический файл HTML, представляющий собой эталон и передаваемый Web-сервером без подключения посредников, показал максимальный результат. Относительно него показан рост накладных расходов у других технологий.Так, у интерпретатора PHP в данном испытании наилучший результат относительноэталона.
Чуть хуже показала себя технология FastCGI. И наконец, самым тяжелымрешением оказался классический интерфейс CGI. В ходе испытания выяснилось, что123растут накладные расходы не только на порождение новых процессов, но и на количество потребляемой памяти.Испытание показало работу Web-приложений «в идеальных условиях» без какойлибо динамической генерации данных. Из проведенного исследования можно понять,какое количество вычислительных ресурсов требуется при использовании той илииной платформы на «холостом ходу». Однако даже при выполнении этого испытаниявидно, что с увеличением числа запросов технологии PHP и FastCGI сравняются, авпоследствии FastCGI и вовсе обгонит интерпретатор PHP.
Более наглядно это показано в следующем тесте.В ходе второго испытания содержимое страницы будет генерироваться динамически. Для этого был написан специализированный скрипт на языке PHP и три программных модуля на языке C++ для режимов CGI и FastCGI. Для последнего былоосуществлено две реализации: с использованием библиотек fcgi и fastcgi++. Разница в результатах их тестирования оказалась незначительной, поэтому для технологииFastCGI было решено рассматривать только один программный модуль – на основебиблиотеки fcgi. Для обеспечения полноты проведения испытания на вход испытуемых модулей методом GET подавалось пять параметров со случайным набором символов латиницы фиксированной длины в имени параметра, а в значении – случайныечисла.
Над этими параметрами выполнялись примитивные математические и логические операции: сложение, вычитание, запись в массивы. Результаты всех операцийвыводились в браузер. Получаемая страница по объему была сравнима со статическойстраницей из предыдущего испытания. Кроме того, сами параметры, в случае с CGIи FastCGI, необходимо было вручную получить и обработать. Для этого была написана собственная библиотека обработки HTTP-запросов. В ней реализован стандартныйалгоритм конечного автомата.
Результаты тестирования представлены на рис. 4.2.На диаграмме результаты тестирования HTML взяты из предыдущего испытанияи являются также эталоном, хотя и весьма условным. Технология CGI снова показывает крайне низкий результат тестирования. Количество запросов, обрабатываемыхс ее помощью, снизилось примерно в 1,5 раза в сравнении с отдачей статическогосодержимого из предыдущего теста. Однако, несмотря на свою неповоротливость,обработчик CGI выполнил все запросы без единого отказа, тогда как остальные динамические платформы, хоть и пренебрежительно малое количество раз, но все же невыполняли запрос, возвращая ошибку.Примечательна тенденция интерпретатора PHP — при увеличении числа одновременно подключенных пользователей снижается количество обрабатываемых за-124Производительность, запросы всекундуЗапросы динамического содержимого1800160014001200HTML1000800PHP600Dynamic CGI400Dynamic FastCGI2000102050100150Количество пользователейРисунок 4.2.
Испытание Web-платформ с динамическим содержимымпросов. Технология FastCGI показывает относительную стабильность, незначительноснижая показатели. При увеличении числа запросов до 50 платформа FastCGI показала лучшие результаты, нежели интерпретатор PHP. Логично предположить, чторазница между PHP и FastCGI будет пропорционально расти в пользу последнего приувеличении количества исполняемой бизнес-логики, которая в случае с PHP являетсяинтерпретируемой, что значительно замедляет исполнение, требуя дополнительноговремени на разбор исходного кода.В итоге программный модуль интерпретатора языка BML было решено реализовать на базе платформ FastCGI и CGI. Решение об использовании первой очевидно— она показала наилучший результат в испытаниях, причина выбора второй — универсальность технологии, которая могла бы использоваться на тех серверах, где поддержка FastCGI не производится. Технологии разработки для обеих платформ незначительно отличаются друг от друга, вследствие чего поддержка платформы CGI нетребует весомых дополнительных трудозатрат при разработке.1254.1Разработка архитектуры и компонентов программного комплекса интерпретатора4.1.1Построение структурыИнтерпретатор BML – комплексная система, предназначенная для обработки исходного кода языка BML и генерации данных на основе логики, записанной на этомязыке.
Структурная схема в общем виде представлена рис. 4.3.Реализацияработы с сессиейПолучениеданных отWeb-сервераБиблиотекарегулярныхвыражений PCREИнтерфейсобработкиHTTP-запросаОбработчик HTTPИнтерфейсFastCGIЧтение файланастроекЯдроинтерпретатораИнтерфейсобработки XMLБиблиотекаlibxml2ИнтерфейсшаблонизатораМодель данныхИнтерфейсдоступа к базамданныхБиблиотекаmysqlclientШаблонизаторCTPPПередачадокумента вбраузерРисунок 4.3.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
