Форум dkLab и Denwer
Здесь общаются Web-разработчики.
Генеральный спонсор:
Хостинг «Джино»

49. Оптимизируем загрузку PHP-кода в 22 раза, или почему FastCGI не ускоряет PHP (Дмитрий Котеров)
Goto page 1, 2  Next
Author Message
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Mon May 12, 2008 1:13 am (написано за 7 секунд)
   Post subject: 49. Оптимизируем загрузку PHP-кода в 22 раза, или почему FastCGI не ускоряет PHP
Reply with quote

dklab.ru/chicken/nablas/49.html
Back to top
View user's profile Send private message Send e-mail
phprus
Участник форума



Joined: 25 Jul 2003
Posts: 162
Карма: 8
   поощрить/наказать

Location: Пермь

PostPosted: Mon May 12, 2008 7:43 am (спустя 6 часов 29 минут; написано за 5 минут 6 секунд)
   Post subject:
Reply with quote

Дмитрий Котеров
А где цифры?
Конкретно меня интересует в каком окружении происходило тестирование всего этого, сколько запросов и с какой загрузкой сервер мог обрабатывать следующие конфигурации: apache+mod_php, nginx+apache+mod_php и nginx+php+php-fpm
Я думаю для сравнительных тестов будет достаточно просто подергать какой-либо скрипт при помощи ab.

Такое ощущение, что не проводилось вообще никаких тестов сравнения производительности различных вариантов запуска php, так как цифры приведены только для сравнения наличия и отсутствия eAccelerator.

Кстати, а о каком мифическом fork'е идет речь в статье? И mod_php и php+php-fpm вполне обходятся без форка на каждый запрос в отличие от запуска скрипта как cgi.
Back to top
View user's profile Send private message Send e-mail
Юрий Насретдинов
Модератор



Joined: 13 Mar 2003
Posts: 8642
Карма: 198
   поощрить/наказать

Location: 007 495

PostPosted: Mon May 12, 2008 10:01 pm (спустя 14 часов 18 минут; написано за 2 секунды)
   Post subject:
Reply with quote

Зато fork делает apache.
Back to top
View user's profile Send private message Send e-mail
alecksey
Заглянувший



Joined: 12 May 2008
Posts: 1
Карма: 1
   поощрить/наказать


PostPosted: Mon May 12, 2008 10:49 pm (спустя 48 минут; написано за 3 минуты 22 секунды)
   Post subject:
Reply with quote

Уважаемый Дмитрий Кóтеров перед тем как писать данные статьи, пожалуйста попробуйте не брать первую же пропиариную тулсу.
Например xCache дает прирост до 400-500%, со всех остальных, в т.ч. eAccelerator.

Ну и под конец, пример с 4.9 мб подгрузкой мало вероятен, а если и вероятен, тому кто это писал нужно бить по рукам.
Извините конечно за грубость... Но статья явно писалась спонтанно. Может перепишете? )
Back to top
View user's profile Send private message
phprus
Участник форума



Joined: 25 Jul 2003
Posts: 162
Карма: 8
   поощрить/наказать

Location: Пермь

PostPosted: Tue May 13, 2008 11:47 am (спустя 12 часов 58 минут; написано за 2 минуты 30 секунд)
   Post subject:
Reply with quote

Юрий Насретдинов wrote:
Зато fork делает apache.
Этот fork существует в любом случае (как я понимаю вы про порождение апачем дочернего процесса для обработки запросов). Однако если php используется как модуль или как FastCGI, то других fork'ов не будет, а в случае php как cgi будет еще один fork.

Так что мне все-еще не понятно о каком-же fork'е идет речь в статье.
Back to top
View user's profile Send private message Send e-mail
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Wed May 21, 2008 1:20 am (спустя 7 дней 13 часов 32 минуты; написано за 8 минут 8 секунд)
   Post subject:
Reply with quote

Тестировал я, замеряя время в начале и в конце скрипта и вычитая второе из первого. Сравнительные цифры в миллисекундах в статье приводятся (Вы их не заметили, наверное; они выделены жирным). Там же написано, почему разница в скорости между mod_php и nginx+fastcgi минимальна, так что я не вижу смысла даже ее тестировать - эффект все равно потонет во времени загрузки 5-мегабайтного файла. Кстати, читаем в FAQ по php-fpm php-fpm.anight.org/faq.html :

Q: Влияет ли php-fpm на скорость обработки запросов ?
A: Нет, не влияет. Однако, если Вы используете специальные фичи, выполнение некоторых запросов можно немного ускорить.


Если тестировать при помощи ab, результат получается очень похожим (что неудивительно). Попробуйте, если не верите. Вот мои результаты:

