* Постоянно профилируйте свой код на сервере (xdebug) и на клиенте (firebug), что бы выявить узкие места кода
и так, на production, отжирая 50% проца, висел xdebug…
* «Критически тяжёлые» функции желательно реализовать на стороннем языка программирования в виде расширения PHP
ага. а как часто это будет отваливаться — никто не учитывает?
* Различие повремени на клиенте может составлять около 1 секунды, поэтому имеет смысл четкое разделение статики и генерируемых средствами PHP страниц.
это как? или у нас PHP на клиентской стороне обрабатывается?
* Старайтесь не использовать require_once или include_once неоднократно по отношению к одному и тому же файлу Иначе Вы элементарно теряете время на повторное считывание файла.
буга. бугага. бугагагагага. на то они и once, чтобы повторно не считывать. или вы еще на 4.2 где этот баг был?
* Желательно использовать проверку отправляемых данных на клиенте Это вызвано тем, что при проверке данных на стороне клиента, резко снижается количество запросов с неверными данными. Системы проверки данных на клиенте строятся в основном с использованием JS и жестких элементов формы (select).
ей. инетбанк такой напишите пожалуйста, я схожу его поломаю
* Желательно большие конструкций DOM для массивов данных строить на клиентеЭто очень эффективный метод оптимизации при работе с отображением большого объёма данных. Суть его сводится к следующему: на сервере подготавливается массив данных и передаётся клиенту, а построение конструкций DOM предоставляется JS функциям. В результате нагрузка частично перераспределяется с сервера на клиент.
это в gwt справедливою в PHP — нет.
* Используйте постоянное соединение с БД при малом количестве одновременно активных клиентов
первый небредовый совет )
* Например можно использовать следующий простой подход: получаем данные выборки из БД и сохраняем их как сериализованный массив в файл
так вот откуда растут монстры с миллионами (я видел) файлов кеша :)
и потом спрашивают — а что все тормозит.
запомните — никакие нахрен файлы не смогут управлять кешем так как тот же memcached.
* Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
ассемблер в студию
* По времени считывания пустого файла колебания от 0.001 для readfile до 0.002 для include.
это на калькуляторе или первом пентиуме?
у меня на сервере около 0.00013 для 1000 чтений.
* $row['id'] быстрее, чем $row[id]
это вообще ошибка в коде, доррогой мой. второй случай — исключение и приведение неизвестной константы к строке
Товагищи! У нас таки-завелся либо очень олскульный, либо просто говнокодер, который в века баз на миллионы строк, невроткубических можностей амазона оптимизирует PHP в стиле 4.2 кода бородатого 2000 года. Это ужасно и печально.
А вообще — десткая статья. Если надо выбирать между опддерживаемостью и оптимальностью — надо выбирать поддерживаемость, уж поверьте мне.
кешер, кстати, насколько медленнее насколько рабоатет flock на чтение байткода. вообще самый быстрый код — на лиспе, давайте на нем вебпанельки писать? )
можно и не хамить кстати :)
можем комитами в symfony померяться для важности. есть шанс, что проиграете.
я как бы неплохо ориентируюсь в теме, и лезть с PHP в такие штуки — глупо.
Для меня основной причиной забросить дельфи было то что та версия которая под .net (не помню точное название) запускалась за время, за которое visual studio успевало запуститься, открыть проект, открыть msdn, скомпилить, запустить под дебагом.
и так, на production, отжирая 50% проца, висел xdebug…
* «Критически тяжёлые» функции желательно реализовать на стороннем языка программирования в виде расширения PHP
ага. а как часто это будет отваливаться — никто не учитывает?
* Различие повремени на клиенте может составлять около 1 секунды, поэтому имеет смысл четкое разделение статики и генерируемых средствами PHP страниц.
это как? или у нас PHP на клиентской стороне обрабатывается?
* Старайтесь не использовать require_once или include_once неоднократно по отношению к одному и тому же файлу Иначе Вы элементарно теряете время на повторное считывание файла.
буга. бугага. бугагагагага. на то они и once, чтобы повторно не считывать. или вы еще на 4.2 где этот баг был?
* Желательно использовать проверку отправляемых данных на клиенте Это вызвано тем, что при проверке данных на стороне клиента, резко снижается количество запросов с неверными данными. Системы проверки данных на клиенте строятся в основном с использованием JS и жестких элементов формы (select).
ей. инетбанк такой напишите пожалуйста, я схожу его поломаю
* Желательно большие конструкций DOM для массивов данных строить на клиентеЭто очень эффективный метод оптимизации при работе с отображением большого объёма данных. Суть его сводится к следующему: на сервере подготавливается массив данных и передаётся клиенту, а построение конструкций DOM предоставляется JS функциям. В результате нагрузка частично перераспределяется с сервера на клиент.
это в gwt справедливою в PHP — нет.
* Используйте постоянное соединение с БД при малом количестве одновременно активных клиентов
первый небредовый совет )
* Например можно использовать следующий простой подход: получаем данные выборки из БД и сохраняем их как сериализованный массив в файл
так вот откуда растут монстры с миллионами (я видел) файлов кеша :)
и потом спрашивают — а что все тормозит.
запомните — никакие нахрен файлы не смогут управлять кешем так как тот же memcached.
* Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
ассемблер в студию
* По времени считывания пустого файла колебания от 0.001 для readfile до 0.002 для include.
это на калькуляторе или первом пентиуме?
у меня на сервере около 0.00013 для 1000 чтений.
* $row['id'] быстрее, чем $row[id]
это вообще ошибка в коде, доррогой мой. второй случай — исключение и приведение неизвестной константы к строке
Товагищи! У нас таки-завелся либо очень олскульный, либо просто говнокодер, который в века баз на миллионы строк, невроткубических можностей амазона оптимизирует PHP в стиле 4.2 кода бородатого 2000 года. Это ужасно и печально.
А вообще — десткая статья. Если надо выбирать между опддерживаемостью и оптимальностью — надо выбирать поддерживаемость, уж поверьте мне.
на тему юзанья — а куда придумали dbus тот же? unix sockets?
кстати, второй комментарий к статье вообще был про непериваривание c-подобного синтаксиса. я так прямо и похоронил ruby вместе с vhdl.
заканчивая тему могу прдложить автору консервным ножом нарезать хлеб, а простым открыть тушенку. неблагодарное дело.
это был такой толстый троллинг.
сначала смотрите что можно использовать, потом только переписываете и если только совсем косяк — пишите свое.
можем комитами в symfony померяться для важности. есть шанс, что проиграете.
я как бы неплохо ориентируюсь в теме, и лезть с PHP в такие штуки — глупо.
Проблема в том что у человека не было проблемы с конфигами. У него была проблема сесть и сделать.