Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Выделено из темы про бенчмарк — прим. адм.
Сегодня попробовал Laravel на Nginx + PHP-fpm без Apache — отдача идет в 4 раза быстрее. Если интересно, могу выложить инструкцию для Debian.
P.S. Заметил внезапно, что laravel.ru на Nginx 0.7.
Изменено Proger_XP (02.01.2013 14:22:19)
Не в сети
Мастер 
Не в сети
С фреймворками на Си одна проблема - нельзя залезть в код ядра. А здесь всегда можно исходники глянуть, если что-то идет не так как ожидается. И сразу поправить, и разрабам отписать.
Изменено OrlandoST (22.12.2012 21:25:17)
Не в сети
С фреймворками на Си одна проблема — нельзя залезть в код ядра. А здесь всегда можно исходники глянуть, если что-то идет не так как ожидается. И сразу поправить, и разрабам отписать.
Ну почему же, очень даже. Касательно Phalcon, там полностью открытый исходный код, скачивайте с github, анализируйте, вносите предложения. 
Изменено oleg578 (26.12.2012 16:00:34)
Не в сети
Ну почему же, очень даже. Касательно Phalcon, там полностью открытый исходный код, скачивайте с github, анализируйте, вносите предложения.
Вот и получается, что для «разгребания» проблем, мне понадобится знание двух языков — С и PHP. А для полноценного тестирования своих «изменений» понадобится постоянная перекомпиляция кода ядра фреймворка. Что несколько усложняет разработку. Также усложняется и отладка. Мне два отладчика одновременно нужно запустить для полноценной отладки. Все идут к тому, чтобы и на сервере, и на фронтенде один язык использовать, а тут наоборот — еще один язык добавляем. Причем компилируемый.
Я не против таких фреймворков. Но тут надо понимать, что ты очень сильно завязан на мастерство разработчиков.
И потом основным узким местом большинства веб-приложений является уровень работы с БД. А это уже модуль, написанный на С. Все остальное — вопрос качества кода и грамотной системы кеширования. Этот фреймворк не дает решений для «узких» мест PHP — асинхронности и многопоточности. Так что я не вижу для чего усложнять себе жизнь.
Я лучше предпочту единую стилизацию кода, автоматическую общую документацию через PHPDoc, прелести автоподстановки и поиска по классам ядра в IDE.
Не в сети
Мастер
- идут к тому, чтобы и на сервере, и на фронтенде один язык использовать
И даже в браузере, если взять Node.js. Получается вообще сказка, раньше это не снилось.
- а тут наоборот — еще один язык добавляем. Причем компилируемый.
Это как раз и повышает скорость работы в разы, очевидно, что интерпретируемый язык не сравнится с компилируемым по быстродействию.
- И потом основным узким местом большинства веб-приложений является уровень работы с БД.
Не совсем. В целом любой скрипт, если это не голый PHP с сотней строк в одном файле, работает в десятки раз медленнее отдачи статики самим сервером, что понятно. Такие фреймворки, как Phalcon, пытаются уменьшить эту разницу — не за счёт ускорения выполнения в узких местах (многопоточность), а за счёт повышения общей скорости работы, в данном случае передвинув весь фреймворк (который обычно подключается из скриптов и обрабатывается PHP до того, как собственно сама страница начнёт генерировать содержимое) в уже скомпилированный баайт-код, причём не PHP-шный, а платформенный. Понятно, что скорость инициализации такой страницы стремится к нулю.
Не в сети
Не совсем. В целом любой скрипт, если это не голый PHP с сотней строк в одном файле, работает в десятки раз медленнее отдачи статики самим сервером, что понятно. Такие фреймворки, как Phalcon, пытаются уменьшить эту разницу — не за счёт ускорения выполнения в узких местах (многопоточность), а за счёт повышения общей скорости работы, в данном случае передвинув весь фреймворк (который обычно подключается из скриптов и обрабатывается PHP до того, как собственно сама страница начнёт генерировать содержимое) в уже скомпилированный баайт-код, причём не PHP-шный, а платформенный. Понятно, что скорость инициализации такой страницы стремится к нулю.
Ну если бы инициализация была самым узким местом, то все бы давно на Fast CGI перешли, а этого нет.
И потом код ядра это же еще не все. Будет куча сторонних (или своих) модулей. Их тоже компилировать?
Тогда уж проще Hip Hop PHP использовать.
Не в сети
Мастер
- Ну если бы инициализация была самым узким местом, то все бы давно на Fast CGI перешли, а этого нет.
На FastCGI действительно многие перешли, связка nginx+php_fpm на моих сайтах дала увеличение производительности в 10 раз по сравнению с Apache+mod_php, как я уже писал выше.
Если учесть, что проектам альтернативных серверов (lighttpd, nginx и пр.) около 10 лет, и они сравнительно недавно стали теснить Apache — то что уж говорить про переход на FastCGI? Принцип «не трогай, пока работает», очень силён, а в некоторых случаях не лишён смысла.
- И потом код ядра это же еще не все. Будет куча сторонних (или своих) модулей.
Никто ведь не мешает собственные модули под Phalcon на PHP писать?
Не в сети
На FastCGI действительно многие перешли, связка nginx+php_fpm на моих сайтах дала увеличение производительности в 10 раз по сравнению с Apache+mod_php, как я уже писал выше.
И в этом случае преимущества Phalcon стремятся к нулю
Если учесть, что проектам альтернативных серверов (lighttpd, nginx и пр.) около 10 лет, и они сравнительно недавно стали теснить Apache — то что уж говорить про переход на FastCGI? Принцип «не трогай, пока работает», очень силён, а в некоторых случаях не лишён смысла.
Я к тому, что проблемы 90% сайтов это слой работы с БД. И первым делом оптимизацию надо начинать с этого. А в фальконе этот слой никак не улучшается. И в принципе никак не может быть улучшен.
Код ядра не покроет всех нужд, поэтому по любому будем тянуть свои/чужие модули на PHP, что снижает выигрыш во время инициализации.
Проблемы с инициализацией можно частично победить ядром в виде phar архива. Тогда не нужно будет тянуть кучу файлов при старте скрипта. Ну или fpm. Я просто не вижу задач, которые бы не решались другими способами. А минусы очень явные — усложнение разработки (прежде всего для крупных проектов), усложнение отладки. Зачем мне еще один черный ящик поверх PHP??
Не в сети
Люди, в о чём, какой FastCGI в PHP ?
Настоящий FastCGI - это единоразовая инициализация всех данных, и затем уже работа всех данных без последующей инициализации приложения, и даже без десериализации кэша. Прямо с данными, которые уже в оперативке.
Такое умеют только phpdaemon, hhvm и несколько других, и это требует серьёзной переделки самого приложения, которые обычно разрабатывались с подходом "грузим всё при старте и всё уничтожается при выходе".
fpm этого не умеет. То что там называется FastCGI, на самом деле является по сути обычным CGI с полной инициализацией при каждом запросе.
И потом, я не верю что выбрасывание Apache ускорило php в 4 раза, так не бывает, либо был криво настроенный апач. На реальных php приложениях разницы по скорости между apache/nginx нет. Есть разница в потреблении памяти, в отдаче медленным клиентам, но по скорости не-статики разницы нет, это видно по многочисленным бенчмаркам.
Мастер
- То что там называется FastCGI, на самом деле является по сути обычным CGI с полной инициализацией при каждом запросе.
Это «ускоренный» CGI, естественно с инициализацией при каждом запросе из-за архитектуры PHP. Но более быстрая работа сервера заслуга не столько его, сколько nginx, lighttpd и пр. О причинах ты всё правильно написал.
- На реальных php приложениях разницы по скорости между apache/nginx нет.
Совершенно не правда. У меня было несколько высоконагруженных серверов и разница при переходе была 4-10 раз. nginx+fpm.
Не знаю насчёт бенчмарков, но по-моему это общеизвестный факт, что Apache сам по себе тяжёл и nginx сотоварищи снимают многие его ограничения. Иначе бы все использовали его и не искали новых путей.
Не в сети
}
Это "ускоренный" CGI, естественно с инициализацией при каждом запросе из-за архитектуры PHP.
phpDaemon, hhvm, kphp позволяют писать демонов без инициализации между запросами. То есть всегда можно хранить состоение в памяти, и не использовать кэш, который ест память и тратит кучу ресурсов на сериализацию/десериализацию.
Совершенно не правда. У меня было несколько высоконагруженных серверов и разница при переходе была 4-10 раз. nginx+fpm.
Можно подробнее ? Сколько ms было в среднем, страница генерировалась очень быстро или там была тяжёлая логика ? Или может быть использовались специфичные для fpm функции, как фоновые функции после отдачи страницы ? И я надеюсь мы именно о php говорим, без учёта статики ?
Я очень хочу посмотреть на этот бенчмарк, потому что нигде больше таких различий нет.
http://www.eschrade.com/page/why-is-fas … w-mod_php/ здесь например apache быстрее nginx.
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)