Пример использования eAccelerator для нагруженного php-проекта

Веб-разработка*

Наш новый фронтенд-сервер сейчас вполне справляется с нагрузкой и в оптимизации не нуждается (чего нельзя сказать о базе данных), но после того, как я очередной раз посмотрел на его top, мне вдруг стало жалко ожесточённо разнашиваемых дисков, и я решил уделить этому пару минут и поставить eAccelerator.

Спящие апачи с нулевым потреблением процессора в рейтинге не учавствовали.

Top до:

last pid: 81349;  load averages:  1.32,  0.96,  0.73
up 26+20:37:16  17:02:30
67 processes:  1 running, 66 sleeping
CPU states:  3.1% user,  0.0% nice,  1.1% system,  0.6% interrupt, 95.2% idle
Mem: 1266M Active, 5844M Inact, 205M Wired, 251M Cache, 214M Buf, 162M Free
Swap: 1024M Total, 1024M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
81128 habrahabr    1  20    0 32460K 14288K lockf  4   0:09  2.93% httpd_habr
81122 habrahabr    1  20    0 32784K 14608K lockf  5   0:09  2.83% httpd_habr
81126 habrahabr    1  20    0 32384K 14328K lockf  3   0:10  2.20% httpd_habr
81105 habrahabr    1  20    0 32456K 14288K lockf  1   0:09  1.86% httpd_habr
81108 habrahabr    1  20    0 32556K 14384K lockf  2   0:09  1.86% httpd_habr
81111 habrahabr    1  20    0 32548K 14372K lockf  7   0:09  1.66% httpd_habr
81133 habrahabr    1  20    0 32880K 14712K lockf  5   0:09  1.66% httpd_habr
75450 nobody       1   4    0  1038M  1037M kqread 3 527:12  1.42% memcached
81110 habrahabr    1  20    0 32388K 14216K lockf  6   0:09  1.37% httpd_habr
81114 habrahabr    1  20    0 32876K 14704K lockf  7   0:10  1.22% httpd_habr
81113 habrahabr    1  20    0 32496K 14328K lockf  0   0:09  1.12% httpd_habr
81112 habrahabr    1  20    0 32496K 14320K lockf  6   0:07  1.03% httpd_habr
81130 habrahabr    1  20    0 32460K 14284K lockf  7   0:09  0.98% httpd_habr
81116 habrahabr    1  20    0 33556K 15384K lockf  2   0:09  0.98% httpd_habr
81106 habrahabr    1  20    0 32888K 14712K lockf  1   0:10  0.88% httpd_habr
81117 habrahabr    1  20    0 34052K 15880K lockf  5   0:09  0.88% httpd_habr
81124 habrahabr    1  20    0 32452K 14292K lockf  2   0:09  0.88% httpd_habr
81107 habrahabr    1  20    0 32440K 14272K lockf  3   0:08  0.88% httpd_habr
81132 habrahabr    1  20    0 32376K 14204K lockf  7   0:08  0.88% httpd_habr
81127 habrahabr    1  20    0 32860K 14944K lockf  2   0:07  0.88% httpd_habr
81103 habrahabr    1  20    0 32472K 14280K lockf  4   0:10  0.83% httpd_habr
81119 habrahabr    1  20    0 32468K 14296K lockf  0   0:09  0.78% httpd_habr
81125 habrahabr    1  20    0 32396K 14232K lockf  7   0:08  0.73% httpd_habr
81123 habrahabr    1  20    0 32876K 14694K lockf  4   0:10  0.78% httpd_habr
81134 habrahabr    1  20    0 32428K 14248K lockf  1   0:08  0.78% httpd_habr
81131 habrahabr    1  20    0 32860K 14684K lockf  6   0:09  0.73% httpd_habr
81115 habrahabr    1  20    0 32388K 14220K lockf  6   0:09  0.68% httpd_habr
81118 habrahabr    1  20    0 34744K 16692K lockf  4   0:09  0.63% httpd_habr
81120 habrahabr    1  20    0 32612K 14540K lockf  3   0:09  0.63% httpd_habr
81121 habrahabr    1  20    0 32396K 14224K lockf  0   0:08  0.59% httpd_habr
81104 habrahabr    1  20    0 33536K 15360K lockf  1   0:09  0.34% httpd_habr
81129 habrahabr    1  20    0 32444K 14276K lockf  6   0:08  0.34% httpd_habr
81109 habrahabr    1  20    0 32444K 14272K lockf  2   0:07  0.24% httpd_habr

