Насколько хороша производительность PHP? - PullRequest
14 голосов
/ 18 мая 2009

Это продолжение моего недавнего поста, в котором говорится, что производительность PHP низкая:

"PHP. ЕСТЬ. ВСЕГДА. BOTTLENECK. Мои серверные фермы, позвольте мне показать их! Общая производительность PHP "

с последующим:

"Производительность PHP падает ужасно . Я основываюсь на своем опыте работы с OpenX (в Linux) и WordPress (в win64)."

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

  1. По сравнению с другими языками / средами исполнения
  2. С точки зрения языка, существуют ли какие-либо конкретные библиотеки или операции, которые лучше или хуже других?
  3. С точки зрения сборки, существуют ли какие-либо версии или платформы, которые лучше или хуже других?

Ответы [ 9 ]

31 голосов
/ 18 мая 2009

Ответ на вопрос "Насколько хороша производительность PHP?" "достаточно хорошо".

Под этим я подразумеваю, что большинство проблем с производительностью веб-сайтов связаны с другими проблемами, такими как плохое проектирование базы данных, кеширование с минимальным отсутствием или кеширование CSS / Javascript / изображений и т. Д.

PHP используется некоторыми из крупнейших сайтов в Интернете, поэтому он прошел этот тест. Джефф Этвуд утверждает, что PHP - отстой, но это не имеет значения . Есть вещи, за которые можно справедливо критиковать PHP (например, непоследовательный порядок параметров, непоследовательное именование функций, магические кавычки и т. Д.), Но я думаю, что он преувеличивает негатив.

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

4 голосов
/ 18 мая 2009

PHP работает нормально. Если, конечно, вы не разрабатываете 3d игры.

  1. Различия незначительны и пламени приманки. Потому что, действительно, это Рубиизм "кого волнует, быстро ли он, если он масштабируется?" все что не так? Смотрите # 2 для примера того, что замедляет вас.

  2. Все, что требует времени. (Иронично, я знаю.) Но на самом деле, это всегда зависит от того, как вы делаете то, что вы делаете , что занимает время. Например, я могу написать два запроса с почти одинаковым выводом, но при увеличении скорости в 2,5 раза с лучшим синтаксисом / выбором. По большому счету, худшая трата времени в скрипте PHP - это доступ к файлу ... благодаря аппаратному обеспечению. Таким образом, количество включаемых / требующихся файлов замедляет работу сценария в большей степени, чем его содержимое - особенно при фрагментации.

    С помощью этой простой системы я манипулировал своей собственной платформой MVC, чтобы почти в 10 раз увеличить скорость приложения CodeIgniter с открытыми концами; это проще и более минималистично, да, но это должно показать, что включение 1 файла против 1 на класс может привести к огромным различиям в скорости.

  3. Пока его * AMP хорош, серверы Linux будут, или, конечно, быстрее. Я был доволен как моей системой WAMP, так и системой LAMP, несмотря на совершенно разные аппаратные и программные различия. (Но система LAMP, как правило, самая быстрая, хотя и менее аппаратная.)

2 голосов
/ 18 мая 2009

В настоящее время ведется проект с разработчиками PHP для создания лучших инструментов Benchmark для PHP.

Руководитель проекта недавно выступил с докладом о технических новостях Google под названием Компиляция и оптимизация языков сценариев , и это очень интересный доклад.

Также на днях я проверил размер приложения PHP.

  • PHPBB 1,3 МБ
  • Joomla 6 МБ
  • WordPress 11,3 МБ

Это данные, загруженные в память.

2 голосов
/ 18 мая 2009

Производительность PHP не так уж и плоха - по сравнению с C она будет проигрывать, но по сравнению с другими языками сценариев она примерно равна.

См. в этой перестрелке для интерактивного теста производительности, чтобы дать вам представление о некоторых показателях производительности.

Конечно, есть это слайд-шоу, в котором говорится, PHP редко является узким местом .

0 голосов
/ 21 мая 2009

Вы можете найти эти слайды выступления Расмуса несколько уместными и интересными: talks.php.net/show/drupal08/

0 голосов
/ 19 мая 2009

PHP может быть не таким быстрым, как скомпилированные серверные языки, но он все еще довольно быстрый и выполняет свою работу.

«Скорость» php больше связана с пользовательским интерфейсом, чем с самой производительностью.

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

Один из предыдущих комментариев достаточно точно подытожил: язык не опасен! приложение doez.

ура, мл

0 голосов
/ 19 мая 2009

Yahoo! использует PHP. http://public.yahoo.com/bfrance/radwin/talks/yahoo-phpcon2002.htm

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

0 голосов
/ 19 мая 2009

Производительность значительно улучшается за счет использования кэша оп-кода, например Альтернативный PHP-кэш , который является бесплатным и обеспечивает значительное повышение производительности за счет «компиляции» ваших сценариев в коды операций, которые могут использоваться Zend Engine напрямую, без лишних затрат (чрезмерно используемый термин IMO) при разборе кода при каждом запросе. Вы можете увидеть тест здесь и пост из моего блога об использовании кэша APC для ускорения Zend_Loader

0 голосов
/ 18 мая 2009

Использование правильных алгоритмов и структур данных гораздо важнее для производительности, чем использование определенного языка программирования (при условии, что их можно выразить на выбранном языке).

Так что PHP может быть даже быстрее, чем C ++, если PHP-программист знает, что он делает.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...