- когда выключен eAccelerator и все файлы грузятся по отдельности:
# ab -c 5 -n 100 http://...
Requests per second: 3.26 [#/sec] (mean)
Time per request: 1535.112 [ms] (mean)

- когда все включено и файлы слиты:
# ab -c 5 -n 100 http://...
Requests per second: 42.91 [#/sec] (mean)
Time per request: 116.521 [ms] (mean)

Здесь прирост в 13 раз, а не в 22. Но скрипт через microtime() и getrusage() говорит, что потратил на свое выполнение 30 мс, а не 42. Вывод - 12 мс тратится уже после того, как скрипт отработал (подозреваю, что в методе очистки пулов Apache). Так что да, в статье можно было бы написать, что под большой нагрузкой, когда load average превышает количество процессоров, ускорение не в 22 раза, а в 13.


Что касается xCache, то его проверял один мой знакомый, и он не выявил значительного ускорения по сравнению с eAccelerator. Возможно, где-то он дает еще бОльший прирост, чем eAccelerator, но - явно не в похожем тесте. Опять же - попробуйте.

Статью, конечно, можно переписать, однако получится в точности то же самое, что уже написано. Смысл?


Кстати говоря, архитектура машины, похоже, оказывает влияние на пропорции ускорения. На более мощном linux-сервере ускорение самой процедуры загрузки (т.е. выдаваемое по microtime() или getrusage()), например, было не в 22 раза, а "всего лишь" в 20 (с 518 до 26 мс).
Back to top
View user's profile Send private message Send e-mail
phprus
Участник форума



Joined: 25 Jul 2003
Posts: 162
Карма: 8
   поощрить/наказать

Location: Пермь

PostPosted: Wed May 21, 2008 10:40 am (спустя 9 часов 19 минут; написано за 3 минуты 41 секунду)
   Post subject:
Reply with quote

Дмитрий Котеров wrote:
Тестировал я, замеряя время в начале и в конце скрипта и вычитая второе из первого.
А вот теперь понятно как именно Вы тестировали. В таком случае не удивительно что скорость исполнения скриптов никак не поменялась, так как она вообще от SAPI не зависит.
Дмитрий Котеров wrote:
Там же написано, почему разница в скорости между mod_php и nginx+fastcgi минимальна, так что я не вижу смысла даже ее тестировать
А вы всетаки попробуйте. Так как nginx при отдаче контента потребляет меньше ресурсов процессора и памяти чем apache, то сэкономленное процессорное время и память могут использоваться скриптами, что позволит несколько уменьшить время отклика сервера.
Back to top
View user's profile Send private message Send e-mail
Vitaly Puzrin
Заглянувший



Joined: 09 Mar 2006
Posts: 16
Карма: 2
   поощрить/наказать


PostPosted: Thu May 22, 2008 8:19 am (спустя 21 час 39 минут; написано за 13 минут 50 секунд)
   Post subject:
Reply with quote

Про FCGI очень неаккуратно написано.

Абстрактно FCGI действительно не быстрее mod_php. НО (!) очень сильно оптимизируется использование памяти и ресурсов.

Например, по сети есть куча руководств по тюнингу mysql. И там написано что для загруженных серверов надо увеличивать количество коннектов чуть ли не до 300. Дык вот, если используется FCGI, то количество процессов ограничено, и 20 коннектов хватает за глаза. А это значит, не расходуется память под буферы и т.д.

Это только совсем очевидный пример. Плюс, апач надо бы на nginx или lighttpd менять. В сумме как нефик делать наковырять выигрыш в пару гигабайт памяти (на 4-гигабайтном сервере). В самом простом случае они пускаются под кэш файловой системы (к примеру, он активно используется для таблиц myisam).

Итого получаем, что прямого выигрыша как бы нет, а косвенный - в разы.

По акселераторам - EA единственный, который не поддерживает shm для хранения переменных. В отличие от xcache и APC. Загрузку кода они ускоряют примерно одинаково (плюс-минус лапоть), но внутри скриптов часто есть еще второй уровень оптимизации, там EA полностью пролетает.

В общем, какая-то слишком сумбурная набла. Формально вроде все верно, а с практической точки зрения ляпов много. Начиная с того, что я бенчмарки без акселератора вообще бы не делал. Потому что таких конфигураций на нормальном продакшене просто нет (почили в бозе за старостью лет). Вам ведь не пришло в голову мерять разницу в производительности между php5 и php3 :)
Back to top
View user's profile Send private message
Юрий Насретдинов
Модератор



Joined: 13 Mar 2003
Posts: 8642
Карма: 198
   поощрить/наказать

Location: 007 495

PostPosted: Thu May 22, 2008 9:13 am (спустя 54 минуты; написано за 2 секунды)
   Post subject:
Reply with quote

Хотел бы добавить лишь одно маленькое возражение предыдущему оратору: почему-то мне кажется, что люди, которые каждый день работают на высоконагруженных серверах, не будут употреблять слова "нормальный production", "давно выбросить машину было пора", и т.д... Поэтому лично меня Ваше сообщение лишь возмущает, и полезной информации я могу извлечь из сообщения еще меньше, чем из статьи (хотя Вы пишете, что там все неправильно). Это мое мнение, конечно... Но попробуйте приводить более весомые аргументы в пользу своей точки зрения, тогда и реакция будет намного теплее.
Back to top
View user's profile Send private message Send e-mail
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Thu May 22, 2008 11:00 pm (спустя 13 часов 47 минут; написано за 4 минуты 49 секунд)
   Post subject:
Reply with quote

phprus wrote:
Так как nginx при отдаче контента потребляет меньше ресурсов процессора и памяти чем apache, то сэкономленное процессорное время и память могут использоваться скриптами, что позволит несколько уменьшить время отклика сервера.
Цифры - в студию, пожалуйста.

Только не на скрипте типа "hello, world" (про него-то и так ясно, что разница может быть в разы, хотя все равно не понятно, зачем "hello, world" вообще оптимизировать), а на реальной системе, в реальном крупном проекте, где число строк кода исчисляется десятками тысяч. Мое утверждение состоит лишь в том, что на фоне времени работы такого скрипта любые выигрыши единиц миллисекунд, которые дает FastCGI (кстати, это вроде бы не одно и то же, что FCGI, хотя похоже), просто утонут.
Vitaly Puzrin wrote:
По акселераторам - EA единственный, который не поддерживает shm для хранения переменных. В отличие от xcache и APC. Загрузку кода они ускоряют примерно одинаково (плюс-минус лапоть), но внутри скриптов часто есть еще второй уровень оптимизации, там EA полностью пролетает.
Ну, довольно спорное утверждение.

Во-первых, есть memcached, громадный плюс которого в том, что он кэширует данные ДЛЯ ВСЕГО КЛАСТЕРА. А кэш в оперативке - только для одной веб-машины. Почувствуйте разницу, как говорится.

Ну и во-вторых, поддерживает ли хотя бы один из акселераторов, имеющих доступ к шаред-памяти, алгоритм LRU (вытеснение давно неиспользуемых данных, который используется в memcached)? Если нет, то тогда он очень мало смысла имеет вообще, потому что слежение за устареванием кэша быстро становится большой головной болью.
Back to top
View user's profile Send private message Send e-mail
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Thu May 22, 2008 11:58 pm (спустя 57 минут; написано за 10 минут 13 секунд)
   Post subject:
Reply with quote

Спасибо другу, который провел кропотливые измерения производительности для чистого PHP, eAccelerator и xCache на тех 5 мегабайтах кода, которые я описываю в статье. Публикую здесь результаты. Тестировалось при помощи ab, 100 запросов, 10 параллельных. Видно, что xCache не только не "быстрее в 5 раз", но и сильно отстает от eAccelerator.

# ab -n 100 -c 10

Чистый PHP без акселераторов:
- когда файлы грузятся по отдельности:
Requests per second: 3.69 [#/sec] (mean)

- когда файлы слиты в один 5-мегабайтный:
Requests per second: 4.85 [#/sec] (mean)


xCache
- когда файлы грузятся по отдельности:
Requests per second: 9.41 [#/sec] (mean)

- когда файлы слиты в один 5-мегабайтный:
Requests per second: 34.54 [#/sec] (mean)


eAccelerator
- когда файлы грузятся по отдельности:
Requests per second: 14.04 [#/sec] (mean)

- когда файлы слиты в один 5-мегабайтный:
Requests per second: 42.86 [#/sec] (mean)


В итоге получаем ускорение, равное 42.86 / 3.69 = 11.6 раз. Как я уже писал выше, скорость съедает процедура очистки пулов, которую проводит Apache при завершении скрипта. Реальная же скорость загрузки кода увеличивается в 22 раза, как и описано в статье.
Back to top
View user's profile Send private message Send e-mail
Vitaly Puzrin
Заглянувший



Joined: 09 Mar 2006
Posts: 16
Карма: 2
   поощрить/наказать


PostPosted: Fri May 23, 2008 6:54 pm (спустя 18 часов 56 минут; написано за 20 минут 7 секунд)
   Post subject:
Reply with quote

Дмитрий Котеров wrote:
Мое утверждение состоит лишь в том, что на фоне времени работы такого скрипта любые выигрыши единиц миллисекунд, которые дает FastCGI (кстати, это вроде бы не одно и то же, что FCGI, хотя похоже), просто утонут.
Насчет скорости работы FCGI как идеального шарообразного коня в вакууме никто и не спорит. Вам отмечают, что вы упорно игнорируете тот факт, что использование легковесного сервера (nginx/lighttpd/zeus) с FCGI дает огромный выигрыш по памяти, по сравнению с apache с mod_php. Огромный - это скажем 2 гигабайта из 4. Вполне реальная цифра.

Насколько от этого ускорится mysql, который память очень любит, и все остальное, я не представляю как тестировать. На моем проекте, по субъективным ощущением, удалось обслужить раза в 2 большую нагрузку. На apache держался до последнего, пока сервер не стал по 2 раза в день в клинч входить из-за свопа. Дело было давно, форум IPB на 2000 уников в сутки, сервер (только не смейтесь) на целерон 2000 и 2 гига памяти.
Дмитрий Котеров wrote:
Во-первых, есть memcached, громадный плюс которого в том, что он кэширует данные ДЛЯ ВСЕГО КЛАСТЕРА. А кэш в оперативке - только для одной веб-машины. Почувствуйте разницу, как говорится.

Ну и во-вторых, поддерживает ли хотя бы один из акселераторов, имеющих доступ к шаред-памяти, алгоритм LRU (вытеснение давно неиспользуемых данных, который используется в memcached)? Если нет, то тогда он очень мало смысла имеет вообще, потому что слежение за устареванием кэша быстро становится большой головной болью.
Достоинств memcached никто не отрицает. Я даже не буду холиварить на предмет того, что shm быстрее memcached. Просто если сервер один, а это частая ситуация, проще поставить xcache или APC, укокошив сразу двух зайцев.

Насчет LRU мамой клясться не буду, не проверял. Там есть TTL, для стандартных задач вроде форума хватает за глаза. С чисткой проблем не было. Просто я не пытался занять в кеше больше памяти, чем там есть. Это все довольно быстро мониторится.

Еще раз подчеркиваю - формально в вашей набле ошибок нет. Просто акценты смещены в несколько странную, я бы даже сказал, устаревшую область. "... или почему FastCGI не ускоряет PHP" - очень стремная формулировка. Отдельно php не ускоряет, а сервер в целом - ускоряет, и весьма заметно. Просто новичков жалко, которые не понимают, для чего переходят на FCGI и легковесные вебсерверы. Начнут ведь в первую очередь тратить время на склеивание скриптов.

Тут есть другие бенчмарки для акселераторов, малость устаревшие, если интересно:
itst.net/wp-content/uploads/2006/10/PHP%20Bytecode%20Cacher%20Review.html

А это ссылка для "истории"
itst.net/654-php-on-fire-three-opcode-caches-compared
Back to top
View user's profile Send private message
umask
Guest





Карма: 388
   поощрить/наказать


PostPosted: Fri May 23, 2008 9:58 pm (спустя 3 часа 3 минуты; написано за 23 минуты 11 секунд)
   Post subject:
Reply with quote

[quote="Vitaly Puzrin"]
Дмитрий Котеров wrote:
Еще раз подчеркиваю - формально в вашей набле ошибок нет. Просто акценты смещены в несколько странную, я бы даже сказал, устаревшую область. "... или почему FastCGI не ускоряет PHP" - очень стремная формулировка. Отдельно php не ускоряет, а сервер в целом - ускоряет, и весьма заметно. Просто новичков жалко, которые не понимают, для чего переходят на FCGI и легковесные вебсерверы. Начнут ведь в первую очередь тратить время на склеивание скриптов.
а ни разу не пробовали запускать фронтом nginx (или лёгкий сервер и балансер), а бэкэндом apache? Не?

Ваши утверждения абсурдны, поскольку легковесному серверу всё равно кто бэкэнд - по HTTP или по Fast-CGI он работает. Тупо меняется протокол.

Суть в том, что легковесный сервер забирает ответ бэкэнда в свои буфера и при этом бэкэнд освобождается, т.е. может выполнять следующий запрос. Вот и вся экономия памяти.
Другое дело, что легковесный сервер тратит меньше ресурсов при отдаче данных из своих буферов в сеть.
Back to top
Vitaly Puzrin
Заглянувший



Joined: 09 Mar 2006
Posts: 16
Карма: 2
   поощрить/наказать


PostPosted: Fri May 23, 2008 10:24 pm (спустя 26 минут; написано за 10 минут 49 секунд)
   Post subject:
Reply with quote

Если keep-alive разруливается на легковесном фронтенде, а дальше стоит апач, то уменьшается количество процессов долго висящих в памяти и ее пожирающих (интерпретирующих php скрипты). Крайний случай - режим легковесного сервера с php-fcgi, когда количество процессов жестко фиксировано. Не вижу здесь ни какого абсурда. apache+mod_php на бакенде все равно будет больше процессов плодить, чем если напрямую php в FCGI загнать.

IMHO, дело не только в буферах. Если у вас пойдут одновременно 100 запросов страниц от разных клиентов, они все равно одновременно дойдут до бакенда с апачем. Это конечно лучше, чем если у апача еще картинок спросят, но все равно не идеально. Как апач с mod_php разрулит по памяти 100 одновременных запросов - одному аллаху известно. Сильно от конфигурации и версии апача зависит. В случае с FCGI имеем гарантию, что количество процессов с php фиксировано на уровне 5-10, а все что выше - в порядке общей очереди. То есть на пиковых загрузках не возникнет лишних накладных расходов, которые могут привести к свопу.
Back to top
View user's profile Send private message
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Sat May 24, 2008 12:54 pm (спустя 14 часов 30 минут; написано за 13 минут 36 секунд)
   Post subject:
Reply with quote

Ну вообще-то в Apache тоже можно установить на лимит числа порождаемых процессов, и сделать "в порядке общей очереди"...

На самом деле, здесь смешиваются две проблемы:

1. Проблема ускорения работы PHP.
2. Проблема "медленных клиентов".

Статья - про первый пункт исключительно.

Что касается второго пункта, скажу о нем чуть подробнее и отделю мух от котлет. "Медленный клиент" - это соединение, которое открывает браузером, скажем, dialup-пользователь, и которое из-за этого висит по 5-6 секунд, заставляя работающий процесс apache ждать. Или же клиент закачивает большой файл. Закачка может занять несколько минут, и все это время апач будет висеть в памяти и ждать. Из-за этого увеличивается необходимое число одновременно работающих процессов с mod_php и, соответственно, расходы памяти.

Так вот, проблема медленных соединений можно спокойно решать отдельно, установив так называемый reverse proxy (nginx, lighttpd, pound и т.д.). Reverse proxy работает следующим образом: он ждет соединения с клиентом, а когда тот полностью передал данные, быстро открывает соединение с сервером, посылает туда данные, забирает ответ в свой буфер и уже отдает его медленному клиенту так долго, как тот этого хочет (при зтом сервер не блокируется и может обрабатывать уже другие запросы). Таким образом, reverse proxy делает "медленных клиентов" быстрыми.

Также часто делают, чтобы именно reverse proxy упаковывал трафик в SSL, а веб-серверы ничего об SSL не знают и отдают контент неупакованным (для улучшения производительности).

Когда используют nginx + FastCGI-PHP, эта связка одновременно как бы является и сервером, и reverse proxy для снижения числа одновременных соединений. Т.е. и мухи, и котлеты - в одном месте. Люди часто это не понимают и считают, что "это nginx такой быстрый сервер", хотя в действительности дело просто в технологии "убыстрения" медленных клиентов, которую можно сделать любыми другими инструментами.

Из этой же проблемы растут ноги, когда говорят "статику надо отдавать nginx-ом". Статика сама по себе вообще не проблема: даже самый захудалый apache на самой захудалой машине способен обрабатывать несколько тысяч статических запросов в секунду. Если у вас не фотохостинг, этого достаточно за глаза: как вы понимаете, отдавать 10000 запросов статики в секунду через apache или 11000 запросов в секунду через nginx (т.к. нагрузка идет в основном на диски) - разницы для скорости проекта практически никакой нет. Выигрыш с nginx тут опять только из-за "медленных" клиентов, которые "срезаются" при помощи reverse proxy.

Итак, если ставится несколько апачей, а над ними - один reverse proxy + балансировщик (nginx и pound умеют не только проксировать, но еще и распределять запросы по нескольким машинам), можно особенно не думать насчет какой-то особенной отдачи статики. Можно ее отдавать теми же самыми апачами. Из-за того, что все соединения стали "быстрыми", разница будет совсем маленькой.

(Опять же, случаи с фотохостингом или сервисом генерации географических карт я не рассматриваю, там все по-другому.)
Back to top
View user's profile Send private message Send e-mail
Vitaly Puzrin
Заглянувший



Joined: 09 Mar 2006
Posts: 16
Карма: 2
   поощрить/наказать


PostPosted: Sat May 24, 2008 4:25 pm (спустя 3 часа 31 минуту; написано за 12 минут 36 секунд)
   Post subject:
Reply with quote

Ну да, все верно. Может, дописать к набле комментарий, чтобы новичков не смущать? Если б вы сказали, что рассматриваете что-то кластероподобное из нескольких серверов с входящим прокси, и вопросов бы ни каких не возникло.

Я прошу прощения, что погорячился насчет апача. Если он на бакенде стоит и только php-скрипты вертит, то можно количество процессов апача ограничить в пару десятков, чтобы остальное в очередь вставало. Получится примерно тот же эффект, что от FastCGI - грамотное расходование памяти.
Back to top
View user's profile Send private message
umask
Guest





Карма: 388
   поощрить/наказать


PostPosted: Sat May 24, 2008 5:46 pm (спустя 1 час 20 минут; написано за 14 минут 15 секунд)
   Post subject:
Reply with quote

Vitaly Puzrin wrote:
Ну да, все верно. Может, дописать к набле комментарий, чтобы новичков не смущать? Если б вы сказали, что рассматриваете что-то кластероподобное из нескольких серверов с входящим прокси, и вопросов бы ни каких не возникло.

Я прошу прощения, что погорячился насчет апача. Если он на бакенде стоит и только php-скрипты вертит, то можно количество процессов апача ограничить в пару десятков, чтобы остальное в очередь вставало. Получится примерно тот же эффект, что от FastCGI - грамотное расходование памяти.
и не стоит забывать об очень важной особенности апача - extended status.
Без такого mod_status крайне трудно понять какой именно скрипт поедает процессор и сколько работает.

У php fast-cgi такой возможности нет. Именно поэтому на бэкэндах использую апач.
Back to top
KoT
Guest





Карма: 388
   поощрить/наказать


PostPosted: Mon May 26, 2008 7:15 pm (спустя 2 дня 1 час 28 минут; написано за 15 минут 3 секунды)
   Post subject:
Reply with quote

umask wrote:
и не стоит забывать об очень важной особенности апача - extended status.
Без такого mod_status крайне трудно понять какой именно скрипт поедает процессор и сколько работает.

У php fast-cgi такой возможности нет. Именно поэтому на бэкэндах использую апач.
простите, а зачем это надо? Если все это есть у nginx :))

sysoev.ru/nginx/docs/http/ngx_http_upstream.html

$upstream_response_time — в переменной хранятся времена ответов серверов в секундах с точностью до миллисекунд. Несколько ответов также разделяются запятыми и двоеточиями.

все это пишется в логи и потом красиво парсится и делается отчет. А апач так умеет? :)
Back to top
umask
Guest





Карма: 388
   поощрить/наказать


PostPosted: Mon May 26, 2008 11:36 pm (спустя 4 часа 20 минут; написано за 19 минут 45 секунд)
   Post subject:
Reply with quote

KoT wrote:
umask wrote:
и не стоит забывать об очень важной особенности апача - extended status.
Без такого mod_status крайне трудно понять какой именно скрипт поедает процессор и сколько работает.

У php fast-cgi такой возможности нет. Именно поэтому на бэкэндах использую апач.
простите, а зачем это надо? Если все это есть у nginx :))

sysoev.ru/nginx/docs/http/ngx_http_upstream.html

$upstream_response_time — в переменной хранятся времена ответов серверов в секундах с точностью до миллисекунд. Несколько ответов также разделяются запятыми и двоеточиями.

все это пишется в логи и потом красиво парсится и делается отчет. А апач так умеет? :)
ну а фронтом стоит nginx, который как раз такое тоже пишет :)

Расскажите, как через upstream_response_time вы будете искать скрипт, который работает по 5 минут? :)
Варианты:
1. если в nginx стоит таймаут на ожидание ответа апстрима, то в логе будет сообщение о таймауте (gateway timeout) и понять завершился или нет скрипт - нельзя. Более того, нельзя точно сказать сколько этот скрипт ещё будет выполнятся.
2. если таймаут в п.1 слишком большой, то nginx в логе ничего не запишет, пока не получит ответ апстрима или пока не случится пресловутый таймаут.

И не дело это nginx'а следить за тем, что и как работает на бэкэндах. Да, замерять производительность можно, но при высоких нагрузках бывает что и лог отключают (говорим про nginx, который может проксировать запросы на сотни или даже тысячи апстримов).
Back to top
phprus
Участник форума



Joined: 25 Jul 2003
Posts: 162
Карма: 8
   поощрить/наказать

Location: Пермь

PostPosted: Tue May 27, 2008 6:46 am (спустя 7 часов 10 минут; написано за 1 минуту 28 секунд)
   Post subject:
Reply with quote

umask wrote:
Расскажите, как через upstream_response_time вы будете искать скрипт, который работает по 5 минут? :)
Недавно вышел php-fpm 0.5.9-rc1 в котором появилась очень интересная функция:
Quote:
request_terminate_timeout - таймаут (в секундах) для исполнения php запроса,
после которого воркер будет принудительно перезапущен. Это то, что раньше
называлось request_execution_timeout и не работало.