Top после:

last pid: 81887;  load averages:  0.17,  0.34,  0.46
up 26+20:55:47  17:21:01
68 processes:  2 running, 66 sleeping
CPU states:  2.5% user,  0.0% nice,  1.2% system,  0.4% interrupt, 96.0% idle
Mem: 1202M Active, 5869M Inact, 201M Wired, 251M Cache, 214M Buf, 204M Free
Swap: 1024M Total, 1024M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
81482 habrahabr    1  20    0 56068K 18912K lockf  4   0:08  1.90% httpd_habr
75450 nobody       1   4    0  1038M  1037M kqread 6 527:34  0.98% memcached
81471 habrahabr    1  20    0 56204K 25744K lockf  6   0:08  0.73% httpd_habr
81487 habrahabr    1  20    0 59492K 31552K lockf  1   0:07  0.73% httpd_habr
81484 habrahabr    1  20    0 59820K 32328K lockf  1   0:08  0.54% httpd_habr
81456 habrahabr    1  20    0 55976K 19380K lockf  0   0:09  0.49% httpd_habr
81469 habrahabr    1  20    0 56140K 18928K lockf  5   0:08  0.49% httpd_habr
81460 habrahabr    1  20    0 57224K 20676K lockf  7   0:08  0.49% httpd_habr
81461 habrahabr    1  20    0 56248K 27964K lockf  5   0:07  0.44% httpd_habr
81459 habrahabr    1  20    0 55752K 25304K lockf  5   0:08  0.34% httpd_habr
81476 habrahabr    1  20    0 55856K 18980K lockf  3   0:08  0.34% httpd_habr
81480 habrahabr    1  20    0 55568K 18380K lockf  3   0:08  0.29% httpd_habr
81470 habrahabr    1  20    0 55952K 27852K lockf  0   0:08  0.29% httpd_habr
81466 habrahabr    1  20    0 57116K 30072K lockf  3   0:07  0.29% httpd_habr
81467 habrahabr    1  20    0 56184K 27648K lockf  1   0:08  0.24% httpd_habr
81477 habrahabr    1  20    0 55836K 24572K lockf  5   0:07  0.24% httpd_habr
81464 habrahabr    1  20    0 59524K 29480K lockf  5   0:08  0.20% httpd_habr
81468 habrahabr    1  20    0 55588K 27248K lockf  1   0:08  0.15% httpd_habr
81458 habrahabr    1  20    0 55812K 19132K lockf  6   0:08  0.15% httpd_habr
81474 habrahabr    1  20    0 55576K 26852K lockf  1   0:08  0.15% httpd_habr

Разумеется, для кого-то это но новость, но всё же занятно, как можно устранить один из недостатков php по сравнению с mod_perl.

При большей нагрузке разница была бы значительней.

+19

25 октября 2007, 17:53

juks 90,1

комментарии (75)

AlexeyK 25 октября 2007, 18:35 #

Судя по всему процессов стало меньше, но их размер...

juks 25 октября 2007, 18:39 # ↑

Это фронтенд с 8G памяти :-)

AlexeyK 25 октября 2007, 19:27 # ↑

Все равно пугает :) Кстати, la - очень специфичная вещь, по ним судить не стоит, кто-то комментарием ниже уже сказал. Самая серьезная вещь в данном случае - графики, их бы увидеть и сравнить :)

