Почему PHP подходит для сайтов с высоким трафиком?

Я был удивлен, узнав сегодня, что PHP широко используется на сайтах с высоким трафиком.

Я всегда думал, что PHP не является сильным с точки зрения производительности, являясь динамическим языком сценариев (например, по сравнению со статически типизированным, скомпилированным языком, таким как C / Java / C # и т. Д.).

Итак, как получилось так хорошо?

Related of "Почему PHP подходит для сайтов с высоким трафиком?"

То, что вы обычно найдете, это то, что это не так медленно, как вы думаете. Причина, по которой многие сайты медленны, заключается в том, что хосты перегружены.

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

Я провел немало тестов для обоих, и для где угодно около 50 тыс. Запросов в секунду (на основе моих номеров) действительно нет существенного выигрыша в использовании скомпилированного двоичного файла (FastCGI). Конечно, это немного быстрее, используя скомпилированный C, но если вы не говорите об уровне трафика на уровне Facebook, это не означает значительную сумму $$$. И это определенно не будет компенсировать относительно быстрый темп развития, который PHP будет позволять по сравнению с использованием C (что, скорее всего, потребует много раз кода, поскольку он не управляется памятью) …

PHP, если правильно написан, может быть достаточно масштабируемым. Ограничивающие факторы, как правило, в вашем движке базы данных. И это будет общий фактор независимо от того, какую технологию вы используете …

Развертывания Java в больших настройках предприятия – это беспорядок … борьба со сборками и кодом, которые могут не скомпилироваться для малейших мелочей. Кроме того, PHP работает на довольно простой настройке по серверу, а не на громоздком коде, который является Weblogic (или другими), так что другие правы в том, что для разработки и дешевого развертывания на нескольких разных машинах низкая стоимость. Это, конечно, не помогло, что я испортился, работая в большой, ОЧЕНЬ неэффективной корпоративной среде, делая Java.

Я бы не сказал, что разработчики PHP дешевле сами по себе (я делаю больше сейчас как разработчик PHP, чем я, как разработчик пользовательского интерфейса Java), но я знаю, что мой последний работодатель заплатил мне за незначительное количество времени, потраченного на настройку , развертывание, компиляция и т. д., что не требуется в PHP. Мы говорим, вероятно, о том, что один день / неделю связанного с этим конфигурирования возникают из-за новых откатов филиала или конфигураций, связанных с релизами. Таким образом, дополнительный я получаю сейчас за счет значительного количества кода, который я могу работать каждую неделю.

PHP, безусловно, помогает в том, что MySQL и Postgres (в меньшей степени) стали настолько мощнее. Они не связаны напрямую, но использование этого как общего спаривания просто подслащает сделку для тех, кто принимает решения.

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

Он действительно не работает «так хорошо», достаточно хорошо, чтобы его можно было использовать. Имейте в виду, что Java и C # .NET также запускаются как байт-код внутри виртуальной машины. PHP с такими инструментами, как Zend Optimizer, также может пропустить этап компиляции и работать как байт-код.

PHP не будет работать так быстро, как собственный, скомпилированный код C, но такие сайты, как Facebook, компилируют PHP на C ++, чтобы он работал быстрее (см. HipHop-PHP ).

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

Также обратите внимание, что существуют другие факторы: база данных, стратегия кэширования, которые влияют на производительность больше, чем сам PHP.

Это не так, поэтому есть такие проекты, как HipHop , но динамические языки часто быстрее развиваются, а оборудование дешевле разработчиков.

По моему мнению, прирост PHP без учета состояния является наиболее важным фактором его масштабируемости. Прошло некоторое время с тех пор, как я сделал какую-либо работу в Интернете с Java / ASP.NET, но я помню, что обе технологии имеют центральное приложение «двигатель», через которое проходят все запросы. Это здорово, потому что информация и состояние могут быть разделены между экземплярами, и много загрузочных операций (чтение файлов конфигурации, подключение к базам данных и т. Д.) Можно выполнить один раз, а затем совместно использовать экземпляры. Это плохо, потому что этот центральный «двигатель» сам по себе становится узким местом для всего приложения.

Отсутствие центрального движка в PHP также означает, что масштабирование вашего приложения, как правило, является простым вопросом добавления другого веб-сервера к вашей установке (хотя масштабирование базы данных вместе с ней сложнее). Я предполагаю, что масштабирование приложения Java / ASP.NET намного сложнее, и они достигают точки насыщения, когда добавление большего количества аппаратного обеспечения дает меньше стимула каждый раз.