Смешно из толпы Python: phpfilter — поддержка PHP под CherryPy . Однако в этом есть серьезная сторона — это то, что выдает что-то, похожее на ошибку синтаксического анализа PHP, — то есть это проблема разработчика (например, кто-то, кто «проверил» PHP прямо на своем веб-сервере для «тестирования»), а не среда выполнения ошибка.
Более того, когда вы в последний раз видели, как ошибка выполнения PHP приводила к сбою всего приложения или веб-сервера? И нет — «Ошибка подключения MySQL: не удается подключиться к локальному серверу MySQL» не в счет — PHP и веб-сервер все еще работают — виноват сервер MySQL (или другой).
С PHP очень трудно для сценария уничтожить среду выполнения — веб-сервер — я бы сказал, что вам придется сознательно пытаться сделать это, возможно, заполнить место на диске или иным образом. Невинные ошибки, конкретные случаи проблем во время выполнения (например, слишком продолжительное выполнение скрипта) и ошибки остаются локальными для конкретных запросов и сценариев PHP, обрабатывающих их. По следующему запросу мы начнем снова с нуля .
Теперь может быть разумным утверждать, что Apache + mod_php обслуживал больше запросов HTTP для динамических страниц, чем любая другая сопоставимая среда. Несмотря на бородавки и прочее, это проверенное ПО просто по массе цифр. Это переводит на платформу, которая стоит мало, чтобы продолжать работать и меньше шансов на пробуждение в 2 часа ночи.
Во всяком случае — недавно наткнулся на отличный блог: FastCGI, SCGI и Apache: Background and Future, где обсуждаются варианты с учетом нового спроса на FastCGI с такими фреймворками, как Rails , увиденными глазами системного администратора. В значительной степени это также объясняет, почему мы закончили с PHP.
Чтобы по-настоящему понять дискуссию, Марк Мейо делает примерное представление о наиболее распространенных технических подходах, используемых для реализации серверов, способных обрабатывать несколько запросов веб-страниц (одновременно) и передавать запрос в программу (например, скрипт PHP) для обработка. Обратите внимание, что это не является подробным руководством по многозадачности — это скорее мое глупое понимание / представление. Хорошее место для начала, если вы хотите чего-то более мясного, есть в Википедии здесь .
- Форкинг: процесс HTTP-сервера порождает дочерние процессы для обработки каждого входящего запроса, дочерние процессы либо истекают (выход), либо возвращаются в «пул» для повторного использования, когда запрос завершается (Apache 1.3x выполняет последнее).
С помощью сценариев Apache + CGI дочерние процессы Apache, в свою очередь, должны разветвлять дополнительные дочерние процессы, в которых выполняется программа CGI, поэтому процесс запуска идет довольно медленно. FastCGI устраняет это, поддерживая выполнение процесса CGI для дальнейших запросов (но для этого требуется гораздо более сложная задача).
С помощью mod_php скрипт запускается внутри самого дочернего процесса Apache. Это уменьшает накладные расходы на дальнейшую ветвь и означает, что PHP «время выполнения» необходимо загружать только при создании дочернего элемента Apache.
Форкинг хорош тем, что его относительно легко реализовать, и что (по большей части) проблемы многозадачности не ложатся на разработчиков приложений.
Еще одна вещь, которая делает эту модель популярной у sysadmins, это то, что дочерние процессы могут «зависать» (например, этот бесконечный цикл в вашем PHP-скрипте) без отключения основного процесса сервера — это, вероятно, причина № 1, почему общие хосты хотят установить mod_php — им не нужно постоянно перезагружать сервер в результате того, что его клиенты сделали с ним.
Кроме того, в частности, для CGI проще перенести проблемы безопасности в операционную систему, позволяя запускать пользовательские сценарии с их разрешениями, а не с разрешениями пользователя веб-сервера.
Это не относится к mod_php, который нарушает обычную безопасность файловой системы UNIX. PHP-скрипты должны быть доступны для чтения только в файловой системе, чтобы mod_php мог их выполнить.
Недостатком разветвления является (относительно) медленное / дорогое развертывание нового процесса, и каждый дочерний элемент сжимает память и ресурсы во время его работы, где он может быть более эффективным для совместного использования. Подход mod_php — это самый простой способ свести эту стоимость к минимуму.
Кроме того, Windows на самом деле не поддерживает разветвление в стиле UNIX, делая больший упор на многопоточность, что может быть проблемой, если вы хотите, чтобы ваш сервер работал хорошо под Windows.
- Потоки: потоки выполняются внутри одного процесса и работают на основе разделения времени: каждый поток получает определенное количество времени для выполнения вещи. Потоки теперь используются в Apache 2.x и также распространены на серверах приложений Java (которые сами являются серверами HTTP)
Преимущество потоков заключается в более низкой стоимости «создания» (например, быстрее) по сравнению с разветвлением, и легче «делиться» между потоками (например, совместно использовать переменную). Примечание: когда ребята из Java говорят, что у них есть веб-сервер, который работает лучше, чем PHP, они, вероятно, говорят правду (но помните, производительность! = Масштабирование)
С другой стороны, некоторые утверждают, что потоки очень сложны в коде, а такие проблемы, как взаимоблокировки и условия гонки, сложно отладить. Это может быть проблемой только для разработчиков на веб-сервере — вам не нужно навязывать темы людям, пишущим приложения, для запуска под вашим веб-сервером — но чем сложнее, тем больше ошибок и т. Д.
Кроме того (более подробно о реализации), если каждому потоку на сервере предоставляется свой собственный поток ввода-вывода для входящего запроса, это, вероятно, приведет к поглощению памяти / ресурсов, при этом большинство операционных систем поддерживают только ограниченное количество одновременно работающих потоков. — для серьезного обсуждения см . Проблему C10K (на самом деле отлично прочитано).
Другая проблема, связанная с потоками и веб-серверами, заключается в большей вероятности того, что данный поток отключит весь сервер, хотя это, вероятно, больше деталей реализации.
- Асинхронный ввод / вывод: в программировании часто используется синхронный (блокирующий) ввод / вывод — вы читаете из «потока», и ваш код (процесс) останавливает выполнение до завершения чтения.
Асинхронный ввод / вывод использует неблокирующие системные вызовы, чтобы позволить вашему коду (процессу) продолжать делать другие вещи (например, больше ввода / вывода) параллельно. Обратные вызовы (или аналогичные) выполняются только тогда, когда происходят определенные события (например, конец файла). И в наши дни мы все знакомы с этим способом, благодаря AJAX, верно? ;).
Возможно, наиболее ярким примером асинхронного ввода-вывода является искаженный фреймворк Python, о котором, как я думаю, мы услышим все больше и больше в ближайшие пару лет.
Асинхронный ввод / вывод хорош тем, что он не имеет ограничений, которые имеет многопоточность, и, вероятно, приводит к более эффективному использованию ресурсов. Это может (в зависимости от вашего API — на более низких уровнях, это сложнее) также легче писать код таким способом, хотя это все же не так просто, как разветвление — большая часть того, что делает Twisted, заключается в предоставлении хорошего API для асинхронного ввода-вывода, решения большинство проблем параллелизма для вас, чтобы вы могли сосредоточиться на проблемах более высокого уровня.
Я предполагаю, что у вас также есть риск того, что «пользовательский код» уничтожит весь сервер с помощью асинхронного ввода-вывода — не рассматривал, как с этим справляются искаженные проблемы — возможно, это просто детали реализации.
Кстати, вы также можете быть удивлены, заметив, что более поздние версии PHP также имеют некоторую поддержку асинхронного ввода-вывода. Смотрите здесь (PDF) для получения дополнительной информации.
Конечно, это определенно не так ясно, как я предполагаю. Для начала, какой тип разработчика вы будете влиять на ваше мировоззрение: разработчики ядра Linux увидят разные проблемы и границы для разработчиков языков и библиотек, которые, в свою очередь, видят другой взгляд на разработчиков приложений, использующих доступные API. И данный веб-сервер, вероятно, будет использовать более одного подхода — возможно, все три.
Похоже, дело в том, что асинхронный ввод-вывод только сейчас достигает совершеннолетия / популярности на веб-серверах. Тем временем FastCGI снова востребован и находится в разработке, учитывая Rails, web.py и аналогичные. Несмотря на это, mod_php до сих пор (сегодня) представляет собой меньшее из всех зол для системных администраторов — не идеальное решение (например, проблемы с безопасностью), а лучший компромисс со всех сторон — по крайней мере, в обозримом будущем.
Кстати, если вы чувствуете, что по-другому смотрите на прошлое PHP, посмотрите статью Адама Трахтенберга : битва за промежуточное ПО: PHP против мира (PDF).