davojan 26 октября 2007, 00:34 # ↑

По поводу размера процессов - это обманка. Если всё устроено, как в xcache, то там используется shared memory, а в топе она отражается у всех процессов, а на самом деле выделена она только один раз.

Автору по собственному опыту рекомендую использовать APC вместо eAccelerator'а. Он, кажется помедленнее, но зато значительно стабильнее. Я пробовал eAccelerator пару лет назад, на достаточно сложных скриптах он падал (PHP 5). Может, конечно, сейчас стало лучше...

juks 26 октября 2007, 00:56 # ↑

Да, shared memory. Сейчас выделено 25мегабайт на всех. Как раз:

Memory Size 26,214,336 Bytes
Memory Available 3,672,832 Bytes
Memory Allocated 22,541,504 Bytes
Cached Scripts 359

А как падал? Умирали апачи/запускались другие?

davojan 26 октября 2007, 01:08 # ↑

> А как падал? Умирали апачи/запускались другие?
Да нет, так xcache любит иногда падать.
Я немного неправильно выразился, вернее сейчас вспомнил конкретно: он не падал, а просто какой-то мусор в аутпут кидал.

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

В пользу APC ещё и то, что его собираются в стандартную поставку включить в PHP6.

AlexeyK 26 октября 2007, 10:19 # ↑

Сейчас АПЦ мало что дает, еакселератор достаточно стабилен, а что касается мусора с xcache - да, было такое, было еще, если использовался memcached, но не у меня, у знакомого на проекте, насколько знаю - проблема решилась.

davojan 26 октября 2007, 11:03 # ↑

Я, наверное, некорректно выразился.
Мусорил не xcache, а eAccelerator. Xcache, почему-то сильно дестабилизировал последний php (5.2.4, кажется), поэтому я от него отказался в продакшне в пользу APC. Насчёт скорости, по ощущениям xcache не сильно быстрее APC.

НЛО прилетело и опубликовало эту надпись здесь

Zada 25 октября 2007, 18:43 #

Не плохо было бы пояснить для незнающих, но интересующихся, что произошло и чему радоваться.

juks 26 октября 2007, 01:42 # ↑

Без этого довольно громоздкий пхп-код собирался заново для каждого запроса. С ускорителем всё остаётся в shared-памяти используется повторно до тех пор, пока не изменится исходный код.

at0mic 25 октября 2007, 18:50 #

не вижу большой разницы в потреблении ресурсов

clops 25 октября 2007, 18:53 # ↑

load average упал где-то в 4 раза

clops 25 октября 2007, 18:53 # ↑

или в 3 %)

at0mic 25 октября 2007, 19:03 # ↑

это всего-лишь указывает на уменьшение кол-ва процессов, но вовсе ну указывает на уменьшение потребляемых ресурсов.
Если вы не знакомы со значением load averages, советую глянуть мельком сюда: http://www.lifeaftercoffee.com/2006/03/13/unix-load-averages-explained/

juks 26 октября 2007, 01:40 # ↑

Разницу надо просто отмасштабировать на тот случай, когда нагрузка будет пиковой.

zotov 25 октября 2007, 19:04 #

А вы точно включили акселератор? :)

Конечно, 2.5% это меньше, чем 3.1%, но разница настолько мизерна, что может быть случайной.

И при чём здесь "ожесточённо разнашиваемые диски"? eAccelerator экономит CPU, а не диски. Все ваши скрипты находятся в кеше независимо от того, есть акселератор или нет.

Slach 25 октября 2007, 19:29 # ↑

исходники скриптов может в файловом кеше OS и находятся
а вот байт код без apc\eAccelerator генерится каждый раз

zotov 25 октября 2007, 19:45 # ↑

Ну да, я и написал: "экономит CPU".

juks 26 октября 2007, 01:15 # ↑

