Как стать автором
Обновить

Комментарии 23

Для полноты картины не хватает nginx, который стоит перед apache (и, например, отдаёт статику и медленно отдаёт ответ клиенту, в то время как процесс апача уже давно освободил память и ресурсы).
И вот так, легко и непринуждённо, автор прорекламировал свой интернет-магазин до релиза, бонусом подняв его рейтинг счётчиком посещений. Я.Метрика подрублена — всё хорошо! SEO выходит на новый уровень, гы.

И прокачал поведенческие факторы айпи адресу, а не домену? Ну-ну

Для полноты картины не хватает Apache + PHP-FPM.
Такая связка будет чуть тормознее mod_php.
Проблема «тормозов» apache+mod_php не в mod_php, она в том, что тюнинг prefork апача сродни некоторой магии, и если идти по простому пути — то простой выход – подставить nginx перед апачем, как раз для того, чтоб медленные клиенты не держали в памяти апач долго
Если звездный час близок, разве не логично выделенный сервер арендовать с гигабитным каналом? Простенькие (ДЦ в РФ) 3500р в месяц стоят.

Некоторым ИП даже 500 рублей на вдску жалко, а вы тут аж на три с половиной тыщи загнули)

НЛО прилетело и опубликовало эту надпись здесь
Из графиков видно что автор не сумел создать достойной нагрузки, которая нагнула бы сервер. В целом непонятно что тестировалось — реальное приложение использует диск и базу (а она опять диск), что обычно и является узким местом. Какие были диски — непонятно, но создается ощущение что основная нагрузка была на чтение, когда все эффективно кэшится в ОП и диск почтни не грузится.
Если в апаче отключить ненужный хлам поставляемый по умолчанию, превратив его примерно в nginx по функционалу, то разница в производительности будет не драматическая.
НЛО прилетело и опубликовало эту надпись здесь
4330? Чем смотрите? Сколько ОЗУ расходуется?
НЛО прилетело и опубликовало эту надпись здесь
Я поясню, почему приведенные цифры вызывают вопросы.
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 адреса? Метрика подключена — и что? Или он думал, что и правда скоро появится инет-магазин, продающий одежду и пиццу?))
Да, аудитория хабра — не самая благодарная для таких статей. Но, знаете, я этот путь прошел сам и захотел им поделиться с другими. Свои соображения я подкрепил скриншотами. А отталкивался от того, что много кто хочет создать свой сайт и кому-то возможно будет полезно это. Вы скажете, мол, пусть создают тогда на конструкторах/хостингах? Нет. Если новый человек хочет создать сайт на впс (неважно почему), я считаю. что эта статья будет ему полезна.
1. Я тоже не против панелей управления веб-сервером. Хотя платить за неё деньги не стал бы (как в случае с ISPmgr, но VestaCP поставить очень даже можно — хуже не станет уж точно, и даже абстрагируясь от гуёв это удобно — Веста обладает удобным набором v-...-команд);
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. Спасибо за критику статьи. Я не ожидал, конечно, что эта статья соберет много лайков или как их там… карм… что тут используется? Я был готов и к негативу. Мол, твоя статья — отстой, потому что нужно то делать так вот и так и тогда результаты будут такие вот:…
Но. Наверно я неправильно спозиционировал статью. Ведь я ее писал исходя из собственного опыта. Я думал, что таких же как я много. Да, они не сидят на хабре прямо сейчас, но, возможно, потом появятся. или уже появлялись в прошлом.
Мне мой опыт был полезен.
Если новый человек хочет создать сайт на впс (неважно почему), я считаю. что эта статья будет ему полезна
Дело в том, что если человек просто хочет создать сайт и пусть висит — ему по фиг на эти разницы между нагрузками.
Если же сайт претендует на серьезность и нагрузки действительно важны, то ни при каких обстоятельствах хостингом не окажется автоматически установленный вдс с автоматически установленными панелями с автоматически выставленными дефолтными настройками. Либо будет нанят админ для настройки, либо человек сам должен будет разобраться и настроить

использую GUI (а по факту isp manager):
Не очень помним что там в исп менеджере, но неужели там нет возможности настроить апач хотя бы немного? Выставить другой режим, отключить модули — в рамках гуя?
Естественно, ISPmanager, VestaCP… оно всё не для хайлоада, скорее. Но оно реализует, как минимум, удобный унифицированный аккаунтинг и менеджмент сервисами. И оно не должно мешать тюнить конфигурацию вручную когда это понадобится. Даже если и будет — это легко обойти воркараундом. А вот собирать дефолтный веб-сервер атомарными кусочками — не очень весёлое и не очень оправданное занятие, если он дефолтный. Суть в том, что и на дефолтном веб-сервере неожиданно может выпрыгнуть из-за кустов хайлоад.
У вас на третьей картинке с VPS с апачом 43.8% CPU steal time. Вот это настоящая проблема, а не то, что оперативка закончилась. По своему опыту могу сказать, что steal time в районе 20% — это уже практически равносильно смерти, т.к. ничего нормально не работает.
Ну так это же VPS, что Вы хотите. Чтоб избавиться от steal надо нормальный сервер.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории