Comments 145
спасибо.
Нехило оптимизировал.
мы обычно раз в 5-10 оптимизируем по нагрузке. За то же время. Правда, используем на порядок больше инструментов.
Это вам в «Я пиарюсь» :-)
И говоря «за то же время» вы не говорите «за те же деньги», а в Вашем случае это феноменальная разница :-)
И говоря «за то же время» вы не говорите «за те же деньги», а в Вашем случае это феноменальная разница :-)
в посте ни слова не было о сумме. Но я думаю, что если они и не равны, то сопоставимы.
А комментарий был о том, что пост про двукратное ускорение не для главной Хабра: это очень слабо.
А комментарий был о том, что пост про двукратное ускорение не для главной Хабра: это очень слабо.
Пост не о двукратном ускорении(это весьма банально), а о недобросовестных действиях хостера.
У вас — 7000 рублей за первичную настройку nginx и ко и 2000 рублей в год за WEBO Site SpeedUp (и на сайте написано что ускорение в 2.5 раза, а Вы пишете что обычно в 5-10… Странно). Сумма достаточно ощутимая, особенно для полу-коммерческих сайтов.
У вас — 7000 рублей за первичную настройку nginx и ко и 2000 рублей в год за WEBO Site SpeedUp (и на сайте написано что ускорение в 2.5 раза, а Вы пишете что обычно в 5-10… Странно). Сумма достаточно ощутимая, особенно для полу-коммерческих сайтов.
WEBO Site SpeedUp ускоряет клиентскую часть, в среднем, в 2,5 раза (без учета серверного кэширования). WEBO Server SpeedUp — 5-10 раз (это как раз с серверным кэшированием). Общее ускорение — можно просто помножить.
А то, что хостеры химичат, это понятно. Просто хотелось тему производительности все же раскрыть глубже: как химичат хостеры становится понятно уже после часа копания, а вот как с этим справляться по всей программе пока никто не написал. Тут же не только nginx+APC.
А то, что хостеры химичат, это понятно. Просто хотелось тему производительности все же раскрыть глубже: как химичат хостеры становится понятно уже после часа копания, а вот как с этим справляться по всей программе пока никто не написал. Тут же не только nginx+APC.
В 90% случаев nginx+APC+правильный конфиг MySQL как раз более чем достаточно.
Внедрение memcached и проч. для сайтов не заточенных изначально под него не дает решающих преимуществ (например, сессии в memcached, кеширование phpBB в memcached).
Внедрение memcached и проч. для сайтов не заточенных изначально под него не дает решающих преимуществ (например, сессии в memcached, кеширование phpBB в memcached).
nginx+APC+конфиг MySQL дают как раз не больше 2-3-кратного прироста. Обычно этого недостаточно для высокой производительности.
А Memcached ни разу не является серебряной пулей (чтобы вот так с нуля его разворачивать, тот же APC может оказаться производительнее).
А Memcached ни разу не является серебряной пулей (чтобы вот так с нуля его разворачивать, тот же APC может оказаться производительнее).
nginx с правильным конфигом apache от nginx с дефолтным конфигом апача на высокой нагрузке отличаются более чем в 2-3 раза даже без учета APC :-D. Дефолтный конфиг апача просто ложит VPS и на этом все заканчивается :-)
Когда я говорю «более чем достаточно» я имею ввиду, что по данному тарифному плану сайт всю жизнь будет обслуживать всю свою имеющуюся аудиторию и не будет иметь проблем.
Когда я говорю «более чем достаточно» я имею ввиду, что по данному тарифному плану сайт всю жизнь будет обслуживать всю свою имеющуюся аудиторию и не будет иметь проблем.
видимо, у нас просто разные взгляды на качественную работу :) нп
Задача любого инженера — качественно решить поставленную задачу затратив минимум ресурсов.
Сферическая производительность в вакууме никого не интересует.
Его интересует только одно: в час пик сайт работает / не работает.
Если на сайте 5000 уников, и в перспективу может быть будет 10'000 — это одни средства, и одна цена, которая всех устраивает.
Если 100'000 и может быть будет 100'000'000 — другие.
Универсального решения нет.
Ваше решение — слишком дорогое для первого варианта, и слишком слабое для второго :-)
Сферическая производительность в вакууме никого не интересует.
Его интересует только одно: в час пик сайт работает / не работает.
Если на сайте 5000 уников, и в перспективу может быть будет 10'000 — это одни средства, и одна цена, которая всех устраивает.
Если 100'000 и может быть будет 100'000'000 — другие.
Универсального решения нет.
Ваше решение — слишком дорогое для первого варианта, и слишком слабое для второго :-)
И вообще, дайте рута на тестовый сервер с развернутой phpBB, посмотрим насколько быстро оно у Вас работает :-)
При желании эту проверку можно устроить как отдельную статью «А вы пользуетесь Досей или всё еще кипятите» :-)
При желании эту проверку можно устроить как отдельную статью «А вы пользуетесь Досей или всё еще кипятите» :-)
Общее ускорение — можно просто помножить.Помножить?! Я понимаю если бы вы сказали «усреднить», тогда бы это было близко к истине. Но «помножить» — это вы загнули.
Я бы в «Высокую производительность» перенес, наверно.
Автору виднее. Ну и напишите что за хостер?
Автору виднее. Ну и напишите что за хостер?
Статья в первую очередь касается рядовых пользователей хостинга, а не тех, кто занимается оптимизацией и разработкой. В «высокой производительности» nginx-ом никого не научить :-)
Хостеру я написал приватно, для того чтобы разводить грязь — нужно собирать доказательства, а их публиковать можно только по желанию клиента. Думаю, приватное сообщение даст тот же эффект, и никого не запачкает.
Хостеру я написал приватно, для того чтобы разводить грязь — нужно собирать доказательства, а их публиковать можно только по желанию клиента. Думаю, приватное сообщение даст тот же эффект, и никого не запачкает.
А где можно глянуть насколько влияет запись в access_log на производительность?
Несущественно, пока производительность не начинает упираться в диск (визуально можно оценить по «толщине» iowait, которая впрочем зависит и от соседей VPS).
Т.е. на VPS отключая access_log мы не столько увеличиваем свою производительность, сколько меньше мешаем соседям по ноде.
Т.е. на VPS отключая access_log мы не столько увеличиваем свою производительность, сколько меньше мешаем соседям по ноде.
Вот и я как бы об этом. Просто никогда не уделял этому внимания, принимая что на общем фоне это просто мизер. Поэтому и подумал, что пропустил что-то.
Спасибо.
Спасибо.
Мизер мизером, но винчестер — это 100-200 операций в секунду. В случае VPS — это 200 операций в секунду НА ВСЕХ.
Конечно 1 запись на 1 хит не будет, т.к. лог пишется блоками, но все равно существенно.
Представьте, сервер отдает 10'000 мелких картинок в секунду (хотя это можно отдельно отрезать от access_log-а), которые все лежат в дисковом кеше. А записывать строчку в access_log приходится в любом случае…
Конечно 1 запись на 1 хит не будет, т.к. лог пишется блоками, но все равно существенно.
Представьте, сервер отдает 10'000 мелких картинок в секунду (хотя это можно отдельно отрезать от access_log-а), которые все лежат в дисковом кеше. А записывать строчку в access_log приходится в любом случае…
Тут я вижу две вещи.
Либо
— Админ шибко умный и решил развести клиента на более дорогой тариф (это с точки зрения хостера выгодно, даже «авторитетные» таким промышляют не редко, ведь это приносит бабки и в 99% сходит с рук, если конечно такой тариф существует, потому что каждый хостер имеет придел и выше самого высокого тарифа уже не предложить)
— Админ шибко «умный» в кавычках (что тоже не исключено, ибо админом в наше время мнит себя каждый кто осилил установку убунты по дефолту, хороших же специалистов найти не так и просто)
Либо
— Админ шибко умный и решил развести клиента на более дорогой тариф (это с точки зрения хостера выгодно, даже «авторитетные» таким промышляют не редко, ведь это приносит бабки и в 99% сходит с рук, если конечно такой тариф существует, потому что каждый хостер имеет придел и выше самого высокого тарифа уже не предложить)
— Админ шибко «умный» в кавычках (что тоже не исключено, ибо админом в наше время мнит себя каждый кто осилил установку убунты по дефолту, хороших же специалистов найти не так и просто)
Можно попросить совета — куда копнуть для настройки VDS на минимальное использование памяти в случае использования связки nginx+apache+php+mysql
mysql и nginx меня особо не беспокоят — в результате моих манипуляций своими кривыми ручками они занимают что-то около 15 метров суммарно.
какие есть способы уменьшения памяти, используемых apache+php, Сейчас они кушают около 40 метров на процесс.
mysql и nginx меня особо не беспокоят — в результате моих манипуляций своими кривыми ручками они занимают что-то около 15 метров суммарно.
какие есть способы уменьшения памяти, используемых apache+php, Сейчас они кушают около 40 метров на процесс.
Отключение неиспользуемых модулей apache/php (пересборка только с необходимыми модулями — по желанию, не всегда поможет на VPS).
Ограничение количества процессов apache (вплоть до 1, если сайты пишете вы, и знаете что блокирующих операций нет).
Ограничение лимита памяти PHP до 16 и менее Мб (если скрипты это выдержат).
Или, если сам apache не нужен — то напрямую nginx+PHP в режиме fastCGI, но это немного геморно настраивать.
Ограничение количества процессов apache (вплоть до 1, если сайты пишете вы, и знаете что блокирующих операций нет).
Ограничение лимита памяти PHP до 16 и менее Мб (если скрипты это выдержат).
Или, если сам apache не нужен — то напрямую nginx+PHP в режиме fastCGI, но это немного геморно настраивать.
Отключение неиспользуемых модулей apache/php — особо не помогает. Не забывайте, что память в системах давно уже ушла от простого выделения.
1 процесс апача — кисловато, возможны затыки на аплоадах (почти везде всё равно есть). 2 — 3 я бы сказал.
1 процесс апача — кисловато, возможны затыки на аплоадах (почти везде всё равно есть). 2 — 3 я бы сказал.
Смотря какие модули.
К примеру я сейчас провел ревизию и вспомнил что у меня для какого-то проекта был поставлен ionCube. И из-за этого был выключен eAccelerator — не дружат они.
Убрав первый и включив второй, получил обратно выигрыш примерно в 10метров на каждый процесс апача.
К примеру я сейчас провел ревизию и вспомнил что у меня для какого-то проекта был поставлен ionCube. И из-за этого был выключен eAccelerator — не дружат они.
Убрав первый и включив второй, получил обратно выигрыш примерно в 10метров на каждый процесс апача.
Если перед апачем стоит gninx, то затык с аплоадом будет просто мизерный. И все становится гараздо хуже если php надо ходить на удаленный сервер.
Во что во что ты, Лёша, вогнал MySQL? :) Ты все буфера ему срезал что ли?
UFO just landed and posted this here
убрать из этой связки apache вообще :)
OpenVZ? Вам поможет строка ulimit -s 1024 в /etc/rc.sysinit.
Это свой опыт или повторение распространенного совета?
Если первое — а оно вообще дает эффект?
Если первое — а оно вообще дает эффект?
Свой опыт. У меня тоже расход памяти был в районе 400 метров из 1GB при учете фактического идла(idle), а стоял lighttpd, mysql и php как fastcgi.
Уменьшил размер стёка, ребутнул контейнер — помогло.
Уменьшил размер стёка, ребутнул контейнер — помогло.
Или я что-то не то делаю, или одно из двух.
Насколько я знаю, команда ulimit дает эффект на все процессы, запущенные после его изменения.
После использования этой штуки после перезагрузки памяти действительно меньше отжирается. Но стоит дать нагрузку — все возвращается на круги своя.
Насколько я знаю, команда ulimit дает эффект на все процессы, запущенные после его изменения.
После использования этой штуки после перезагрузки памяти действительно меньше отжирается. Но стоит дать нагрузку — все возвращается на круги своя.
Именно поэтому её надо выполнять в момент старта системы. Я использую для этого rc.sysinit.
Дать нагрузку, или не дать — не важно: флаг -s устанавливает размер стёка для процесса, который на разных системах имеет разный размер. У меня он был 8Мб, кажется.
Попробуйте, а потом расскажите о результатах. Возможно, в вашем случае это не станет панацеей.
Дать нагрузку, или не дать — не важно: флаг -s устанавливает размер стёка для процесса, который на разных системах имеет разный размер. У меня он был 8Мб, кажется.
Попробуйте, а потом расскажите о результатах. Возможно, в вашем случае это не станет панацеей.
Размер стека может быть установлен в конфигах апача, MySQL.
Если там уже стояло мало, то не поможет.
На мелких объемах памяти и ulimit -s 64 можно :-)
Если там уже стояло мало, то не поможет.
На мелких объемах памяти и ulimit -s 64 можно :-)
Вот подскажите, я прописал в /etc/rc.sysinit, но все равно ulimit -s выводит 10240. Где еще можно копнуть, что может менять это значение? На сервере CentOS и Plesk.
Вот засранцы хостеры! За такую оптимизацию расстреливать надо!
Ну хостер оптимизирует себе доход, а не производительность серверов. Я думаю это много где такое. Хочешь, чтобы было хорошо — сделай сам.
Видимо, хостеры под оптимизацией понимают оптимизацию своих прибылей :)
А по поводу обращений к диску — да, на VPS это проблема, в одном месте использовал VPS для отдачи статики через nginx, хостеры сказали, что слишком часто обращается к диску, давайте переходите на тарифный план с большей памятью, чтоб кешировалось. Душила жаба платить не только за память, но и за и так не используемые проц и дисковое пространство. Отключил ведение логов, убрал оттуда часть больших файлов — проблема решилась. С тех пор немного побаиваюсь VPS.
А по поводу обращений к диску — да, на VPS это проблема, в одном месте использовал VPS для отдачи статики через nginx, хостеры сказали, что слишком часто обращается к диску, давайте переходите на тарифный план с большей памятью, чтоб кешировалось. Душила жаба платить не только за память, но и за и так не используемые проц и дисковое пространство. Отключил ведение логов, убрал оттуда часть больших файлов — проблема решилась. С тех пор немного побаиваюсь VPS.
Очевидно, тут явный конфликт интересов: хостеру НЕ выгодно, чтобы Ваш сайт работал быстро после оптимизации, и потреблял мало памяти — ведь тогда он потеряет много денег за грядущие долгие годы.Очень недальновидный подход — сдирать максимум с того, что есть, вместо того, чтобы заботиться о привлечении клиентов. Если хостинг отечественный, то криворукость админа равновероятна ущербности политики руководства. В буржуйском варианте это 100% админский косяк.
у меня было интересней
так как я не админ, не держу проектов, то купил дешевый vps, поставил mysql и прикрутил tracer (он на питоне). Память сразу кончилась. Повысел тариф (все равно копейки). Память опять кончилась. Попросил посмотреть службу поддержки. Они посмотрели, что-то написали, что делать, и сказали, что услуга по оптимизации платная. Я времено положил болт…
Вдруг неожидано в этот тикет приходит ответ: сделал то-то, то-то (с описанием почему это будет работать быстрее) и с подписью: тех. директор
Было очень приятно. Все стало раотать шустро
так как я не админ, не держу проектов, то купил дешевый vps, поставил mysql и прикрутил tracer (он на питоне). Память сразу кончилась. Повысел тариф (все равно копейки). Память опять кончилась. Попросил посмотреть службу поддержки. Они посмотрели, что-то написали, что делать, и сказали, что услуга по оптимизации платная. Я времено положил болт…
Вдруг неожидано в этот тикет приходит ответ: сделал то-то, то-то (с описанием почему это будет работать быстрее) и с подписью: тех. директор
Было очень приятно. Все стало раотать шустро
А зачем утаивать хостера? Какая разница некомпетентный администратор или специально? В любом случае это косяк, и желательно знать, хотя бы где лучше нанять своего админа, чем обращаться к хостеру.
а какая посещаемость сайта?
nginx, 1 процессСпорное решение. На мой взгляд, нужно хотябы два. Пока один залочен на дисковой операции, второй может запросто отдавать что-то из кеша.
В данном конфиге nginx с диском не работает, да и вообще не уверен, что увеличении кол-ва процессов тут помогает.
Объясните эту фразу:
«Zend Optimizer практически не помогает.»
Как ZO может вообще помогать?
«Zend Optimizer практически не помогает.»
Как ZO может вообще помогать?
Не знаю пишу ли по теме, но есть проблема, может опытные люди помогут. Есть файловый сервер работает только на раздачу файликов ~50 Mb. Настроил вроде Апач, что бы при всем желании он не мог съесть всю память (150 процессов макс, средний размер процесса 6Мб, памяти на сервере 2 Гб). Через примерно сутки сервер начинает тормозить, скорость раздачи сильно падает, перезагрузка Апача не помогает! Помогает только reboot. В чем может быть проблема? Система работает под CentOS. Подозрительных процессов не вижу. Пока решаю проблему ребутом по крону раз в сутки, но не радует меня такая система. =(
пользуясь случаем, раз уж пошла речь об оптимизации элементов web-сервера, подскажите пожалуйста, какое количество ждущих процессов (мин, макс) и максимальных процессов Apache будет оптимальным для 50 уников(по 5-10 запросов) в минуту. При этом в плане будет увеличение в 2 или 4 раза. Apache работает в режиме prefork. Память 512Мб.
PS
До этого VPS с default настройками лёг, сейчас, подкрутив конфиги, сервер вроде выдерживает максимальную нагрузку, но боюсь что настройки я поставил неоптимальные :(
ServerLimit 1000
StartServers 100
MinSpareServers 100
MaxSpareServers 200
MaxClients 1000
MaxRequestsPerChild 2000
PS
До этого VPS с default настройками лёг, сейчас, подкрутив конфиги, сервер вроде выдерживает максимальную нагрузку, но боюсь что настройки я поставил неоптимальные :(
ServerLimit 1000
StartServers 100
MinSpareServers 100
MaxSpareServers 200
MaxClients 1000
MaxRequestsPerChild 2000
UFO just landed and posted this here
Это известное заблуждение. Такое же как и «DDOS выгоден для провайдера».
На самом деле нормальному хостеру вовсе невыгодно чтобы у клиента все плохо работало. Иначе он
1) Будет писать кучу запросов и жалоб вида «Какого хрена, за что я вам плачу, ничего не пашет»
2) Будет жаловаться на различных форумах
3) Уйдет к другому хостеру
Ну и вообще, это плохо для кармы.
В данном случае, вероятно, имеет место быть просто неквалифицированно выполненная работа.
На самом деле нормальному хостеру вовсе невыгодно чтобы у клиента все плохо работало. Иначе он
1) Будет писать кучу запросов и жалоб вида «Какого хрена, за что я вам плачу, ничего не пашет»
2) Будет жаловаться на различных форумах
3) Уйдет к другому хостеру
Ну и вообще, это плохо для кармы.
В данном случае, вероятно, имеет место быть просто неквалифицированно выполненная работа.
4) На VPS есть и ещё такой момент — если хостер оверселлит проц/память, то хостер заинтересован в максимальной оптимизации сервера, а на вирт.хостинге — и сайтов (это в том случае, если суточные/пиковые лимиты на процессор/память не лимитированы жёстко).
А по пункту 1 — грамотно настроить сервер ещё и дешевле — в случае неправильной настройки больше времени на переписку уйдёт.
Но полностью исключать вариант, что присутствует попытка продать тариф дороже — исключать всё же нельзя.
А по пункту 1 — грамотно настроить сервер ещё и дешевле — в случае неправильной настройки больше времени на переписку уйдёт.
Но полностью исключать вариант, что присутствует попытка продать тариф дороже — исключать всё же нельзя.
выкиньте вообще апач, если пользуетесь nginx. php запустите в режиме fcgi. сэкономите памяти вагон и маленькую тележку.
Если вам не лень это настраивать, и нет .htaccess, и вам не лень все пересобирать когда обновляется версия PHP тогда конечно все хорошо :-)
ну если лень — то никогда ничего работать не будет как надо :)
Лень — очень ценное инженерное качество. :-)
Цена любого решения = цена реализации + цена поддержки за все последующие годы.
И в случае PHP+FCGI второе как раз сильно увиличевается, т.к. с каждым сервером при любом апдейте придется разбираться вручную.
Цена любого решения = цена реализации + цена поддержки за все последующие годы.
И в случае PHP+FCGI второе как раз сильно увиличевается, т.к. с каждым сервером при любом апдейте придется разбираться вручную.
Пакеты?
Какие пакеты :-) (в смысле именно)
nginx есть в пакетах, PHP — тоже. Что ещё надо? Что вы используете для старта FCGI?
Если голый PHP, то он уже в пакетах, если spawn-fcgi, то его обновлять не надо, он не обновляется. PHP-FPM скоро войдёт в PHP и, сталобыть, появится в пакетах.
Если голый PHP, то он уже в пакетах, если spawn-fcgi, то его обновлять не надо, он не обновляется. PHP-FPM скоро войдёт в PHP и, сталобыть, появится в пакетах.
.htaccess почти всегда можно переписать в конфиге nginx'а. он редко настолько разветвленный, чтобы был вообще звиздетс
Также это чуть медленнее, и нужны дополнительные танцы с бубном для шаринга опкод-кеша между процессами PHP…
Такая конфигурация возможна в поставке из репозитория, без ручной сборки php?
apt-get install php-fcgi
apt-get install nginx
apt-get install nginx
sudo apt-get install php-fcgi
Reading package lists… Done
Building dependency tree
Reading state information… Done
E: Couldn't find package php-fcgi
:-)
Reading package lists… Done
Building dependency tree
Reading state information… Done
E: Couldn't find package php-fcgi
:-)
не помню точное название, apt-cache search php|grep -i fcgi
px@LBox2:~$ apt-cache search php|grep -i fcgi
px@LBox2:~$
Нету такого, пакетом только php-cgi :-)
px@LBox2:~$
Нету такого, пакетом только php-cgi :-)
погуглил — это то же самое
вот например для linode:
library.linode.com/web-servers/nginx/php-fastcgi/debian-5-lenny
library.linode.com/web-servers/nginx/php-fastcgi/debian-5-lenny
кстати — что лучше? mod_php или fcgi?
mod_php быстрее, nginx+fcgi меньше памяти ест.
Это не так. На замерах сайта adme.ru FCGI чуть-чуть уделывал mod_php. Вероятно за счёт меньшего объёма занимаемой памяти — всё-таки системе легче.
Значит тесты бывают разные :-) На тех замерах что видел я — выигрывает как раз mod_php (особенно если апач остается).
И на fcgi нужны легкие танцы с бубном чтобы заставить ускоритель шарить кеш между процессами.
И на fcgi нужны легкие танцы с бубном чтобы заставить ускоритель шарить кеш между процессами.
Я не проводил замеры. Я просто переключал между FCGI и mod_php и смотрел как меняется загрузка машины на этом сайте.
По скорости в тестах в порядке убывания идут:
1. apache + mod_php
2. nginx + php-fcgi
3. nginx + apache + mod_php
4. nginx + apache + php-fcgi
В реальной работе при заметных нагрузках из-за медленных клиентов п.1 быстро проигрывает и уходит в конец списка:
1. nginx + php-fcgi
2. nginx + apache + mod_php
3. nginx + apache + php-fcgi
4. apache + mod_php
1. apache + mod_php
2. nginx + php-fcgi
3. nginx + apache + mod_php
4. nginx + apache + php-fcgi
В реальной работе при заметных нагрузках из-за медленных клиентов п.1 быстро проигрывает и уходит в конец списка:
1. nginx + php-fcgi
2. nginx + apache + mod_php
3. nginx + apache + php-fcgi
4. apache + mod_php
Это такой топик-пиар что-ли?
А что мешает прийти на сервер следубщему админу, настроить его по-своему, показать график, почему это лучше и сделать такой же пост на хабре?
А что мешает прийти на сервер следубщему админу, настроить его по-своему, показать график, почему это лучше и сделать такой же пост на хабре?
Это топик про конфликт интересов.
А сделать такой же пост — ничего, кроме того, что на хабре однотипную статью высоко не оценят. :-)
Однако Вы, как специалист, можете примерно оценить что же я такого уродского сделал, что позволит после меня такую статью написать. Я ведь описал все что сделал :-)
А сделать такой же пост — ничего, кроме того, что на хабре однотипную статью высоко не оценят. :-)
Однако Вы, как специалист, можете примерно оценить что же я такого уродского сделал, что позволит после меня такую статью написать. Я ведь описал все что сделал :-)
Нет, просто я не понял самого смысла топика :)
Ведь если клиент хостера заказал настройку сервера у хостера, а не сделал ее сам, то он не сможет воспользоваться советами из статьи — он просто не знает, как проверить, что php работает как cgi, а у mysql — мало памяти. А по графику munin'a, наверно, пользователь заметил улучшения по сравнению с тем, что было до «настройки».
А лично мне не понравилось из поставленного:
1) mod_php. Пережиток прошлого, уродская штука. Не запускает программы юзера под юзером. Встраивается в веб-сервер. Не thread-safe. Зачем такое нужно? Вместо него рулит php-fcgi или php-fpm.
2) можно было либо отказаться от apache, перейдя на nginx+php-fcgi, либо сделать apache-mpm-worker, что дало бы прирост, но, опять же, запретило mod_php.
Ведь если клиент хостера заказал настройку сервера у хостера, а не сделал ее сам, то он не сможет воспользоваться советами из статьи — он просто не знает, как проверить, что php работает как cgi, а у mysql — мало памяти. А по графику munin'a, наверно, пользователь заметил улучшения по сравнению с тем, что было до «настройки».
А лично мне не понравилось из поставленного:
1) mod_php. Пережиток прошлого, уродская штука. Не запускает программы юзера под юзером. Встраивается в веб-сервер. Не thread-safe. Зачем такое нужно? Вместо него рулит php-fcgi или php-fpm.
2) можно было либо отказаться от apache, перейдя на nginx+php-fcgi, либо сделать apache-mpm-worker, что дало бы прирост, но, опять же, запретило mod_php.
Эта статья — не рекомендации по оптимизации, а описание того что сделал хостер и как плохо после этого стало, и что можно было бы сделать.
1) Нужно для легкого развертывания. Никогда по этому показателю FCGI с ним не сравнится из-за дополнительного демона.
2) Это сложнее в реализации и поддержке, новые сайты с .htaccess трудно добавлять. А apache-mpm-worker — PHP не рекомендуют использовать с MPM: au.php.net/manual/en/faq.installation.php#faq.installation.apache2
1) Нужно для легкого развертывания. Никогда по этому показателю FCGI с ним не сравнится из-за дополнительного демона.
2) Это сложнее в реализации и поддержке, новые сайты с .htaccess трудно добавлять. А apache-mpm-worker — PHP не рекомендуют использовать с MPM: au.php.net/manual/en/faq.installation.php#faq.installation.apache2
Если бы сисадмины были супергероями, я бы выглядел сейчас вот так:
Цитата:
Неработающие страницы оказались из-за конфликта APC и Zend Optimizer(не ожидал однако его тут увидеть)
Т.е. вы, перед тем как начать оптимизировать, не удосужились проверить, с чем там у них PHP работает? ;)
Неработающие страницы оказались из-за конфликта APC и Zend Optimizer(не ожидал однако его тут увидеть)
Т.е. вы, перед тем как начать оптимизировать, не удосужились проверить, с чем там у них PHP работает? ;)
mod_php хорош только при очень грамотном софте сайта.
Если софт кривой, то сначала будет работать хорошо, а потом там будет накапливаться мусору — ой-ей сколько. Память выжрется вся и будет достигнут противоположный эффект.
mod_cgi обычный — решение в этом плане более медленное, но как бы с «защитой от дурака». Если не устраивает, то лучше ставить нечто другое, как писали выше, но не mod_php, под который код нужно писать зная о его подводных камнях.
Если софт кривой, то сначала будет работать хорошо, а потом там будет накапливаться мусору — ой-ей сколько. Память выжрется вся и будет достигнут противоположный эффект.
mod_cgi обычный — решение в этом плане более медленное, но как бы с «защитой от дурака». Если не устраивает, то лучше ставить нечто другое, как писали выше, но не mod_php, под который код нужно писать зная о его подводных камнях.
Под «защитой от дурака» я имел ввиду, что ошибки кодирования PHP не силько критичны, т.к. при завершении скрипта все ресурсы освобождаются.
Приведите пример, где под mod_php что-то не освобождается :-)
При использовании некоторых shared-библиотек, где не очень добросовестно относятся к выделению и освобождению памяти, действительно может возникать утечка. На уровне самого языка всё, конечно, освобождается, но для ОС — нет. Впрочем, поскольку у любого чилда апача есть максимальное количество запросов, которое обслуживать, это не так критично — через какое-то время всё равно процесс умрёт и память вернётся в систему. Но если сильно поднимать MaxRequestsPerChild и/или использовать глючные третьесторонние расширения — огрести можно.
Насколько я помню, такая проблема одно время была с генерацией PDF, приводила к невозможности вызова gs до перезапуска Апача.
Насколько я помню, такая проблема одно время была с генерацией PDF, приводила к невозможности вызова gs до перезапуска Апача.
Может создателю сайта подумать о том чтобы создать мобильную версию сайта, который будет открываться в часы пик.
Давно перестал доверять настройкам хостера, был такой случай, код приложения вылизан, сайт тормозит, php стоял 5.6 в режиме CGI и уже давно устаревший eAccelerator!!! регулярно пропадал DOCUMENT_ROOT и все валилось напрочь =) это уже на тарифе пожирнее на который заказчик перешел из-за того что очень сильно тупил сайт. В итоге бодание с тех поддержкой в течении месяца смена на php7 при котором у них не запускался MYSQL, дошло до того что заказчику втюхали ssd и 4ех ядерный процессор. А я ему сказал давайте возьмем этот сервер который без ssd и с 2умя ядрами и настроим его сами, в итоге страницы открываются у хостера 5-6 сек у того что сам настраивал 1-1.5 сек, а потом выясняется, что кроме всего этого стоял еще включенный xDebug. Так что если тупит сайт не покупайте тариф по жирнее, а найдите лучше нормального админа который это поправит)
Обычно ставлю php7 в режиме fastcgi
nginx и по возможности апач убираю совсем.
Ускоряет ощутимо. Потом уже переход на MariaDB и тонкая настройка.
nginx и по возможности апач убираю совсем.
Ускоряет ощутимо. Потом уже переход на MariaDB и тонкая настройка.
Sign up to leave a comment.
Заказывая оптимизацию сервера у хостера — держи ухо востро