Я имел в виду, что это довольно злой сервер для текущей задачи. Он и без акселератора потянул бы нагрузку в разы больше этой. Просто захотелось чтобы он меньше ворочался, раз есть такая возможность.

С дисками я, пожалуй, неверный пример привёл. По iostat не удаётся уловить разницы, нужна большая нагрузка, в разы. Да и общий объём исходного кода маловат.

butuzov 25 октября 2007, 21:02 #

Мы успешно используем и мемкшд, и еакселератор, и AdoDB .

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

juks 26 октября 2007, 01:37 # ↑

MySQL это наше всё :-) После переезда на новые срервера Каравана пришлось попотеть, проблем, думаю, мало кто не заметил. Всё вдруг взбударажилось и встало ребром.

До конца не помогло подключение новых тредов для FreeBSD 6.2 и оптимизация структуры базы и запросов к ней.

Видимо, помимо прочего, просто совпали моменты переезда и то время, когда myisam (да-да, все таблицы с начала жизни проекта до недавного времени были в myisam) стал не к месту для такого проекта. Кратковременное запирание таблиц приводило к гигантской очереди, которая просто не могла рассосаться.

Спокойствие настало тогда, когда в добавок к остальному посты и комментарии были переведены в InnoDB и был выделен двухгигабайтный буфер памяти. InnoDB в отличии от myisam умеет очень хорошо распоряжаться оперативной памятью: хранить там не только закешированную информацию но и целые индексы таблиц.

innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 2G

Про то, как сдесь применить AdoDB пока ничего сказать не могу: не пользовался. Пока довольствуемся стандарным кешем запросов MySQL.

butuzov 26 октября 2007, 01:42 # ↑

ХАБРА ЖИЛА НА МАЙИСАМЕ????
(широко выпучив глаза)

juks 26 октября 2007, 01:50 # ↑

До 400000 запросов к бекэнду в сутки, так что от одной страницы от 3-5 до 50-70 запросов к базе.

Я не сомневаюсь, что прежние авторы проблем с производительностью myisam на тех объёмах данных и той посещаемости не испытывали. Самое досадное, что на старых серверах это работало без проблем, а всплыло жутким комшаром только после переезда, так что всем долго казалось, что у меня просто руки кривые.

За то видно, где предел myisam.

long 26 октября 2007, 01:55 # ↑

какая ОС были и на какую перебрались? какая версия MySQL была и на какую перешли? есть некоторые подозрения на этот счет...

juks 26 октября 2007, 02:13 # ↑

С 6.2 на 6.2. MySQL 5. Разница версии в одну десятую.

Процессоры — с AMD 64 на новые четёрыхядерные ксеоны.

Там кроме прочего, были явные проблемы с таблицами, которые могли всплыть от dump-restore. Когда всё было в myisam то средствами repair/analyze/myisamchk ничего сделать не получалось, они просто висли. Приходилось пересоздавать проблемную таблицу.

long 26 октября 2007, 02:27 # ↑

у нас на 4.х не наблюдалось проблем, а вот после перехода на 5 - repair стало достаточно регулярной процедурой :(

juks 26 октября 2007, 02:15 # ↑

точнее одну сотую

OlegD 26 октября 2007, 11:45 # ↑

До 400000 запросов в сутки - это как-то мало. Это получается порядка 4.6 запросов/сек к backend, это всего-то 324 req/sec к БД в пиках. У меня вот req/sec к backend на торрентовском форуме ~50, и есть еще трекер (отдельное приложение) с загрузкой порядка 350 req/sec, вместе они дают порядка 1200 req/sec к БД в среднем и ~2000 req/sec в пиках. От MyISAM отказался, разумеется, уже сто лет назад, заменив на InnoDB (в MyISAM остались только таблицы с fulltext indexes), EAccelerator тоже уже давно стоит, эффект есть, вот недавно сделал все-таки frontend на Squid, дабы вообще не было обращений к backend для статики, тоже замечательно помогает. Median service time по cache hit - 0.003 sec (это статика), по cache miss (динамика) - 0.22 sec.

juks 26 октября 2007, 19:34 # ↑

На форуме?

Сейчас всё, вроде бы, удалось решить, но говорить «много-мало» в данном случае как-то неправильно. Разве специфика отдельно взятых данных, структуры базы и запросов к ней ничего не решают? Разве можно сравнивать запросы одним только количеством :-)?