request_slowlog_timeout - таймаут (в секундах) для исполнения php запроса,
после которого в отдельный лог сохранится php backtrace того места в скрипте,
на котором, возможно, подвис запрос.

slowlog - имя файла для этого лога.
Качать тут: php-fpm.anight.org/downloads/test/
Back to top
View user's profile Send private message Send e-mail
KoT
Guest





Карма: 388
   поощрить/наказать


PostPosted: Tue May 27, 2008 1:54 pm (спустя 7 часов 7 минут; написано за 3 минуты 52 секунды)
   Post subject:
Reply with quote

umask, простите, вы вообще поняли, что сказали? :)

вырезка из access.log
...
85.17.155.132 - - [27/May/2008:14:40:45 +0400 "2.861" "0.846"] GET /?option=com_smf&Itemid=44&action=printpage;topic=8.0 HTTP/1.0 "200" 296445 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.0" "-"
38.99.44.103 - - [27/May/2008:14:43:16 +0400 "18.194" "18.193"] GET /index.php?option=com_content&task=view&id=93&Itemid=51&limit=1&limitstart=130 HTTP/1.0 "200" 14678 "-" "Mozilla/5.0 (Twiceler-0.9 www.cuill.com/twiceler/robot.html)" "-"
...
Quote:
И не дело это nginx'а следить за тем, что и как работает на бэкэндах. Да, замерять производительность можно, но при высоких нагрузках бывает что и лог отключают (говорим про nginx, который может проксировать запросы на сотни или даже тысячи апстримов).
Да, вы правы, это дело программера отлавливать все ошибки на стадии тестирования, а не выкладывать сырой проект на продакш сервер.

