время генерации страницы
- Автор темы Духовность™
- Дата начала
TutanXamoN
Новичок
fixxxer
Сенкс) Ибо я уже площадку тестовую разворачивать начал.
Сенкс) Ибо я уже площадку тестовую разворачивать начал.
TutanXamoN
Новичок
Дык я ведь не успокоился)
Видимо в который раз требуется ликбез ) Попробую изложить как можно доступнее.
CGI это очень простая штука - каждый раз запускается php. На обработку каждого запроса. Думаю всем понятно, что запуск программы это длительная операция, хотите померьте exec в unix. Плюс к тому, при запуске php необходимы действия по инициализации, которые тоже не такие уж легкие.
Fastcgi это такая штука (мы рассматриваем только внешний fastcgi). Php запускается как fastcgi-сервер. Грубо говоря, примерно как и веб сервер - только протокол не http а fastcgi %) в цикле принимаем соединения, обрабатываем и отдаем результат. На обработку одного соединения нужен один процесс, потому для распараллеливания запускается несколько копий php - воркеров - таким образом, чтобы не было случаев, когда ответить долго некому (все воркеры заняты, а очередь входящих соединений копится и переполняется), но и чтобы не было слишком много воркеров (зря тратим ресурсы, если вдруг нахлынет пик соединений - получим неотвечающую системву с запредельным load average).
Apache+mod_php. Фактически - то же самое =) только соединения обрабатываются не fastcgi sapi, а апачом. Апач умеет число воркеров регулировать автоматически, но это уже детали не столь существенные.
Существенно то, что на самом деле - не совсем то же самое. В первом случае у нас помимо fastcgi висит веб сервер, обычно nginx, который и смотрит наружу и обрабатывает внешние соединения. Во втором случае, если вешать апач наружу, то может произойти "ой", когда у нас слишком много открытых соединений. На каждое соединение апачу нужен отдельный процесс - а теперь для наглядности представим себе 10 000 диалапщиков, которые к нам зашли - у нас висит 10 000 нехилых таких по размеру процессов апача, ОС жужжа свопом переключает туда-сюда контекст между 10 000 процессов, картина еще та. Почему используют nginx? Nginx все делает в одном процессе (для многоядерных серверов запускают столько процессов, сколько ядер) - он устроен как конечный автомат, и (тут я упрощаю совсем) занимается по сути обработкой очередей, и только делает быстрые операции по разбору http запросов и говорит операционной системе - а вот пошли этот файл в этот сокет. А тут вспоминаем оценку сложности: при раздаче ядром зависимость от числа соединений близка к O(const), если же раздавать кучей процессов переключаясь между ними, то чем больше переключений, тем больше мы процессорного времени теряем впустую, и получится там скорее всего что-то типа O(n^2). Так что - что получается - с бекенда же nginx по той же схеме вытягивает запрос в свой кэш, откуда медленно и печально раздает клиенту (раздает по сути ядро
). Тем, кто заинтересован в изложении этой темы более научном, чем мои жесты руками и подсчеты на пальцах, советую почитать http://groups.google.com/group/fido7.ru.unix.prog/browse_thread/thread/44db58f70be988ad
Парадоксально не так ли, я только что написал все то же самое, что в статье, которую выше дико раскритиковал) А вот почему.
Конечно же fastcgi ничего не ускоряет. Это cgi все замедляет, но его как атавизм времен, когда уже 5 соединений в секунду были чем-то немыслимым, и рассматривать нечего. Схема nginx + apache-mod_php так же эффективна как схема nginx+php-fpm, если речь не идет о маньячной оптимизации, когда становится критичным то, что апач вообще-то потяжелее php-fpm. Для мамбы это критично, для подавляющего большинства здесь присутствующих - нет, подавляющему большинству присутствующих для начала надо оптимизировать sql-запросы.
О бредовости сравнения с CGI думаю все уже поняли. Сравнение с перлом - в том смысле, что там приходится вручную разрабатывать fastcgi-обработчик, делать цикл приема соединений, счетчик, который сделает рестарт, когда мы наликали памяти.
Конечно, у такого подхода - когда все ручками - есть и преимущества - не надо каждый раз инициализировать одно и то же - но посчитайте время на эту инициализацию в своем приложении: оно либо мизерно, либо вам надо прочитать про кеширование и lazy load
Про акселераторы - это вообще другая история - не имеющая НИКАКОГО отношения к используемому SAPI. На самом деле это не они акселераторы, а в пхп "замедлятор": то, что, пока php-исходник не изменился, не надо каждый раз его компилировать в байткод, понятно последнему ламеру, а соответствующий функционал кастрирован явно из коммерческих соображений - надо же продавать zend-овский performance suite =) То, что лексический анализ - операция сложная и длительная, ясно любому, кто хоть раз в жизни писал парсеры.
CGI это очень простая штука - каждый раз запускается php. На обработку каждого запроса. Думаю всем понятно, что запуск программы это длительная операция, хотите померьте exec в unix. Плюс к тому, при запуске php необходимы действия по инициализации, которые тоже не такие уж легкие.
Fastcgi это такая штука (мы рассматриваем только внешний fastcgi). Php запускается как fastcgi-сервер. Грубо говоря, примерно как и веб сервер - только протокол не http а fastcgi %) в цикле принимаем соединения, обрабатываем и отдаем результат. На обработку одного соединения нужен один процесс, потому для распараллеливания запускается несколько копий php - воркеров - таким образом, чтобы не было случаев, когда ответить долго некому (все воркеры заняты, а очередь входящих соединений копится и переполняется), но и чтобы не было слишком много воркеров (зря тратим ресурсы, если вдруг нахлынет пик соединений - получим неотвечающую системву с запредельным load average).
Apache+mod_php. Фактически - то же самое =) только соединения обрабатываются не fastcgi sapi, а апачом. Апач умеет число воркеров регулировать автоматически, но это уже детали не столь существенные.
Существенно то, что на самом деле - не совсем то же самое. В первом случае у нас помимо fastcgi висит веб сервер, обычно nginx, который и смотрит наружу и обрабатывает внешние соединения. Во втором случае, если вешать апач наружу, то может произойти "ой", когда у нас слишком много открытых соединений. На каждое соединение апачу нужен отдельный процесс - а теперь для наглядности представим себе 10 000 диалапщиков, которые к нам зашли - у нас висит 10 000 нехилых таких по размеру процессов апача, ОС жужжа свопом переключает туда-сюда контекст между 10 000 процессов, картина еще та. Почему используют nginx? Nginx все делает в одном процессе (для многоядерных серверов запускают столько процессов, сколько ядер) - он устроен как конечный автомат, и (тут я упрощаю совсем) занимается по сути обработкой очередей, и только делает быстрые операции по разбору http запросов и говорит операционной системе - а вот пошли этот файл в этот сокет. А тут вспоминаем оценку сложности: при раздаче ядром зависимость от числа соединений близка к O(const), если же раздавать кучей процессов переключаясь между ними, то чем больше переключений, тем больше мы процессорного времени теряем впустую, и получится там скорее всего что-то типа O(n^2). Так что - что получается - с бекенда же nginx по той же схеме вытягивает запрос в свой кэш, откуда медленно и печально раздает клиенту (раздает по сути ядро
). Тем, кто заинтересован в изложении этой темы более научном, чем мои жесты руками и подсчеты на пальцах, советую почитать http://groups.google.com/group/fido7.ru.unix.prog/browse_thread/thread/44db58f70be988adПарадоксально не так ли, я только что написал все то же самое, что в статье, которую выше дико раскритиковал
) А вот почему.Конечно же fastcgi ничего не ускоряет. Это cgi все замедляет, но его как атавизм времен, когда уже 5 соединений в секунду были чем-то немыслимым, и рассматривать нечего. Схема nginx + apache-mod_php так же эффективна как схема nginx+php-fpm, если речь не идет о маньячной оптимизации, когда становится критичным то, что апач вообще-то потяжелее php-fpm. Для мамбы это критично, для подавляющего большинства здесь присутствующих - нет, подавляющему большинству присутствующих для начала надо оптимизировать sql-запросы.
О бредовости сравнения с CGI думаю все уже поняли. Сравнение с перлом - в том смысле, что там приходится вручную разрабатывать fastcgi-обработчик, делать цикл приема соединений, счетчик, который сделает рестарт, когда мы наликали памяти.
Конечно, у такого подхода - когда все ручками - есть и преимущества - не надо каждый раз инициализировать одно и то же - но посчитайте время на эту инициализацию в своем приложении: оно либо мизерно, либо вам надо прочитать про кеширование и lazy load Про акселераторы - это вообще другая история - не имеющая НИКАКОГО отношения к используемому SAPI. На самом деле это не они акселераторы, а в пхп "замедлятор": то, что, пока php-исходник не изменился, не надо каждый раз его компилировать в байткод, понятно последнему ламеру, а соответствующий функционал кастрирован явно из коммерческих соображений - надо же продавать zend-овский performance suite =) То, что лексический анализ - операция сложная и длительная, ясно любому, кто хоть раз в жизни писал парсеры.
AmdY конечно, есть опция, проверять ли дату изменения
triumvirat, а можешь заменить в configuration.php include_once на include и тоже выложить трейс?
-~{}~ 06.04.09 00:01:
кстати, -> Frontend_Article_View->__construct() в сумме работает 0,012 без базы и файлов
не многовато?
triumvirat, а можешь заменить в configuration.php include_once на include и тоже выложить трейс?
-~{}~ 06.04.09 00:01:
кстати, -> Frontend_Article_View->__construct() в сумме работает 0,012 без базы и файлов
не многовато?
Что касается упаковки в файл, то это все вопросы компромиссов.
На каком-то этапе константное время подгрузки огроменного байткода на каждый запрос превысит суммарное время, которое тратится на stat+подгрузку меньших по необходимости.
-~{}~ 06.04.09 01:22:
И, кстати, учитывая statcache в 5.2, получаем вообще экономию на спичках. Желающих тестировать предостерегу что тестировать надо хотя бы через аб, но уж никак не запуская консольный php и эмулировать реальные ситуации, а не больные фантазии типа 100000 файлов по 1 строке.
На каком-то этапе константное время подгрузки огроменного байткода на каждый запрос превысит суммарное время, которое тратится на stat+подгрузку меньших по необходимости.
-~{}~ 06.04.09 01:22:
И, кстати, учитывая statcache в 5.2, получаем вообще экономию на спичках. Желающих тестировать предостерегу что тестировать надо хотя бы через аб, но уж никак не запуская консольный php
и эмулировать реальные ситуации, а не больные фантазии типа 100000 файлов по 1 строке.
Минимизации чего? Есть ложь, есть большая ложь, а есть кривые бенчмарки, которые величайшая ложь. Надо не читать всякую ахинею а взять свой проект и проверить.
P.S. Недавно как раз с другом обсуждали, что если, отталкиваясь от общеизвестных фактов, "немножко" подменять понятия и подтвердить все красивыми бенчами (нарисованными ручками в екселе), а вдобавок еще и постить от сколь-либо авторитетного имени - можно протолкнуть в массы любой бред: у большинства людей (к сожалению) доверие к авторитетам и лень сильнее желания самостоятельно подумать и разобраться
Есть ложь, есть большая ложь, а есть кривые бенчмарки, которые величайшая ложь. Надо не читать всякую ахинею а взять свой проект и проверить.P.S. Недавно как раз с другом обсуждали, что если, отталкиваясь от общеизвестных фактов, "немножко" подменять понятия и подтвердить все красивыми бенчами (нарисованными ручками в екселе), а вдобавок еще и постить от сколь-либо авторитетного имени - можно протолкнуть в массы любой бред: у большинства людей (к сожалению) доверие к авторитетам и лень сильнее желания самостоятельно подумать и разобраться
vovanium
Новичок
fixxxer
Никто же не будет для небольшого сайта компании покупать выделенный сервак.
-~{}~ 06.04.09 13:24:
fixxxer
Для меня Котеров не авторитет, более того его статьи я нашел уже после этой темы, первое что попалось по поиску тестов множества иклюдов против минимального их количества. Да, и я же не спорю, в случаях когда все максимально закешировано, и отсутствует проверка модификации файлов, это разница может быть пренебрежимо мала, но пока что не у всех сайты работают в таком режиме...
Никто же не будет для небольшого сайта компании покупать выделенный сервак.
-~{}~ 06.04.09 13:24:
fixxxer
А думать уже не модно? Неужели непонятно что один и тот же код разбитый на много кусков, будет подключаться в любом случае медленнее, чем тот же объем кода в одном файле. Еще раз для тех кто читать не умеет, речь не о файлах которые подключаются по необходимости, а те которые подключаются всегда.
vovanium
Новичок
Вот ради интереса объединил 9 файлов pma в один (хотя там можно побольше объединить), в итоге получилось
pma_orig - оригинальный pma 3.1.3
pma_mod - оригинальный pma в котором 9 файлов объединены в один
eA mod 1 - eAccelerator c включенной проверкой модификации файлов
eA mod 0 - eAccelerator c выключенной проверкой модификации файлов
Т.е. даже с учетом того что тестилось все на локалке (Q6600 + 8 ГБ мозгов), разница видна около 3,5-6%, тестил ab -c5 -n 100 (данные усредненные, без учета первого запуска), причем разница при кэшировании даже больше.
Да можно сказать что разница в 6 мс не много, но это pma, к примеру моя cms на той же машине выполняется в среднем 31 мс.
Код:
pma_orig 28,86 r/s 173 ms
pma_mod 29,82 r/s 167 ms
pma_orig + eA mod 1 43,8 r/s 114 ms
pma_mod + eA mod 1 45,94 r/s 108 ms
pma_orig + eA mod 0 47,39 r/s 106 ms
pma_mod + eA mod 0 49,78 r/s 100 mspma_mod - оригинальный pma в котором 9 файлов объединены в один
eA mod 1 - eAccelerator c включенной проверкой модификации файлов
eA mod 0 - eAccelerator c выключенной проверкой модификации файлов
Т.е. даже с учетом того что тестилось все на локалке (Q6600 + 8 ГБ мозгов), разница видна около 3,5-6%, тестил ab -c5 -n 100 (данные усредненные, без учета первого запуска), причем разница при кэшировании даже больше.
Да можно сказать что разница в 6 мс не много, но это pma, к примеру моя cms на той же машине выполняется в среднем 31 мс.
vovanium
и что? это как раз экономия на спичках получается.
eA дает прирост менее 50%, далее в рамках погрешности данные.
далее: pma это работа с базой, что влияет на результаты теста. исключи ее)
для примера:
система AMD Phenom X4 9650, те же 8 гиг, диск сата, запущены иксы, айсвизель и прочая десктопная хренотень, которая может неслабо влиять на результаты.
база исключена мемкэшем. ab на другой машине. 20-22 файла в инклуд.
без eA 8-10 ms
с eA стабильно 4 ms
и то это далеко от правды, потому что все тесты синтетические.
посему есть мнение, что все подобные опережающие оптимизации в отрыве от реальных условий, есть фуфло.
если у тебя 300к хитов в сутки, то вообще не надо заморачиваться, есть более слабые места, устранение которых даст наибольший прирост производительности.
-~{}~ 06.04.09 16:01:
конечно же 300к хитов не есть хайлоад, тут вообще можно без особых оптимизаций жить )
и что? это как раз экономия на спичках получается.
eA дает прирост менее 50%, далее в рамках погрешности данные.
далее: pma это работа с базой, что влияет на результаты теста. исключи ее)
для примера:
система AMD Phenom X4 9650, те же 8 гиг, диск сата, запущены иксы, айсвизель и прочая десктопная хренотень, которая может неслабо влиять на результаты.
база исключена мемкэшем. ab на другой машине. 20-22 файла в инклуд.
без eA 8-10 ms
с eA стабильно 4 ms
и то это далеко от правды, потому что все тесты синтетические.
посему есть мнение, что все подобные опережающие оптимизации в отрыве от реальных условий, есть фуфло.
если у тебя 300к хитов в сутки, то вообще не надо заморачиваться, есть более слабые места, устранение которых даст наибольший прирост производительности.
-~{}~ 06.04.09 16:01:
конечно же 300к хитов не есть хайлоад, тут вообще можно без особых оптимизаций жить )