Вслед за переключением Friendster на PHP , интересно увидеть, что здесь разыгрывается война пламени ( Джефф делает здесь аккуратную подборку ссылок).
После различных комментариев на тему «ясно, что Friendster не знает Java» думаю, что это положило конец этой линии;
У нас был не один, а ДВА парня, которые написали бестселлеры JSP. Не то чтобы это обязательно означало, что они отличные разработчики Java, но я на самом деле думаю, что наши ребята были хороши как любая команда.
Не желая добавлять больше топлива в огонь, кажется, что есть некоторые разработчики J2EE, которые просто не «получают» PHP. Что само по себе интересно, что так трудно понять в PHP? На некотором фундаментальном уровне, кажется, существует различие в мышлении между J2EE-парнем и PHP-парнем, что означает (по крайней мере, в одном направлении), что нельзя понять, что другой подход также работает (и может фактически работать лучше).
CGI от Dummy
Возможно, самый простой способ сказать, что PHP делает на веб-сервере (как модуль Apache), — это сравнить его с CGI (все понимают, правильно ли CGI?).
Примечание / Отказ от ответственности: я не лучший специалист, чтобы говорить о жизненных циклах запросов PHP, производительности и масштабируемости. PHP действительно нужен Стерлинг , Джордж и Расмус, чтобы собраться вместе и написать подробную статью о том, как он работает и почему PHP масштабируется, чтобы мы все могли жить долго и счастливо.
Мой взгляд на CGI — это жизненный цикл запроса;
1. Apache получает запрос на страницу и видит, что он нуждается в обработке CGI
2. Apache разветвляет процесс для обработки запроса (что приводит к накладным расходам)
3. Какой бы бинарный CGI ни выполнял свой запуск (больше накладных расходов)
4. Бинарный файл CGI обрабатывает запрос и доставляет ответ браузеру.
5. Процесс / CGI двоичный «умирает» — возврат к шагу 1
С PHP (как модуль Apache) это почти то же самое, за исключением того, что PHP работает внутри процесса, что означает, что нет никаких накладных расходов на разветвление внешнего процесса и намного меньше работы, которая должна выполняться с точки зрения «запуска» PHP. Другими словами, мы говорим только шаги 1 и 4 выше. Попытка объяснить здесь .
Напротив, приложение, работающее как Java-сервлет, является резидентным в памяти. Если разработчик PHP хранит информацию о сеансе в файле или базе данных, разработчик Java может поместить ее в память. Это важный момент, чтобы понять разницу между путями Java и PHP.
Нашел довольно полезный документ из Сравнения производительности альтернативных решений для приложений Web-to-Database за 2000 год, в котором обсуждается более подробно. Он выступает в пользу сервлетов при рассмотрении производительности и с такими ключевыми словами, как «Поскольку сервлеты написаны на очень переносимом языке Java и следуют стандартной структуре, они предоставляют средства для создания сложных серверных расширений независимо от сервера и операционной системы. Предупреждаю, что здесь есть кто-то, кто читает этикетку.
Но вот в чем суть;
Масштабируемость! = Производительность (!!!)
К сожалению, автор «Мифа о масштабируемости PHP» ошибся, и я видел комментарии о том же влиянии на Friendster.
Да, темы взаимосвязаны, но масштабируемость больше связана с тем, что происходит, когда вы добавляете больше ресурсов, и как это увеличивает объем запросов, обрабатываемых вашим приложением. Смотрите Википедию о масштабируемости . Как правило (если вы не планировали заранее), вы начинаете думать о масштабировании, когда производительность начинает падать из-за увеличения нагрузки.
То, что Java-сервлет работает лучше, чем скрипт PHP, при оптимальных условиях (например, много свободной памяти) не имеет ничего общего с масштабируемостью. Суть в том, может ли ваше приложение продолжать обеспечивать стабильную производительность при увеличении объема. Можно ли, например, поддерживать производительность, добавляя оборудование?
Другими словами «Эта страница занимает 0,5 секунды, чтобы завершить свой ответ. Можем ли мы сохранить эту производительность еще с 500 000 посещений в день? »(Масштабируемость) — вот что нас интересует, а не « Эта страница занимает 0,5 секунды. Как можно уменьшить это до 0,1? »(Производительность).
Обычно люди говорят о двух типах масштабируемости: вертикальная (добавление новых процессоров, диска, памяти к существующей «большой коробке» или покупка «большей коробки») и горизонтальная (добавление дополнительных «коробок» и распределение нагрузки между ними).
Вертикальная масштабируемость проста в реализации, но обычно дороже в долгосрочной перспективе. Как правило, существует ограничение на количество памяти, например, вы можете добавить к существующей «коробке», а «следующая коробка вверх» стоит в три раза дороже, но увеличивает емкость только на 20%.
Горизонтальная масштабируемость требует больше усилий / хитрости, но может оказаться чрезвычайно успешной, как об этом говорится в «Секретном источнике силы Google» — создать «суперкомпьютер» из грязных дешевых деталей. Для репликации файловой системы (и расширением базы данных) в нескольких системах, как правило, существует ряд зрелых решений на выбор, многие с открытым исходным кодом. Репликация памяти — другая история (теперь вернемся к этому важному моменту ).
Кому ты доверяешь?
В одном из комментариев здесь указывалось, что «J2EE может работать в кластере», например, заботясь о репликации памяти.
Именно здесь вам нужно спросить «что такое Java?». Это просто язык программирования? Или библиотеки времени выполнения + являются операционной системой?
Прочитайте Двенадцать правил для разработки более безопасного кода Java , советы типа «Сделайте ваши классы несериализуемыми: сериализация опасна, потому что позволяет злоумышленникам получить в свои руки внутреннее состояние ваших объектов».
Какая?!?
Этот совет по безопасности просто не вычисляется в PHP — это все или ничего. Те, кому я выставляю свои объекты, которым я полностью доверяю (на мгновение игнорируя RPC). Конечно, есть некоторые PHP-фреймворки , но вы не найдете хостов, предоставляющих их как сервис.
В этом и заключается моя собственная фундаментальная проблема с «путём Java» и серверами приложений, такими как JBoss . Кажется, они заново изобретают целую кучу колес (особенно в том, что касается репликации), которые уже являются хорошо обозначенной территорией. А J2EE всего около четырех лет.
Как говорит Расмус, говоря о «ничего не поделился», PHP делегирует все «сложные вещи» другим системам. Apache (который, я думаю, можно с уверенностью сказать, можно доверять) заботится о обработке запросов, разветвляя детей при необходимости. Такие инструменты, как Squid , рекомендуются Rasmus для балансировки нагрузки.
Когда дело доходит до данных сеанса, я гораздо больше склонен верить в кластеризацию файловой системы или базы данных, чем кластеризацию J2EE, ключевыми моментами которой являются зрелость как в механизме, так и в инструментах, которые его поддерживают (для системных администраторов). Также существует серьезный вес в кластеризации Linux, который представляет другой путь для PHP, в то время как существуют другие альтернативы, такие как MSession или memcached ( pecl :: memcache ).
Забавное чтение — « Почему Java отстает для системных администраторов с некоторыми очень правильными точками, такими как;
java.io.FileNotFoundException: somefile (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:64)
at sun.tools.jar.Main.run(Main.java:186)
at sun.tools.jar.Main.main(Main.java:904)
против
Warning: file(somefile): failed to open stream: No such file or directory in /home/hfuecks/scripts/reader.php on line 10
В разделе O’Reillys Java SysAdmin (!) Веселье продолжается с планированием заданий в Java .
Хммм …
$ man cron
«4-е распределение Беркли 20 декабря 1993 года»
Mind set Разрывность
В ответ на комментарий Расмуса о ничем не разделенном / бесконечной горизонтальной масштабируемости написал кто-то по имени Марк;
«Расмус, твой пост — та самая причина, по которой не стоит использовать PHP. Вы отправляете состояние сеанса, обмен сообщениями между процессами и состояние приложения в базу данных. Ради Friendster, я надеюсь, что у них есть огромный кластеризованный экземпляр Oracle, потому что, как только они превысят возможности своей базы данных, сайт развалится.
JSP намного, намного эффективнее, чем PHP, когда речь идет о снятии нагрузки с базы данных, по тем причинам, которые вы упомянули выше. Песочница каждого запроса по своей сути является ошибкой, потому что для любого ОО потребовалось бы загружать профиль пользователя каждый раз, когда вы заходите на страницу ».
Типичным подходом PHP было бы сохранение профиля пользователя как части данных сеанса, которые содержат все, что имеет отношение к этому сеансу — вы загружаете его один раз за запрос и заполняете все необходимые объекты им. Конечно, вызов БД (если это то, что вы используете) это накладные расходы, но это управляемые накладные расходы. Дальнейшие вызовы БД (например, выборка контента) могут быть устранены путем разумного использования кэширования.
Джордж предлагает отличную дискуссию по Scaling Oracle и PHP, которая, как мне кажется, подчеркивает ключевое различие мышления между PHP и Java-разработчиком. Возьмите этот совет к примеру;
«Если средняя страница в вашем веб-приложении содержит девять изображений, то только десять процентов запросов к вашему веб-серверу фактически использовали постоянные соединения, которые они им присвоили. Другими словами, девяносто процентов запросов тратят ценный (и дорогой, с точки зрения масштабируемости) дескриптор соединения Oracle. Ваша цель должна заключаться в том, чтобы с вашего динамического веб-сервера обслуживались только те запросы, которые требуют подключения Oracle (или, по крайней мере, требуют динамического контента). Это увеличит объем работы, связанной с Oracle, выполняемой каждым процессом, что, в свою очередь, уменьшает количество дочерних элементов, необходимых для создания динамического контента.
Самый простой способ добиться этого — выгрузить все ваши изображения на отдельный веб-сервер (или набор веб-серверов) ».
Этот совет специфичен для приложения и среды, в которой оно выполняется. Я бы сказал, что разработчики PHP думают о приложениях таким образом; каждый из них уникален, и, когда дело доходит до масштабирования, требуется уникальный набор решений.
В то же время Java-подход ищет решение «один размер подходит всем» — то, что отвлечет вас от конкретных решений, подобных этому, и создаст среду, в которой вы можете «выстрелить и забыть». Хотя это замечательная цель, она требует ( и) заново изобрел много колес и требует фундаментального убеждения, что программное обеспечение может быть произведено серийно и при этом соответствовать требованиям. При таком подходе PHP-подход кажется недосягаемым для парня из J2EE.
В конечном счете, думаю, что это противостояние между «Процесс / Форк» (LAxP) и «Время выполнения / Поток» (J2EE / .NET). Когда вы спрашиваете «масштабируется ли PHP?», Вы действительно спрашиваете: «Process / Fork + X постоянное хранилище масштабируется?». Во многих отношениях это ставит под сомнение, масштабируется ли * Nix …