У меня фронтэнд для динамики (только php скрипты) в среднем обрабатывает 22-25кк запросов в день. Отключать логи я не собираюсь, т.к. места хватает и нагрузки на диск я не наблюдаю :)
Back to top
umask
Guest





Карма: 388
   поощрить/наказать


PostPosted: Tue May 27, 2008 8:51 pm (спустя 6 часов 57 минут; написано за 5 минут 15 секунд)
   Post subject:
Reply with quote

phprus wrote:
umask wrote:
Расскажите, как через upstream_response_time вы будете искать скрипт, который работает по 5 минут? :)
Недавно вышел php-fpm 0.5.9-rc1 в котором появилась очень интересная функция:
Quote:
request_terminate_timeout - таймаут (в секундах) для исполнения php запроса,
после которого воркер будет принудительно перезапущен. Это то, что раньше
называлось request_execution_timeout и не работало.

request_slowlog_timeout - таймаут (в секундах) для исполнения php запроса,
после которого в отдельный лог сохранится php backtrace того места в скрипте,
на котором, возможно, подвис запрос.

slowlog - имя файла для этого лога.
Качать тут: php-fpm.anight.org/downloads/test/
не спорю - круто.

как будет релиз, через версию можно будет попробовать.
Очень странно автор php-fpm отзывается о включении кода его проекта в официальный php.
Да и не факт, что автор будет своё детище поддерживать столько, сколько мне нужно.

Скажем так, я придерживаюсь позиции RedHat - использую то, в поддержке чего со стороны разработчика или некой компании уверен. Например, если разработчик какого-либо проекта несподобится написать патч, то RedHat сделает это за него сама.
Back to top
umask
Guest





Карма: 388
   поощрить/наказать


PostPosted: Tue May 27, 2008 9:06 pm (спустя 14 минут; написано за 13 минут 42 секунды)
   Post subject:
Reply with quote

KoT wrote:
 простите, вы вообще поняли, что сказали? :)

