Сравнение РНР как интерпретатора CGI и как модуля Apache

Сравнение РНР как интерпретатора CGI и как модуля Apache

Как было сказано выше, РНР можно компилировать 

• в виде самостоятельного интерпретатора CGI
• как модуль Apache.

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

Если  РНР скомпилирован как модуль Apache (рис. 2.1), он выполняется в адресном пространстве процесса самого веб-сервера, благодаря чему обеспечивается заметное увеличение производительности по сравнению с обычными интерпретаторами CGI, являющимися самостоятельными процессами.

Некоторые функции, такие как постоянные соединения с базами данных (persistent database connections), доступны только в версии модуля Apache.

Программирование в среде Web. Зачем нужно использовать РНР?

Теперь, когда мы знаем, как устанавливать РНР, стоит  задаться вопросом, для чего вообще нужен РНР. Можно было бы ограничиться HTML - в конце концов, это старый испытанный метод создания веб-страниц. Почему необходимы «динамические» веб-страницы? Значительно проще овладеть в совершенстве HTML, чем изучать совершенно новую технологию.

Недостатки HTML

Содержание  многих веб-сайтов статическое, например научные статьи. Страницы на этих сайтах являются документами, состоящими из простого текста, изображений и гиперссылок на другие документы. Для сайтов такого типа обычно достаточно простых технологий на стороне клиента. HTML и каскадные таблицы стилей (CSS) предоставляют средства структурирования и представления содержимого страницы, а с помощью JavaScript при желании можно несколько оживить ее.

Однако Интернет и интранет все в большей степени используются для приложений, и большинство из них включает в себя базы данных. Эти сайты и приложения являются динамическими, поскольку их содержание меняется в зависимости от участвующих в них данных и действий пользователя. Именно здесь вступает в игру РНР. Благодаря запуску на сервере программ РНР можно создавать очень мощные приложения, взаимодействующие с базами данных и динамически создающие содержание.

Главное различие между страницами РНР и страницами HTML состоит в том, как с ними работает веб-сервер.

 

Что происходит со страницами HTML?

Когда от броузера поступает запрос страницы, веб-сервер делает следующие три шага:

• читает запрос от броузера;

• находит страницу на сервере;

• посылает страницу обратно броузеру через Интернет или интранет.

Что происходит со страницами РНР?

С помощью  РНР добавляется еще один шаг. Вместо того чтобы отослать пользователю статическую страницу HTML, мы потребуем от сервера выполнить некоторые действия в соответствии с нашим кодом РНР:

РНР примет некоторые решения и создаст страницу, соответствующую конкретной ситуации. Поэтому при использовании РНР сервер действует следующим образом:

• читает запрос от броузера;
• находит страницу на сервере;
• выполняет инструкции РНР для модификации страницы;
• посылает страницу обратно броузеру через Интернет или интранет.

 

 

Что же такого делает РНР, чего не может HTML?

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

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

Вот еще несколько примеров того, что можно делать с помощью  РНР, но нельзя делать с помощью только HTML:

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

Этот перечень охватывает лишь то, что лежит на поверхности; в действительности РНР позволяет решать значительно более широкие задачи.

WWW - новое поколение

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

Статические публикации

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

Активные веб-сайты

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

Эти технологии молено разбить на две группы: технологии на стороне  клиента и технологии на стороне сервера. В первую группу входят:

• Управляющие элементы ActiveX, создаваемые с помощью Visual C++ или Visual Basic
• Апплеты Java
• Сценарии, выполняемые на стороне клиента, и динамический HTML

 

В число технологий, используемых на стороне сервера, входят:

• CGI 
• Фирменные API для веб-серверов, такие как ISAPI и NSAPI
• Active Server Pages
• JavaServer Pages и Java Servlets
• PHP

Остановимся вкратце на каждой из них.

Динамические технологии на стороне клиента

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

Управляющие элементы ActiveX

Управляющие элементы ActiveX являются отдельными программами, которые известны как компоненты. Разрабатываются они на таких языках, как С++ или Visual Basic. Располагаясь на веб-странице, такой элемент реализует какую-либо специальную функцию, например, выводит диаграммы и графики, играет роль таймера, производит аутентификацию клиента или доступ к базе данных. Управляющие элементы ActiveX добавляются к страницам HTML с помощью тега <OBJECT>, который вошел в стандарт HTML. Встроенные в веб-страницу управляющие элементы ActiveX могут выполняться броузером или сервером.