На хабре для каждого пользователя свои запросы и запросы довольно непростые, некоторые у меня не умещаются в экран. Чего стоит один только вывод постов и комментариев одной лентой? Лично я бы допускать этого в таком виде не стал, но здесь это есть. Как следствие - «using temporary; using filesort». Все эти количества комментариев, персонализированные ленты многого стоят. Для любого зарегистрированного пользователя кеширование практически сходит на нет.

OlegD 26 октября 2007, 20:00 # ↑

На форуме, да. Я просто удивился, что периодически наблюдаемые мной здесь затыки вызываются таким небольшим количеством запросов - и HTTP, и SQL. А сами SQL-запросы здесь я видел когда-то в отладке внизу страницы, поэтому могу более или менее сравнить.

juks 26 октября 2007, 20:36 # ↑

Когда просочились запросы, то самых страшных среди не было :-)

long 26 октября 2007, 01:47 # ↑

если мне не изменяет мой склероз, myisam как раз умеет хранить индексы в памяти. в отличии от InnoDB, которая может там держать таблицы

juks 26 октября 2007, 02:00 # ↑

innodb_buffer_pool_size

The size in bytes of the memory buffer InnoDB uses to cache data and indexes of its tables. The larger you set this value, the less disk I/O is needed to access data in tables. On a dedicated database server, you may set this to up to 80% of the machine physical memory size. However, do not set it too large because competition for physical memory might cause paging in the operating system.

Насколько моя память помнит, для myisam основные опции — параметры для буфера запросов и сортировки, помню, что когда я этим занимался, я не нашёл ничего такого, что позволилось бы ему с ногами залезть в память. Может быть, конечно, я просто что-то упустил.

До момента предоставления значительного количества памяти mysql потреблял 100-300% ЦПУ (в системе числится 8 процессоров от двух четырёхядерных ксеонов), как только таблицы были переведены в innodb. С двумя гигабайтами потребление снизилось до 1-15% в обычном решиме и 100% в пиковом.

long 26 октября 2007, 02:24 # ↑

эээ.... а как innodb_buffer_pool_size соотнотносится с индексами myisam?

juks 26 октября 2007, 08:23 # ↑

никак не соотносится

fisher 26 октября 2007, 12:22 # ↑

в myisam считай vfs (файловый кеш)
ну и каменты на mysam (частые апдейты) - жесть конечно :)

anight 26 октября 2007, 01:29 #

А можно еще больше все ускорить, если отказаться от apache в пользу nginx + php as fastcgi + php-fpm

juks 26 октября 2007, 01:40 # ↑

Nginx берёт на себя статику и делает это, как все знают, очень хорошо. Про наш довольно лёгкий апач, который ничего кроме php-скриптов не крутит, против fastcgi я бы не стал сейчас спорить, да и это пока не актуально.

anight 26 октября 2007, 01:49 # ↑

Смотря для чего используете apache. Если только для php, то как я уже сказал выше, это лишнее.

long 26 октября 2007, 01:53 # ↑

Игорь Сысоев предупреждал, что связка nginx + php(fastcgi) может быть не стабильна. хотя многие проекты вполне хорошо себя чувствуют на этой связке - специально интересовался этим вопросом совсем не давно.

anight 26 октября 2007, 02:00 # ↑

На практике она достаточно стабильна чтобы советовать ее другим. За плечами у меня три года ее использования и все проблемы которые были найдены - сейчас решены. И в nginx и в php. Обязательно берите последние версии вышеназванных продуктов.

juks 26 октября 2007, 02:08 # ↑