вырезка из access.log
...
85.17.155.132 - - [27/May/2008:14:40:45 +0400 "2.861" "0.846"] GET /?option=com_smf&Itemid=44&action=printpage;topic=8.0 HTTP/1.0 "200" 296445 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.0" "-"
38.99.44.103 - - [27/May/2008:14:43:16 +0400 "18.194" "18.193"] GET /index.php?option=com_content&task=view&id=93&Itemid=51&limit=1&limitstart=130 HTTP/1.0 "200" 14678 "-" "Mozilla/5.0 (Twiceler-0.9 www.cuill.com/twiceler/robot.html)" "-"
...
Да, как выглядят логи я представляю. Спасибо, что публике представили.

Что я сказал - я понял. Представляем ситуацию, когда куча процессов httpd (ну или php-fcgi) кушает процессор, по логу прокси\балансера всё в порядке.
apache extended status даст представление что именно происходит и какой скрипт потребляет процессор и сколько.
В случае же с php-fcgi поможет его перезапуск или уменьшение таймута на чтение ответа бэкэнда (что не всегда приемлимо).
Так понятней?

Похоже, что именно вы не понимаете о чём говорите.
KoT wrote:
Да, вы правы, это дело программера отлавливать все ошибки на стадии тестирования, а не выкладывать сырой проект на продакш сервер.
Вообще, это дело только лишь тестеров. Никакой программист не способен оттестировать код так, как это делает профессионал по профессионально составленному тест-плану.

А ещё бывает, что скрипты получается сломать (из-за кривых рук программеров) и они начинают жить своей, очень интересной жизнью и подобная ситуация требует исследований, а не тупого перезапуска.
KoT wrote:
У меня фронтэнд для динамики (только php скрипты) в среднем обрабатывает 22-25кк запросов в день. Отключать логи я не собираюсь, т.к. места хватает и нагрузки на диск я не наблюдаю :)
3M хитов на динамике в сутки. Лог тоже пишется. Диск на балансере - обычный SATAII.
И что теперь? У кого-то может быть и 30M или 30G хитов в динамику.
Back to top
Антон Макаренко
Участник форума



Joined: 05 Feb 2004
Posts: 374
Карма: 31
   поощрить/наказать

Location: Киев

PostPosted: Sun Jun 01, 2008 4:40 am (спустя 4 дня 7 часов 33 минуты; написано за 24 секунды)
   Post subject:
Reply with quote

