Comments 23
Для полноты картины не хватает nginx, который стоит перед apache (и, например, отдаёт статику и медленно отдаёт ответ клиенту, в то время как процесс апача уже давно освободил память и ресурсы).
И вот так, легко и непринуждённо, автор прорекламировал свой интернет-магазин до релиза, бонусом подняв его рейтинг счётчиком посещений. Я.Метрика подрублена — всё хорошо! SEO выходит на новый уровень, гы.
Для полноты картины не хватает Apache + PHP-FPM.
Такая связка будет чуть тормознее mod_php.
Проблема «тормозов» apache+mod_php не в mod_php, она в том, что тюнинг prefork апача сродни некоторой магии, и если идти по простому пути — то простой выход – подставить nginx перед апачем, как раз для того, чтоб медленные клиенты не держали в памяти апач долго
Проблема «тормозов» apache+mod_php не в mod_php, она в том, что тюнинг prefork апача сродни некоторой магии, и если идти по простому пути — то простой выход – подставить nginx перед апачем, как раз для того, чтоб медленные клиенты не держали в памяти апач долго
Если звездный час близок, разве не логично выделенный сервер арендовать с гигабитным каналом? Простенькие (ДЦ в РФ) 3500р в месяц стоят.
UFO just landed and posted this here
Из графиков видно что автор не сумел создать достойной нагрузки, которая нагнула бы сервер. В целом непонятно что тестировалось — реальное приложение использует диск и базу (а она опять диск), что обычно и является узким местом. Какие были диски — непонятно, но создается ощущение что основная нагрузка была на чтение, когда все эффективно кэшится в ОП и диск почтни не грузится.
Если в апаче отключить ненужный хлам поставляемый по умолчанию, превратив его примерно в nginx по функционалу, то разница в производительности будет не драматическая.
UFO just landed and posted this here
4330? Чем смотрите? Сколько ОЗУ расходуется?
UFO just landed and posted this here
Я поясню, почему приведенные цифры вызывают вопросы.
4330 воркеров. php-fpm воркер даже в простое это где-то ~16Мб ОЗУ. Получается, что на сервере только fpm потребляет: 4330*16=~67 Гб (!) ОЗУ. У вас сервер с 128 Гб ОЗУ? Сервера с таким объемом ОЗУ лично у меня только под нагруженными сервисами аналитики.
Касательно лога. Хотелось бы увидеть вывод:
Кроме того не видно, какие из запросов динамика, а какие статика. Судя по всему в логе они находятся в одной куче.
4330 воркеров. php-fpm воркер даже в простое это где-то ~16Мб ОЗУ. Получается, что на сервере только fpm потребляет: 4330*16=~67 Гб (!) ОЗУ. У вас сервер с 128 Гб ОЗУ? Сервера с таким объемом ОЗУ лично у меня только под нагруженными сервисами аналитики.
Касательно лога. Хотелось бы увидеть вывод:
head -n1 1001freefonts.com.logКроме того не видно, какие из запросов динамика, а какие статика. Судя по всему в логе они находятся в одной куче.
Статья плохая. Заявленная тема раскрыта плохо, советы так же крайне сомнительные. Если кратко, то взяли три непонятных площадки в непонятной конфигурации, непонятно как нагрузили и сразу сделали выводы и дали неправильный советы (не нужно включать в режиме ondemand, задумайтесь о схеме запуска воркеров и накладных расходах связанных с этим). Характер нагрузки тоже выбран плохо. Обычная страница сейчас это один запрос порождающий за собой 1-5 AJAX запросов в течении первых 5-7 секунд. Про конфигурирование через GUI я вообще молчу…
Вообще расчет требуемого железа делается совершенно не так. И нагрузочное так же нужно делать с пониманием того, как это работает на сервере. Не буду повторятося и просто приведу видео: Сколько выдержит мой сервер?
Вообще расчет требуемого железа делается совершенно не так. И нагрузочное так же нужно делать с пониманием того, как это работает на сервере. Не буду повторятося и просто приведу видео: Сколько выдержит мой сервер?
Называется этот режим worker, в отличие от дефолтного prefork. Но установить его непросто, в панелях типа ISP это сделать невозможно, а если озадачиться и попытаться это осуществить через ssh, то выяснится, что для этого мало выключить prefork и включить worker, еще нужна тредобезопасная версия php
А какая версия Apache, простите, использовалась? Вместо worker давно есть event-MPM, который замечательно работает на Apache 2.4.10+, а с 2.4.24+ и подавно.
Да и вообще, официальный сайт PHP не рекомендует устанавливать этот режим.
Неверно, неправильно вы прочитали. Официальный сайт не рекомендует поточный режим Apache для mod_php, для FastCGI (PHP-FPM) это наилучшая практика.
Сколько не тестил сам, Apache 2.4.24(и выше)+mod_proxy+mod_proxy_fcgi+PHP-FPM 5.6 (и выше) работают ничуть не хуже Nginx+PHP-FPM, а иногда даже стабильнее.
Просто в апач нужно уметь, читать правильную документацию, правильно сконфигурировать и будет счастье.
А клац-клац мейнстримовый Nginx (еще и через ISP-панель) по заметкам из ИТ-бложиков — это не показатель, уж простите.
отвечу вам, но в ответе немного обобщу настроения пользователей хабра, которое я испытал на себе:
Итак. красной нитью в комментах лежит осуждение меня за то, что использую GUI (а по факту isp manager): дело то в том, что статья изначально была ориентирована не на таких уж протертых юзеров, которые и ламп сами установят и сконфигурируют сервер в консоли (да, таких много).
даже если кто-то, допустим, очень прошаренный, я не вижу причин не использовать панели управления серверами. Будь то или isp или vesta. Ну да это бох с ним.
по поводу для FastCGI (PHP-FPM) это наилучшая практика. — так я ведь о этом и писал, разве нет?
Про «коня в вакууме» — да, тесты были сделаны для сайта на могуте, еще и демонстрационного, но сравнивать то режимы это позволяет?, разве нет? И потом уже думать, как экстраполировать на реальный проект, например можно этот проект склонировать на тестовый впс и протестировать.
Про рекламу: не понимаю единственного коммента товарища tchspprt который посчитал это всё за рекламу. Рекламу чего? IP адреса? Метрика подключена — и что? Или он думал, что и правда скоро появится инет-магазин, продающий одежду и пиццу?))
Да, аудитория хабра — не самая благодарная для таких статей. Но, знаете, я этот путь прошел сам и захотел им поделиться с другими. Свои соображения я подкрепил скриншотами. А отталкивался от того, что много кто хочет создать свой сайт и кому-то возможно будет полезно это. Вы скажете, мол, пусть создают тогда на конструкторах/хостингах? Нет. Если новый человек хочет создать сайт на впс (неважно почему), я считаю. что эта статья будет ему полезна.
Итак. красной нитью в комментах лежит осуждение меня за то, что использую GUI (а по факту isp manager): дело то в том, что статья изначально была ориентирована не на таких уж протертых юзеров, которые и ламп сами установят и сконфигурируют сервер в консоли (да, таких много).
даже если кто-то, допустим, очень прошаренный, я не вижу причин не использовать панели управления серверами. Будь то или isp или vesta. Ну да это бох с ним.
по поводу для FastCGI (PHP-FPM) это наилучшая практика. — так я ведь о этом и писал, разве нет?
Про «коня в вакууме» — да, тесты были сделаны для сайта на могуте, еще и демонстрационного, но сравнивать то режимы это позволяет?, разве нет? И потом уже думать, как экстраполировать на реальный проект, например можно этот проект склонировать на тестовый впс и протестировать.
Про рекламу: не понимаю единственного коммента товарища tchspprt который посчитал это всё за рекламу. Рекламу чего? IP адреса? Метрика подключена — и что? Или он думал, что и правда скоро появится инет-магазин, продающий одежду и пиццу?))
Да, аудитория хабра — не самая благодарная для таких статей. Но, знаете, я этот путь прошел сам и захотел им поделиться с другими. Свои соображения я подкрепил скриншотами. А отталкивался от того, что много кто хочет создать свой сайт и кому-то возможно будет полезно это. Вы скажете, мол, пусть создают тогда на конструкторах/хостингах? Нет. Если новый человек хочет создать сайт на впс (неважно почему), я считаю. что эта статья будет ему полезна.
1. Я тоже не против панелей управления веб-сервером. Хотя платить за неё деньги не стал бы (как в случае с ISPmgr, но VestaCP поставить очень даже можно — хуже не станет уж точно, и даже абстрагируясь от гуёв это удобно — Веста обладает удобным набором v-...-команд);
2. Господа edogs и Planet_Dust немного пояснили — можно наотключать кучу бай дефолт включенных модулей, перейти на event (читайте epoll) вместо prefork, оттюнить и отполировать Apache до состояния, слабо отличающегося от nginx… суть в том, что Ваша статья не полна с точки зрения теории, а значит не очень показательна для новичка — если ориентироваться на эти данные, то можно пойти по ложному посылу;
3. Я не обладаю для этого достаточной квалификацией, но могу предположить, что Я.Метрику можно подрубить к in-addr.arpa-домену, после чего прописать PTR-запись. А насчёт одежды и пиццы — поправимо, ибо я же сказал, цитата, «до релиза». Я могу быть неправ, ибо я понятия не имею о SEO, но неправым полностью я быть не могу — с этого всего можно словить бонусы;
4. «Критикуешь — предлагай», как грицца. А у меня нуль публикаций :) Так что мою критику можно отсечь с аргументом «спердобейся». Вы в любом случае молодец — даже если Вы написали не до конца правильно информирующую статью — Вас поправили в комментариях с информацией, актуальной на 2018 год. Как известно, у 99% статей комментарии интереснее и важнее самой статьи. Данная тематика на хабре почти исчезает, в любом случае читать Ваш труд — лучше, чем заниматься некропостингом, хоть и по содержанию самой статьи разница мала.
2. Господа edogs и Planet_Dust немного пояснили — можно наотключать кучу бай дефолт включенных модулей, перейти на event (читайте epoll) вместо prefork, оттюнить и отполировать Apache до состояния, слабо отличающегося от nginx… суть в том, что Ваша статья не полна с точки зрения теории, а значит не очень показательна для новичка — если ориентироваться на эти данные, то можно пойти по ложному посылу;
3. Я не обладаю для этого достаточной квалификацией, но могу предположить, что Я.Метрику можно подрубить к in-addr.arpa-домену, после чего прописать PTR-запись. А насчёт одежды и пиццы — поправимо, ибо я же сказал, цитата, «до релиза». Я могу быть неправ, ибо я понятия не имею о SEO, но неправым полностью я быть не могу — с этого всего можно словить бонусы;
4. «Критикуешь — предлагай», как грицца. А у меня нуль публикаций :) Так что мою критику можно отсечь с аргументом «спердобейся». Вы в любом случае молодец — даже если Вы написали не до конца правильно информирующую статью — Вас поправили в комментариях с информацией, актуальной на 2018 год. Как известно, у 99% статей комментарии интереснее и важнее самой статьи. Данная тематика на хабре почти исчезает, в любом случае читать Ваш труд — лучше, чем заниматься некропостингом, хоть и по содержанию самой статьи разница мала.
1. Ну да, я ведь о том и говорил в заключении — что, мол, скорее всего вы захотите отказаться от панели управления (имею ввиду платные типа isp), после того как сервер будет полностью настроен и переведен в состояние релиза. Даже дал парочку рекомендаций в связи с этим, а вы почему то меня всеравно залошили. Дело в том, что я так и сделал, поэтому в статье решил упомянуть эти панели управления, черт бы их дери.
2. Моя статья не полна, — да так можно сказать о любой статье.
перейти на event (читайте epoll) — скажите как это сделать просто и легко. Пусть это будут команды для ubuntu. Если они сработают, я свою статью удалю нафиг, если вдруг окажется, что под этими режимами результаты лучше чем для perfork. Потому что я не нашел метода, который бы выключал перфорк и включал епол ваш этот.
3. вы серёзно думаете, что если допустим 100500 пользователей зайдет на адрес типа 130.193.44.219 то потом это можно как-то трансформировать в полезные поведенческие факторы для уже адреса с доменом? Если да, то напишите об этом статью. Кстати, без издевок, я например, не знаю. Но мне кажется такая статья взлетит )
4. Спасибо за критику статьи. Я не ожидал, конечно, что эта статья соберет много лайков или как их там… карм… что тут используется? Я был готов и к негативу. Мол, твоя статья — отстой, потому что нужно то делать так вот и так и тогда результаты будут такие вот:…
Но. Наверно я неправильно спозиционировал статью. Ведь я ее писал исходя из собственного опыта. Я думал, что таких же как я много. Да, они не сидят на хабре прямо сейчас, но, возможно, потом появятся. или уже появлялись в прошлом.
Мне мой опыт был полезен.
2. Моя статья не полна, — да так можно сказать о любой статье.
перейти на event (читайте epoll) — скажите как это сделать просто и легко. Пусть это будут команды для ubuntu. Если они сработают, я свою статью удалю нафиг, если вдруг окажется, что под этими режимами результаты лучше чем для perfork. Потому что я не нашел метода, который бы выключал перфорк и включал епол ваш этот.
3. вы серёзно думаете, что если допустим 100500 пользователей зайдет на адрес типа 130.193.44.219 то потом это можно как-то трансформировать в полезные поведенческие факторы для уже адреса с доменом? Если да, то напишите об этом статью. Кстати, без издевок, я например, не знаю. Но мне кажется такая статья взлетит )
4. Спасибо за критику статьи. Я не ожидал, конечно, что эта статья соберет много лайков или как их там… карм… что тут используется? Я был готов и к негативу. Мол, твоя статья — отстой, потому что нужно то делать так вот и так и тогда результаты будут такие вот:…
Но. Наверно я неправильно спозиционировал статью. Ведь я ее писал исходя из собственного опыта. Я думал, что таких же как я много. Да, они не сидят на хабре прямо сейчас, но, возможно, потом появятся. или уже появлялись в прошлом.
Мне мой опыт был полезен.
Если новый человек хочет создать сайт на впс (неважно почему), я считаю. что эта статья будет ему полезнаДело в том, что если человек просто хочет создать сайт и пусть висит — ему по фиг на эти разницы между нагрузками.
Если же сайт претендует на серьезность и нагрузки действительно важны, то ни при каких обстоятельствах хостингом не окажется автоматически установленный вдс с автоматически установленными панелями с автоматически выставленными дефолтными настройками. Либо будет нанят админ для настройки, либо человек сам должен будет разобраться и настроить
использую GUI (а по факту isp manager):Не очень помним что там в исп менеджере, но неужели там нет возможности настроить апач хотя бы немного? Выставить другой режим, отключить модули — в рамках гуя?
Естественно, ISPmanager, VestaCP… оно всё не для хайлоада, скорее. Но оно реализует, как минимум, удобный унифицированный аккаунтинг и менеджмент сервисами. И оно не должно мешать тюнить конфигурацию вручную когда это понадобится. Даже если и будет — это легко обойти воркараундом. А вот собирать дефолтный веб-сервер атомарными кусочками — не очень весёлое и не очень оправданное занятие, если он дефолтный. Суть в том, что и на дефолтном веб-сервере неожиданно может выпрыгнуть из-за кустов хайлоад.
У вас на третьей картинке с VPS с апачом 43.8% CPU steal time. Вот это настоящая проблема, а не то, что оперативка закончилась. По своему опыту могу сказать, что steal time в районе 20% — это уже практически равносильно смерти, т.к. ничего нормально не работает.
Sign up to leave a comment.
Выбор режима работы web-сервера на личном опыте