Пока к fastcgi меня жизнь не привела.

Когда я работал в mail.ru то на моём проекте использовался nginx+apache+mod_perl. К моменту ухода рекорд был 1800000 хитов на один сервер web+база (news.mail.ru).
Проблемы были две:

* оптимизатор MySQL под нагрузкой начинал сходить с ума и брать неоптимальный индексы, приходилось долго и упорно расставлять их везде в виде use index, запросов было много, поэтому это был очень раздражительный и муторный процесс.

У нас там не было такого количества пямяти, поэтому скинуть всё на innodb не удавалось.

* mod_perl «тёк» (да, не высвобождал память, но в каких-то слишком значительных количествах), поэтому апачи должны были перезапускаться время от времени по maxrequests

fisher 26 октября 2007, 12:27 # ↑

база непричём? fastcgi+nginx даёт возможность разнести разные вещи - апликейшн и обработку соединений. кстати "бекенд" в правильной ардитектуре - это именно аппликейшн, а у вас на фронте тяжеленный апач с пхп.

juks 26 октября 2007, 19:15 # ↑

На фронте nginx

fisher 28 октября 2007, 15:05 # ↑

ммм тогда значит я не понял терминов ты пишешь "Наш новый фронтенд-сервер"

juks 29 октября 2007, 10:58 # ↑

Я так выразился, имея в виду, что база на отдельном :-)

smart 5 апреля 2008, 13:35 # ↑

Вот кстати, регулярно натыкаюсь на подобное "искажение" привычной нам терминологии. Пожалуй, надо написать разъяснительную статью, о том, как называются компоненты больших web-систем :)

long 26 октября 2007, 01:42 # ↑

не разу не получали вот такую картинку?

juks 26 октября 2007, 01:44 # ↑

Nginx здесь непричём. Ему просто не ответил апач, а тот, в свою очередь, не дождался ответа от базы. Как решались проблемы с базой написано выше.

long 26 октября 2007, 01:50 # ↑

вообще это был ответ на предложение уйти от apache к nginx. я могу ошибаться, но мне показалось что подразумевалось, что все живет исключительно на apache.

juks 26 октября 2007, 02:01 # ↑

Нет-нет, без nginx никуда.

kiev 20 ноября 2007, 00:12 # ↑

так если настроить nginx то апач вообще не надо

anight 26 октября 2007, 01:45 # ↑

Конечно получали ;-) Надеюсь, что на хабре нет подвисающих скриптов.

DjOnline 12 декабря 2007, 16:49 # ↑

у меня на довольное крупном проекте с 350k+ хитов в сутки всё это крутится на apache 2.2+ php в связке с fc_gid (китайский fastcgi), насколько я помню в котором обошли проблему, ради которой был придуман php-fpm. Или php-fpm мне тоже может помочь? php 5.4.6

По поводу nginx - можно ли совмещать фронтенд с nginx и бэкенд с apache+php на одной машине? Как раз таки для оптимального использования памяти в случаях с подгрузкой статики.

Насчёт eAccelerator и APC - хочу, но боюсь. Раз в год ставил и apc, и mmturk (в то время он так назывался) - потом ломал голову почему падает полностью процесс апача. Вот и насколько опасно ставить это сейчас в продакшене.

DjOnline 12 декабря 2007, 18:42 # ↑

Ну вот, тесты показали что eAccelerator полностью делает неработоспособной вплоть до связку apache + php (cgi) + fcgid.

anight 12 декабря 2007, 19:32 # ↑

Во-первых, советую обстоятельно исследовать возможность отказаться от apache совсем: если у вас уже на машине есть nginx + php as fastcgi - они умеют работать напрямую, без apache. Это сэкономит память и в вашем случае немного убыстрит сайт.
Что это за странный php 5.4.6 ?
Падающие акселераторы несите в студию http://groups.google.ru/group/highload-p… , вместе с бэктрейсами, попробуем разобраться что к чему.

