Я с удивлением узнал сегодня, что PHP широко используется на сайтах с высоким трафиком.
Я всегда думал, что PHP не является сильным с точки зрения производительности, являясь динамическим языком сценариев (например, по сравнению со статически типизированным, скомпилированным языком, таким как C/Java/С# и т.д.).
Итак, как получилось так хорошо?
То, что вы обычно найдете, это не так медленно, как вы думаете. Причина, по которой многие сайты медленны, заключается в том, что хосты перегружены.
Но одним из основных преимуществ PHP над скомпилированным языком является простота обслуживания. Поскольку PHP разработан с нуля для HTTP-трафика, там меньше, чем для большинства других скомпилированных языков. Кроме того, слияние изменений становится проще, так как вам не нужно перекомпилировать и перезагрузить сервер (как это было бы с скомпилированным двоичным кодом)...
Я провел немало тестов для обоих, и для любого порядка 50 тыс. запросов в секунду (основанный на моих числах) действительно нет существенного выигрыша в использовании скомпилированного двоичного файла (FastCGI). Конечно, это немного быстрее, используя скомпилированный C, но если вы не говорите об уровне трафика на уровне Facebook, это не означает значительного $$$. И это определенно не собирается компенсировать относительно быстрый темп развития, который PHP будет позволять по сравнению с использованием C (что, скорее всего, потребует много раз кода, поскольку он не управляется памятью)...
PHP, если правильно написанный, может быть достаточно масштабируемым. Ограничивающие факторы, как правило, в вашем движке базы данных. И это будет общим фактором независимо от того, какую технологию вы используете...
Развертывания Java в больших корпоративных настройках - это беспорядок... борьба со сборками и кодом, которые могут не скомпилироваться для малейших мелочей. Кроме того, PHP работает на довольно простой настройке по серверу, а не на громоздком коде, который является Weblogic (или другими), поэтому другие права в том, что его низкая стоимость для разработки и дешевая для развертывания на нескольких разных машинах. Это, конечно же, не помогло, что я испортился, работая в большой, ОЧЕНЬ неэффективной корпоративной среде, выполняя Java....
Я бы не сказал, что разработчики PHP сами по себе дешевле (теперь я делаю больше PHP-разработчиком, чем разработчиком Java-интерфейса), но я знаю, что мой последний работодатель заплатил мне за незначительное количество время, потраченное на настройку, развертывание, компиляцию и т.д., которые не требуются в PHP. Мы говорим, вероятно, о том, что один день/неделю связанного с этим конфигурирования возникают из-за новых откатов ветки или конфигураций, связанных с релизами. Таким образом, дополнительные, которые мне платят сейчас, компенсируются значительным количеством кода, который я могу работать каждую неделю.
PHP, безусловно, помогает в том, что MySQL и Postgres (в меньшей степени) стали настолько мощнее. Они не связаны напрямую, но, поскольку это общее соединение просто подслащает сделку для тех, кто принимает решения.
Большинство веб-сайтов имеют шейдеры производительности при запросе базы данных и т.д. Количество времени, затрачиваемого на выполнение script, обычно невелико по сравнению с этим. Использование таких вещей, как libmemcached, может помочь смягчить это.
Он действительно не работает так хорошо, просто достаточно, чтобы его можно было использовать. Имейте в виду, что Java и С#.NET также запускаются как байт-код внутри виртуальной машины. PHP с такими инструментами, как Zend Optimizer, также может пропустить этап компиляции и работать как байт-код.
PHP не будет работать так быстро, как собственный, скомпилированный код C, но такие сайты, как Facebook, компилируют PHP на С++, чтобы он работал быстрее (см. HipHop-PHP).
Многие сайты начались как сайты с низким трафиком. Как только у вас запущен ваш PHP-сайт, и вам приходится обрабатывать гораздо более высокий трафик, дешевле просто купить больше серверов, чем переписывать приложение с PHP на что-то другое. Кроме того, есть инструменты, которые улучшают производительность PHP.
Также обратите внимание, что существуют другие факторы: база данных, стратегия кэширования, которые влияют на производительность больше, чем сам PHP.
Это не так, поэтому есть проекты вроде HipHop, но динамические языки часто быстрее развиваются, а аппаратное обеспечение дешевле, чем разработчики.
По-моему, природой PHP без учета состояния является важнейшим фактором его масштабируемости. Прошло некоторое время с тех пор, как я провел какую-либо веб-работу с Java/ASP.NET, но я помню, что обе технологии имеют центральное приложение "движок", через которое проходят все запросы. Это здорово, потому что информация и состояние могут быть разделены между экземплярами, и много загрузочных операций (чтение файлов конфигурации, подключение к базам данных и т.д.) Можно выполнить один раз, а затем совместно использовать экземпляры. Это плохо, хотя из-за того, что центральный "движок" сам по себе становится узким местом для всего приложения.
Отсутствие центрального движка в PHP также означает, что масштабирование вашего приложения, как правило, просто связано с добавлением другого веб-сервера в вашу установку (хотя масштабирование базы данных вместе с ней сложнее). Я предполагаю, что масштабирование приложения Java/ASP.NET намного сложнее, и они достигают точки насыщения, когда добавление большего количества аппаратного обеспечения каждый раз уменьшает нагрузку.