Существует  некоторое препятствие: управляющие  элементы ActiveX разработаны Microsoft и, несмотря на совместимость со стандартом HTML, функционируют только в Internet Explorer. Некоторая поддержка ActiveX обеспечивается и для броузера Netscape при использовании подключаемого модуля (plug-in), поставляемого фирмой NCompass. Следовательно, на практике нельзя рассматривать ActiveX как не зависящий от платформы способ создания динамических страниц.

Апплеты Java

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

Сценарии на стороне клиента и DHTML

Языки сценариев  предоставляют новичкам более легкий доступ к программированию. Языки сценариев для использования в Сети на стороне клиента были разработаны с целью создания динамической альтернативы статическому HTML. Когда броузер находит в коде HTML команду сценария, он транслирует этот сценарий в чистый HTML (если броузер понимает данный язык сценариев). Это позволяет разработчику создавать более интерактивные веб-страницы со значительно расширенной по сравнению со страницами чистого HTML функциональностью.

Основным  языком сценариев, используемым на стороне  клиента, служит JavaScript. Он поддерживается как Netscape Navigator (с версии 2), так и Microsoft Internet Explorer (с версии 3). Используемый на стороне клиента VBScript поддерживается только в Internet Explorer и потому не очень  полезен для создания универсальных сценариев для Интернета. Тем не менее, он иногда применяется в интранет, использующих исключительно решения Microsoft.

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

Технологии на стороне сервера

Несколько лет  назад единственным практическим решением для размещения в Сети динамического содержания была технология под названием Common Gateway Interface (CGI - интерфейс общего шлюза). CGI-программы предоставляли сравнительно простой способ создания веб-приложения, получающего введенные пользователем данные, выполняющего запрос к базе данных и возвращающего результаты обратно броузеру. Как Microsoft, так и Netscape разработали собственные API, с помощью которых для обслуживания веб-запросов можно было создавать код, выполняющийся в рамках того же процесса (in-process). В число новейших предлагаемых технологий на стороне сервера входят Active Server Pages (ASP), Java Servlets и JavaServer Pages (JSP), хотя существует много других.

Интерфейс общего шлюза - Common Gateway Interface (CGI)

CGI является  наиболее часто используемой  сетевой технологией, используемой на стороне сервера, и чуть ли не каждый существующий сегодня веб-сервер имеет поддержку CGI-программ. CGI-программа может быть написана почти на любом языке, хотя чаще всего для программирования CGI используется Perl. Веб-серверы, реализующие CGI, действуют как шлюз между запросом пользователя и требуемыми данными. Для этого сначала создается новый процесс, в котором будет выполняться программа (рис. 3.3). Затем в него загружается необходимая среда времени выполнения и сама программа. Наконец, передается объект, представляющий запрос, и вызывается программа. По окончании работы программы веб-сервер считывает из stdout данные, которые она возвратила.

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

Фирменные API веб-серверов (ISAPI, NSAPI)

Видимо, в  ответ на неэффективность CGI Microsoft и Netscape разработали собственные API, позволяющие разработчикам создавать серверные приложения в виде библиотек совместного доступа. Эти библиотеки загружаются в процесс веб-сервера и могут обслуживать несколько запросов, не создавая новых процессов. Они могут загружаться при запуске веб-сервера или по мере необходимости в них. Если в течение определенного времени они не используются, веб-сервер выгружает их из памяти.

Хотя выполняемые  в рамках процесса библиотеки являются эффективным расширением веб-сервера, с ними тоже возникает ряд проблем:

• •   Поскольку эти API специфичны для каждой платформы, написанные с их использованием программы могут работать только на соответствующей платформе. Перенесение этих программ в другую среду является очень сложной задачей.
• •   Поскольку доступ к этим библиотекам осуществляется одновременно несколькими пользователями, они должны быть написаны с применением методов обеспечения безопасности потоковых переменных (thread-safe). Это означает, что доступ к глобальным и статическим переменным должен осуществляться с большой осторожностью.
• •   Если в выполняемой на сервере программе происходит нарушение прав доступа, то поскольку она находится в том же процессе, что и сам веб-сервер, может произойти авария всего веб-сервера.