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

Откомпилированные программы работают быстрее интерпретируемых сценариев.

Скорость выполнения у интерпретируемых языков, используемых в Web-контексте, выше, когда интерпретатор вызывается как модуль, являющийся частью самого Web-сервера, а не отдельным процессом.

Сравнение компилируемых и интерпретируемых языков

с большой долей вероятности можно сказать, что скомпилированные программы более эффективны: они потребляют меньше памяти и выполняются быстрее, чем их аналоги, созданные на языках написания сценариев. Это происходит из-за повышенных накладных расходов, которые требуются для работы интерпретатора. Язык С является языком компилируемого типа, а языки Perl и РНР являются языками интерпретируемого типа, поэтому программы, написанные на языке С, обычно работают быстрее сценариев, написанных на языке Perl и РНР.

Для программ, которые будут активно использоваться, лучше всего подойдет язык С. Хорошим примером этого может служить программа-клиент mysql, работающая с командной строкой.

Имеют место и факторы, которые могут сгладить эти различия. Написание программ на С позволяет получить более быстрые программы, но существует вероятность, что написанная программа будет неэффективной. Написание программы с помощью компилируемого языка программирования само по себе не является полной гарантией более высокой производительности. По-прежнему нужно думать о том, что вы делаете. Кроме того, различие между скомпилированными и интерпретируемыми программами уменьшается, если приложение проводит большую часть времени, выполняя код из библиотеки клиента СУБД MySQL, которая подключена к механизму интерпретатора.

Сравнение характеристик автономной и модульной версии интерпретаторов языка

в Web-приложениях интерпретаторы языков написания сценариев используются в двух формах. Это справедливо и для Web-сервера Apache, который будет использоваться нами при написании Web-приложений.

Web-сервер имеет соответствующие настройки для вызова интерпретатора как отдельного процесса. Когда Apache необходимо запустить какой-нибудь сценарий РНР или Perl, он запускает соответствующую программу и передает ей этот сценарий на выполнение. В этом случае, Web-сервер Apache взаимодействует с интерпретаторами как CGl-профаммами, т.е. он осуществляет с ними обмен данными по протоколу Common Gateway Interface (CGI) .

Интерпретатор может быть и модулем, непосредственно подключенным к двоичному коду Apache, работающим как часть процесса Apache. В терминах сервера Apache интерпретаторы Perl и РНР являются модулями mod perlH mod php3.

Сторонники Perl и РНР мог>т спорить относительно преимуществ в скорости их любимого интерпретатора, но с тем, что форма работы интерпретатора является более важным фактором, существенно влияющим на производительность, согласятся все. Очевидно, что любой интерпретатор работает значительно быстрее в модульном режиме, чем в виде автономного CGI-приложения.

В автономных приложениях необходимо запускать интерпретатор всякий раз, когда на выполнение приходит сценарий. Таким образом вносится определенная лепта в перегрузку системы и повышается штраф на запуск интерпретатора. В модульной системе интерпретатор работает как часть уже работающего процесса сервера Apache, и возможности интерпретатора для Web-страниц будут доступны постоянно. Это существенно увеличивает производительность системы, снизит ее персфузку и прямо отразится на возросшей возможности обрабатывать входящие запросы и на скорости отклика сервера.

Штраф на запуск автономного интерпретатора примерно на порядок снижает производительность по сравнению с модульной формой работы интерпретатора. Цена запуска интерпретатора сыфает офомную роль, если предпочтение будет отдаваться обслуживанию бысфых транзакций в совокупности с незначительными вычислениями, а не медленных с большим процентом обработки. Результатом того, что большая часть времени тратится на запуск интерпретатора, а не на выполнение сценария, будет бесполезная расфата ресурсов. Это аналогично ситуации, при которой работник проводит большую часть дня в подготовке к работе, приходит на работу в 4 часа дня и уходит домой в 5 часов.

Возможно, у вас появится вопрос, о какой экономии может идти речь, если по-прежнему требуется запускать Web-сервер Apache. А причина проста - в момент запуска Apache автоматически создает пул порождаемых процессов, который будет в дальнейшем использован для обработки входящих запросов. Всякий вновь прибывший запрос, фебую-щий обработки сценария, уже ожидает свой Apache-процесс. Конечно, каждый новый экземпляр сервисов сервера Apache умножает количество запросов, таким образом цена запуска процесса может приниматься во внимание только для фуппы запросов, а не для одного запроса.

Какой из языков будет лучше работать в модульной форме (modperl и mod php3)? Это и по сей день является предметом споров, но можно остановиться на таких принципиальных моментах.

Язык Perl компилирует сценарий во внутренний скомпилированный формат, язык РНР - нет. Таким образом, если сравнивать однажды скомпилированный сценарий, то Perl всегда будет быстрее, особенно, если этот сценарий содержит циклы с большим количеством итераций.

Модуль modperl производит кэширование сценариев, которые часто вызываются. Это также является фактором ускорения обработки процессов. Выполнение сценария, который уже находится в кэше, начнется значительно быстрее потому, что не требует синтаксического анализа. Однако язык РНР быстрее запускает выполнение сценария.

Для работы модуля mod perl потребуется больше памяти, чем для работы модуля mod php3. Процессы, создаваемые сервером Apache для модуля modperl, имеют больший объем, чем процессы, необходимые модулю mod php3. Это кроется в идеологии создания языка РНР как такового, который должен взаимодействовать с по-рождаюшим процессом и может быть активизирован и остановлен этим процессом несколько раз. В это же время, язык Perl был разработан как такой, который должен запускаться из командной строки как автономная программа, а не как язык, заключенный в процесс Web-сервера. Вероятно, в этом и кроется причина увеличенного потребления памяти, ведь в модульном режиме Perl не работает в своей естественной среде. Другим факторами, влияюшими на увеличенное потребление памяти, является кэширование сценария и наличие дополнительных модулей Perl, которые он использует в своей работе. В обоих случаях программного кода на протяжении всего жизненного цикла процесса Web-сервера Apache в памяти сохраняется значительно больше.

Но эти преимущества языка Perl над РНР в скорости выполнения сценариев сводятся на нет в новой версии РНР 4. РНР 4 подобен РНР 3 по возможностям и интерфейсу, но в нем используется высокопроизводительный механизм интерпретации Zend.

В любом случае, все эти факторы в результате дают разницу в производительности между модульными версиями языков Perl и РНР, которую можно выразить в процентах. По возможности лучше избегать автономных интерпретаторов для любого языка написания сценариев.

Автономная версия интерпретатора имеет одно преимущество над модульным вариантом: ее можно настроить для работы под различными идентификаторами пользователей. Модульные версии работают всегда под тем же пользователем, что и Web-сервер, который в целях безопасности всегда имеет минимальные привилегии. Это составляет определен-