Quote:
Начнут ведь в первую очередь тратить время на склеивание скриптов.
Извините, что перебиваю дискуссию профессионалов, я вот написал склеивающий __autoload() (forum.dklab.ru/viewtopic.php?p=156550#156550) и получил тем самым массу удовольствия.
Back to top
View user's profile Send private message Send e-mail
Alexey V. Karagodov
Guest





Карма: 388
   поощрить/наказать


PostPosted: Thu Jun 19, 2008 10:40 am (спустя 18 дней 6 часов 15 секунд; написано за 1 минуту 12 секунд)
   Post subject:
Reply with quote

к примеру мне так и не понятно, чем автору nginx+php-fpm не угодил
ни особых цифр ни каких то подробных описаний тестов, ничего ...
просто какое-то "фи" в адрес нескольких хорошо работающих продуктов
Back to top
poforg
Guest





Карма: 388
   поощрить/наказать


PostPosted: Thu Jun 19, 2008 5:36 pm (спустя 6 часов 55 минут; написано за 6 минут 52 секунды)
   Post subject:
Reply with quote

umask wrote:
Очень странно автор php-fpm отзывается о включении кода его проекта в официальный php.
"До включения в официальный php в php-fpm должен появиться стабильный dynamic process manager и API как минимум."
Что вам кажется странным в этой позиции ?
Back to top
alex946
Заглянувший



Joined: 23 Sep 2005
Posts: 3
Карма: 0
   поощрить/наказать


PostPosted: Thu Jun 19, 2008 11:35 pm (спустя 5 часов 59 минут; написано за 3 минуты 23 секунды)
   Post subject: цифры в студию
Reply with quote

Не поленился, на сервере собрал оба варианта. тестировал на живом сайте при нескольких загруженных соседях, выполняя команды ab по очереди к каждому варианту. Сайт собирается из примерно полутора мегабайт скриптов.
Code (any language): скопировать код в буфер обмена
php 5.2.6 as nginx+FCGI+php-fpm+xcache+memcached

ab -n 1000 -c 5 http://test.***.ru/
Requests per second:    31.51 [#/sec] (mean)
Requests per second:    29.04 [#/sec] (mean)
Requests per second:    32.32 [#/sec] (mean)
Requests per second:    31.39 [#/sec] (mean)

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 3  1  40100  18260  55416 400568    0    0    66   715  165 9394 73 11 10  5
 6  1  40100  18352  55496 401324    0    0    20   796  164 8121 72 11 11  6
 7  0  40100  16444  55628 402220    0    0    49   764  203 8002 70 12 12  7
 5  0  40104  19448  55000 397064    0    0    24   683  220 7642 72 10 13  5
 3  2  40104  20716  55076 397700    0    0    40  1216  340 6902 52  9 28 11
 3  1  40104  20096  55152 398516    0    0    20   857  159 8644 69 11 13  7

Parse Time: 0.1049 s / 8 SQL
Memory 548984
SQL connection time 0.0064
SQL time 0.0028
PHP time 0.0957

php 5.2.6 as nginx+Apache2+mod_php+xcache+memcached

ab -n 1000 -c 5 http://***.ru/

Requests per second:    16.39 [#/sec] (mean)
Requests per second:    16.11 [#/sec] (mean)
Requests per second:    16.72 [#/sec] (mean)
Requests per second:    16.07 [#/sec] (mean)

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 5  0  40108  17740  55356 398340    0    0    58   519  137 4264 74  5 15  7
 6  1  40108  16952  55464 398768    0    0    30   798  209 5228 77  5 14  4
 3  1  40100  15596  55564 399244    0    0    39   775  197 4377 73  6 15  6
 5  0  40100  15324  55620 399752    0    0    40   304  215 4958 78  5 12  4
 7  1  40100  14668  55700 400180    0    0    27   914  168 4372 76  4 15  5
 3  1  40100  14612  55772 400696    0    0    45   423  276 4394 76  4 14  5
 4  1  40100  16556  55128 398788    0    0    32   501  141 4330 81  5 10  4

Parse Time: 0.1798 s / 8 SQL
Memory 3013980
SQL connection time 0.0020
SQL time 0.0117
PHP time 0.1661
Вполне заметен практически двукратный выигрыш по скорости для FCGI, по расходу памяти сказать сложнее, много чего мешает померять точно.
Back to top
View user's profile Send private message Send e-mail
Юрий Насретдинов
Модератор



Joined: 13 Mar 2003
Posts: 8642
Карма: 198
   поощрить/наказать

Location: 007 495

PostPosted: Fri Jun 20, 2008 12:37 am (спустя 1 час 1 минуту; написано за 2 секунды)
   Post subject:
Reply with quote

Почему, интересно, у Вас получилось SQL time в 5 раз больше, при вдвое меньшем количестве запросов в базу в секунду?
Back to top
View user's profile Send private message Send e-mail
alex946
Заглянувший



Joined: 23 Sep 2005
Posts: 3
Карма: 0
   поощрить/наказать


PostPosted: Fri Jun 20, 2008 12:00 pm (спустя 11 часов 23 минуты; написано за 2 минуты 43 секунды)
   Post subject:
Reply with quote

Скорее всего кто-то из соседних сайтов в этот момент напряг БД. Кроме того, это не средняя цифра, а от последней загрузки страницы.
vmstat тоже приведён только для последнего запуска ab для каждого из вариантов
Back to top
View user's profile Send private message Send e-mail
Guest






Карма: 388
   поощрить/наказать


PostPosted: Sat Jun 21, 2008 7:15 pm (спустя 1 день 7 часов 15 минут; написано за 9 минут 49 секунд)
   Post subject:
Reply with quote

Дмитрий, в 50 набле, IMHO неточность для апача с reverse-proxy. Если количество процессов апача не ограничивать (по дефолту около сотни), то при взрывной нагрузке все равно память закончится и сервер сложится. Статика-то отдастся, а скриптам на бакенде кирдык.

Помнится, когда у яши крыша потекла и он начал интернет со страшной силой индексировать, куча больших форумов байки травили про массированные DDoS- атаки :) Было очень смешно, когда все врагов искали :)

PS. Странно, что xcache опять пролетел по сравнению с eaccelerator. Но поскольку всего в полтора раза, наверное можно списать на космические флюиды и особенности замеров. Как говорится, "наш удав, как хотим, так и меряем" :)
Back to top
Иваннн
Guest





Карма: 388
   поощрить/наказать


PostPosted: Wed Jun 25, 2008 5:45 pm (спустя 3 дня 22 часа 30 минут; написано за 15 секунд)
   Post subject:
Reply with quote

groups.google.ru/group/highload-php-ru/browse_thread/thread/2919ab6e985e1c00
Back to top
Guest






Карма: 388
   поощрить/наказать


PostPosted: Mon Jul 07, 2008 7:46 am (спустя 11 дней 14 часов 56 секунд; написано за 1 минуту 21 секунду)
   Post subject:
Reply with quote

по поводу №50
как то очень неаккуратно написано, вот незнающий человек не поймет причем тут медленные клиенты а только больше запутается, надо бы хотя бы немножко упомянуть про архитектурные различия веб серверов.
Back to top
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Wed Aug 13, 2008 12:14 pm (спустя 1 месяц 6 дней 4 часа 28 минут; написано за 2 минуты 40 секунд)
   Post subject:
Reply with quote

Гость, ну так черкните статейку на эту тему, а я особенно интересные места из нее в статье процитирую.

alex946, боюсь, что замеры были проведены неправильно (Юрий указал один из примеров, почему).
Гость wrote:
Если количество процессов апача не ограничивать (по дефолту около сотни), то при взрывной нагрузке все равно память закончится и сервер сложится.
Ну она точно так же закончится и в FastCGI. Вы уверены, что Apache+mod_php потребляет настолько уж сильно больше памяти, чем FastCGI+PHP, если "медленных" клиентов срезали? Если да, то - насколько больше?

И - в чем именно неточность в статье? В каком абзаце?
Back to top
View user's profile Send private message Send e-mail
Антон Иконников
Guest





Карма: 388
   поощрить/наказать


PostPosted: Fri Aug 15, 2008 8:58 am (спустя 1 день 20 часов 43 минуты; написано за 1 минуту 36 секунд)
   Post subject:
Reply with quote

Дмитрий, а как в теории в склеивающем autoload'е бороться с require и dirname(__FILE__) в сторонних библиотеках?
Back to top
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Fri Aug 15, 2008 12:27 pm (спустя 3 часа 28 минут; написано за 7 минут 35 секунд)
   Post subject:
Reply with quote

Ну, с простыми require можно бороться:
1. вырезая их регулярными выражениями перед склейкой и полагаясь на автолоад;
2. создав много пустых файлов и подменив их в include_path, как я писал выше.

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

С dirname(__FILE__) также никак красиво не побороться. Я некоторое время назад пытался в исходниках парсера PHP сделать функцию подмены номера строки и файла (по аналогии с такой функциональностью в Perl и Си: #line 123 "file.name"), однако там все очень-очень глубоко закопано, и легко эту функциональность не сделать: bugs.php.net/bug.php?id=45111&edit=2 (особенно так, чтобы это было совместимо с существующими акселераторами). Совместимое решение, правда, я-таки придумал, однако по прикидкам на его реализацию у меня уйдет порядка недели Си-программирования - увы, пока такого не могу себе позволить...

Можете, конечно, искать регэкспами "__FILE__" и заменять на некоторую строку, но это тоже затычка.

Т.е. универсальный склейщик в любом случае не получится.

Для облегчения работы можете еще написать для SVN (или CVS) хук, который при коммите бы проверял, что файл не содержит ничего, кроме определения класса (простейшего регэкспа будет достаточно; конечно, его можно будет обмануть, но, по крайней мере, случайно ничего не проскочит). Тогда у вас файлы получатся автоматом "безопасные для склейки", а сторонние библиотеки, которые этому правилу не удовлетворяют, просто не закоммитятся (поэтому не будут мешать).
Back to top
View user's profile Send private message Send e-mail
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Fri Aug 15, 2008 12:29 pm (спустя 1 минуту 28 секунд; написано за 1 минуту 25 секунд)
   Post subject:
Reply with quote

Да, кстати, подмена __FILE__ - это еще только маленькое зло. По-настоящему большое зло - это сообщение об ошибках и нотисы, в которых идет ссылка не на исходный файл, а на склеенный. Вот это зло самое что ни на есть настоящее, и именно с ним я пытался бороться, делая поддержку #line).
Back to top
View user's profile Send private message Send e-mail
exed
Guest





Карма: 388
   поощрить/наказать


PostPosted: Fri Nov 07, 2008 8:34 am (спустя 2 месяца 22 дня 20 часов 5 минут; написано за 14 минут 53 секунды)
   Post subject:
Reply with quote

Я честно не понимаю почему скорость работы __autoload выше, кол-во кода уменьшается, но __autoload срабатывает в последний момент, если требуемый класс не найден. Ведь сначала нужно отсканировать память на наличие класса, сгенерировать ошибку и только затем сунуться в __autoload.

И по поводу require_once LIB_DIR . "/Some/Library.php";
В чем зло явного указания пути к файлу, если в include_path указывается не 1, а 3 пути. то при использовании нужно пройтись по всем каталогам, в поисках нужного файла. Я не заглядывал в код PHP, но злом оно может быть, если интерпритатор сначала
проходит по всем путям из include_path и только в результате ошибки обращается к файлу.
другими словами:
Code (php): скопировать код в буфер обмена
_require_once($path)
{
        $dirs =        explode (www.php.net/explode)(PATH_SEPARATOR, get_include_path (www.php.net/get_include_path)());
        foreach($dirs as $v)
        {
                if( _open($v.$path) ) return true;
        }

        if( _open($v.$path) ) return true;

 return false;
}
Но так ведь логичней
Code (php): скопировать код в буфер обмена
_require_once($path)
{
        if( _open($v.$path) ) return true;

        $dirs =        explode (www.php.net/explode)(PATH_SEPARATOR, get_include_path (www.php.net/get_include_path)());
        foreach($dirs as $v)
        {
                if( _open($v.$path) ) return true;               
        }

  return false;
}
Back to top
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Fri Dec 19, 2008 8:31 pm (спустя 1 месяц 12 дней 11 часов 57 минут; написано за 58 секунд)
   Post subject:
Reply with quote

Случайно наткнулся на статью, начинающуюся практически теми же словами, что и моя, но только на английском:
blog.milkfarmsoft.com/?p=4

Я даже думал, что кто-то взял и перевел мою статью. А потом посмотрел на дату и увидел, что английская статья вышла на 2 года реньше.
Back to top
View user's profile Send private message Send e-mail
_а-я_
Guest





Карма: 388
   поощрить/наказать


PostPosted: Thu Jan 08, 2009 7:46 pm (спустя 19 дней 23 часа 15 минут; написано за 22 секунды)
   Post subject:
Reply with quote

Спасибо большое, очень познавательно!)
Особенно, таким новичкам как я)
Меня как раз сейчас интересует это все.
Так как у меня в основном вап-сайты, то меня как раз волнует вопрос «медленных клиентов».
Прочитав все, я понял, что лучше не использовать инклуды. А «забихать» все в один большой php-файл по возможности.

Так же поставил nginx, чтоб отдавать файлы.
Динамика идет на mod_php т.е. стоит апача

До этого я хотел чтоб nginx сразу отдавал PHP- fcgi через php-fpm/
Но прочитав тут все, понял что этого не стоит делать. Это так?
Или все же лучше поставить? Будут ли хоть какие то плюсы?
Выиграем память? У меня пока всего 64мб на все про все.

Были попытки поставить, поставил php-fpm, но никак не могу соединить это все вместе.
Хотелось бы через сокеты. Кто может с этим помочь?

И еще меня волнует один вопрос, если PHP транслирует байт-код, а eAccelerator – кэширует, почему нельзя на сервере хранить именно в этом «байт-коде»
Back to top
Дмитрий Котеров
Администратор



Joined: 10 Mar 2003
Posts: 13665
Карма: 413
   поощрить/наказать


PostPosted: Thu Jan 15, 2009 8:02 pm (спустя 7 дней 15 минут; написано за 4 минуты 21 секунду)
   Post subject:
Reply with quote

_а-я_ wrote:
До этого я хотел чтоб nginx сразу отдавал PHP- fcgi через php-fpm/
Но прочитав тут все, понял что этого не стоит делать. Это так?
Неправильно говорить "не стоит". Лучше говорить - "по скорости разница будет совсем незначительной, и fastcgi тут не является панацеей". Ну а память при fastcgi выиграете, да, но тоже не чтобы уж очень значительно тоже (при правильных настройках апача).
_а-я_ wrote:
Прочитав все, я понял, что лучше не использовать инклуды. А «забихать» все в один большой php-файл по возможности.
Главное, чтобы это не ухудшало читабельность программы и не усложняло ее разработку. Все-таки человеческое время дороже машинного.
Плюс - эффект начинает проявляться, только если исходников очень много (1М и больше). Если у Вас кода всего-то на 100КБ, то смысла заморачиваться вообще нет.
_а-я_ wrote:
если PHP транслирует байт-код, а eAccelerator – кэширует, почему нельзя на сервере хранить именно в этом «байт-коде»
Zend Encoder это как раз и пытается делать, только смысла нет совсем: достаточно в shared memory хранить оттранслированную версию.
Кроме того, у eAccelerator есть режим сохранения байт-кода во временные файлы тоже.
В любом случае, когда байт-код на лету генерится, это гораздо удобнее, чем хранить его в виде файлов (потому что исчезает фаза компиляции при разработке).
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic All times are GMT + 3 Hours
Goto page 1, 2  Next
Page 1 of 2    Email to a Friend.
Post a reply
Username
Subject
Господа спамеры и оптимизаторы!

Вы можете даже и не пытаться вставлять в текст поста ссылки - они все равно автоматически удаляются (вернее, тэги <a> заменяются на тэги <u>).

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

Disable BBCode in this post
Disable Smilies in this post
    HTML is OFF
BBCode is ON
Smilies are ON
You cannot post new topics in this forum. You can reply to topics in this forum. You cannot edit your posts in this forum. You cannot delete your posts in this forum. You cannot vote in polls in this forum. You cannot attach files in this forum. You can download files in this forum.
XML