DjOnline 13 декабря 2007, 10:25 # ↑

nginx пока нет, переделывать несколько проектов, завязанных на .htaccess довольно сложно ( nginx не поддерживает ведь .htaccess от апач?).
Сорри, php 5.2.5 :)
php-fpm не использую, и пока так и не понял чем он лучше в плане скорости китайского fcgid.so + php-cgi + suexec.
А у eAccelerator судя по всему именно несовместимость с php-cgi, поддерживает только php-fastcgi, но fastcgi.coremail.cn не поддерживает php-fastcgi.

APC то хоть сможет работать в связке с fcgid ?

p.s. самое интересное что в логах ничего не пишется, вообще ничего, и только php-cgi выдаёт EACCELERATOR: Warning: "-" is cached but it's mtime is in the future. - как видим, ему попадает какой-то "-" вместо имени файла.

anight 13 декабря 2007, 21:49 # ↑

На мой взгляд большинство вещей из htaccess легко переносятся на конфиг nginx.
eAccelerator должен нормально работать с php-fastcgi. Если у вас не работает, составьте внятный баг-репорт, вам обязательно помогут по указанной выше ссылке.
APC тоже должен замечательно работать с php-fastcgi.

DjOnline 13 декабря 2007, 10:36 # ↑

http://groups.google.ru/group/highload-php-ru/browse_thread/thread/a9a6bd475b121a9b - судя по всему у товарища та же самая проблема, с неработающим php-cgi в связке в eAccelerator, в отличие от меня у него php_fpm. Официально на сайте eAccelerator сказано что оно и не может работать с php-cgi..

anight 13 декабря 2007, 21:51 # ↑

Он не может работать с CGI sapi по очевидным причинам. А php-cgi это название бинарного файла для CGI и FastCGI sapi. php-fpm - это всегда FastCGI sapi.

smart 5 апреля 2008, 13:32 # ↑

Совмещать на одном сервере front и back можно, и для многих (не слишком больших) проектов как раз очень эффективно.

fisher 26 октября 2007, 12:22 #

у вас до сих пор не было акселератора? :)

smart 26 октября 2007, 14:12 # ↑

Ну если у них и без него 95% idle - то нафиг он нужен? :)

fisher 26 октября 2007, 17:07 # ↑

эээ посмотрим с другой стороны
если квартира 100 метров, но из ней без труда можно сделать 200, то не стоит ли это все-таки сделать ;)

smart 26 октября 2007, 17:14 # ↑

Нууу... если в этой квартире живет только одна очень маленькая собачка - то зачем? :)

fisher 26 октября 2007, 17:18 # ↑

а, то есть платить зп "чтоб на жизнь хватало" нормально? ;)

smart 26 октября 2007, 17:19 # ↑

Если среднему специалисту просто так поднять зп в 2 раза - работать он станет хуже ;)

fisher 28 октября 2007, 17:32 # ↑

ну, смотря со скольких. если с "чтоб на жизнь хватало" - то нифига подобного.

kosiasik 5 апреля 2008, 11:39 # ↑

Учтём ;)

smart 5 апреля 2008, 13:31 # ↑

Ты не средний. Ты хороший :)

juks 26 октября 2007, 19:13 # ↑

Да, именно так :-)

smart 26 октября 2007, 14:14 #

Я долго думал, что может значить этот пост, и наконец понял: он значит, что у хабра все хорошо! :)

feedbee 5 апреля 2008, 12:25 #

Полезна не так сама статья, как комментарии к ней. Читайте комменты от начала до конца ;)

DjOnline 14 июля 2008, 12:53 #

Как подружть APC/Eacc/xdebug c http://fastcgi.coremail.cn/ под Apache ?
APC создаёт число копий кэша равное числу дочерних процессов Fastcgi, соответственно обновляя страницу apc.php видно каждый раз разный uptime и разное число хитов. Точно также дублируются и пользовательские данные.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.