Comments 73
Шикарная статья… очень дельно всё. В мемориз…
Да и кстати в большенстве случаев проблема решается всё же покупкой нового сервера ибо так проще и во многом дешевле чем время простоев и специалиста.
Да вы правы в большенстве случаев нужно все покупать даже депломы и училку по рускому ненужно тратится по чем зря и серверы будут работать хорошо кто бы сомневался.
Решает ли это проблему?
Хостер как я понял у Вас терпеливый и с дельным подходом к клиентам, посоветуете?)
Об авторе — Steffen Konerow, автор High Performance Blog.
Статья — перевод.
Мой совет, nginx (полноценный, т.е. без apache и прочего говна(php fastcgi)), лучше взять бобольше оперативы, и использовать apc либо memcache, постараться закэшировать все редкоизменяемые вещи (оперативка гораздо удобнее харда :) )
Живой пример тому rutracker.org
Живой пример тому rutracker.org
И еще, быстрее PHP только PHP, смарти хоть и удобен для дезигнеров, но от него лучше отказаться
Быстрее PHP только HTML, а смарти позволяет использовать кэширование в HTML с достаточно гибкими правилами инвалидации кэша. Вряд-ли вы сможете быстро переписать CMS для того, чтобы обеспечить и шаблонизацию, и грамотное разделение логики и отображения, и гибкие возможности кэширования. Ну, или как вариант, напишете еще один смарти. Да, можно использовать тот-же blitz, и другие решения, написанные на C, как и blitz, но CMS потребует очень глубокой переработки, сомневаюсь что это экономически целесообразно. Докупить сервер точно дешевле и проще будет.
Мой совет, nginx (полноценный, т.е. без apache и прочего говна(php fastcgi))
А что исполняет php в данной конфигурации?
А что исполняет php в данной конфигурации?
на деле все упирается в производительность базы и php, а не проксирование запросов от nginx к apache и обратно
Позвольте узнать, вы там программист или системный администратор?
Какая-то странная позиция для того, чтобы давать советы: «у нас все тормозило/падало, мы позвонили хостеру/администратору, он что-то сделал, используя [технологию], все заработало».
Очень полезная статья. Есть другие интересные решения в области масштабирования, например апачевский hadoop. Не уверен что это подходит к CMS, но для систем где есть много различных серверных процессов и сервисов подойдет.
Лучше всего Hadoop подходит для пакетной обработки больших объемов данных (это когда у вас терабайты чего-то там и вы хотите какие-то рассчеты произвести над этим, используя пару десятков машин). Там где важно время отклика, он себя с ними ведет намного хуже. Я бы сказал, даже совсем не подходит. Хотя вот StumbleUpon как-то умудрились прикрутить к своему сервису HBase, но как я понимаю, читают они очень маленькие объемы данных (буквально несколько ячеек), так что проблема не так остра для них.
DRBD active-active это вообще говоря типа ядерного реактора
умеючи — приносит свет и тепло, неумеючи — разносит всё так, что мало не кажется
очень интересно посмотреть в честные глаза того хостера, который предложил DRBD active-active, не задавая вопросов о том, что конкретно делается на этой файловой системе и как
ну и вообще говоря масштабируемость и PHP/MySQL, как говорится ...kommt nicht zusammen, kann man nicht binden, sind nicht verwandt… т.е. только с костылями и через тернии
умеючи — приносит свет и тепло, неумеючи — разносит всё так, что мало не кажется
очень интересно посмотреть в честные глаза того хостера, который предложил DRBD active-active, не задавая вопросов о том, что конкретно делается на этой файловой системе и как
ну и вообще говоря масштабируемость и PHP/MySQL, как говорится ...kommt nicht zusammen, kann man nicht binden, sind nicht verwandt… т.е. только с костылями и через тернии
кстати, из статьи можно сделать вывод, что ваш хостер (администратор) был не профессионалом в своей области.
Нормальный админ никогда не поставит крупный проект на апач+мод_пхп
Нормальный админ никогда не поставит крупный проект на апач+мод_пхп
«Почему FastCGI не ускоряет PHP» — dklab.ru/chicken/nablas/49.html
«mod_php vs CGI vs FastCGI» — dev.1c-bitrix.ru/community/blogs/howto/568.php
Вы то сами как профессионал тестировали?
«mod_php vs CGI vs FastCGI» — dev.1c-bitrix.ru/community/blogs/howto/568.php
Вы то сами как профессионал тестировали?
На мой вкус статья банальна и очевидна. О каждом из пунктов в отдельности полно хороших статей.
Никто и не спорит :) Автор приводит свою историю получения опыта в highload в боевых условиях. А также подчеркивает, что оптимизация не завершается никогда и ей нельзя научиться заранее — узкие места бывают разные.
Истины вообще, как правило, банальны и очевидны. Делай зарядку по утрам, работай на любимой работе, а не ради денег, чаще гуляй на свежем воздухе, не пей, а если пьешь — закусывай.
И будешь богатым, умным и здоровым.
Такие уж они, эти истины. Но их банальность и очевидность нисколько не мешает людям на них класть снова и снова.
И будешь богатым, умным и здоровым.
Такие уж они, эти истины. Но их банальность и очевидность нисколько не мешает людям на них класть снова и снова.
Об авторе — Steffen Konerow, автор High Performance Blog.
Я надеюсь, этого в реальности не происходило и описано только в статье. Потому что апач+mod_php, отсутствие memcached, файлы в одной папке — это «вон из профессии» сразу.
Я надеюсь, этого в реальности не происходило и описано только в статье. Потому что апач+mod_php, отсутствие memcached, файлы в одной папке — это «вон из профессии» сразу.
Кешировани смарти, к сожалению, весьма глючная штука, приводящая, иногда, к непредвиденным результатам. Ждем финала Смарти3, хотя более подходящее решение уже найдено:
В нашем частном случае, мы статику кешируем через memcache и nginx отдает ее оттуда напрямую. Если не попал в кеш — проваливаемся в бекенд, который генерирует контент и сохраняет его в memcache
При этом имеем:
— возможность отдавать всю «статику» практически моментально
— при потере кеша он быстро восстанавливается
— динамические блоки собираются nginx через SSI (с предварительной проверкой на такую же закешированность в мемкеше). при этом собираются они параллельно и в случае отсутствия закешированного значения запросы «проваливаются» на разные бекенды одновременно (снижение нагрузки на каждый отдельно-взятый бекенд)
В нашем частном случае, мы статику кешируем через memcache и nginx отдает ее оттуда напрямую. Если не попал в кеш — проваливаемся в бекенд, который генерирует контент и сохраняет его в memcache
При этом имеем:
— возможность отдавать всю «статику» практически моментально
— при потере кеша он быстро восстанавливается
— динамические блоки собираются nginx через SSI (с предварительной проверкой на такую же закешированность в мемкеше). при этом собираются они параллельно и в случае отсутствия закешированного значения запросы «проваливаются» на разные бекенды одновременно (снижение нагрузки на каждый отдельно-взятый бекенд)
Походу админ крутой а программисты не очень раз такая система)
смарти ещё и тормаз редкостный…
но, блин, гибкий, сцуко… за то и любим… :(
х)) а какие из его гибкостей вы используете?
в частности (из наиболее критичных):
1) динамически регистрирующиеся модификаторы и блоки
2) поиск шаблона по заданному дереву (удобно для whitelabelling)
3) замечательная изоляция в пределах инклюда (фетчинга) шаблона
+
4) пре-компиляция в качестве «гибкости» засчитывается?
5) упрощенная логика приложения в шаблоне для неособо умного дизайнера засчитывается?
1) динамически регистрирующиеся модификаторы и блоки
2) поиск шаблона по заданному дереву (удобно для whitelabelling)
3) замечательная изоляция в пределах инклюда (фетчинга) шаблона
+
4) пре-компиляция в качестве «гибкости» засчитывается?
5) упрощенная логика приложения в шаблоне для неособо умного дизайнера засчитывается?
но, блин, гибкий, сцуко… за то и любим… :(
UFO just landed and posted this here
теоретически, вероятный вариант
а) nagios (или иная система) сидит внутрисети, а упали внешние каналы
б) nagios (или иная система) долбит мало-зависящий от внешних факторов скрипт в качестве проверки живучести сайта
в) nagios (или иная система) проверяет живучесть с интервалом в каждые 3-5 минут. у нас иногда Call Centre или Customer Support звонит на минуту-две раньше, чем приходит СМС с проблемой…
а) nagios (или иная система) сидит внутрисети, а упали внешние каналы
б) nagios (или иная система) долбит мало-зависящий от внешних факторов скрипт в качестве проверки живучести сайта
в) nagios (или иная система) проверяет живучесть с интервалом в каждые 3-5 минут. у нас иногда Call Centre или Customer Support звонит на минуту-две раньше, чем приходит СМС с проблемой…
Ничего не написано про сам проект, непонятно какой он был. Иногда на сайте много картинок, тогда нужно оптимизировать одно, иногда много запросов к базе, тогда другое. Просто миллион посетителей в месяц — это примерно 30 тысяч в день, что на самом деле не так много для рядового сайта, поэтому очень не хватает описания специфики работы.
Я один такой, скажите в чем профит от варниша(ваниша)??? Чем им кеш в nginx неугодил? там если юзать +perl+memcache можно вообще оч крутую систему кеширования организовать
А причем тут, собственно, Perl?
Про Варниш — строгий RTFM. Это просто другое средство для повышения производительности/масштабируемости.
Про Варниш — строгий RTFM. Это просто другое средство для повышения производительности/масштабируемости.
Записки Капитана…
Не читайте хабр и ваш сайт упадет
И не насилуйте особо сильно оптимизационую сторону, а то не из-за кого будет сайту падать.
И не насилуйте особо сильно оптимизационую сторону, а то не из-за кого будет сайту падать.
Не хочу быть занудой, но apache по тексту вобще ни причем. У меня apache спокойно держит 80-100 запросов в секунду (на одном сервере) без падений и железо примерно такое же как у вас.
Сейчас вот что показывает:
Server uptime: 15 hours 28 minutes 34 seconds
Total accesses: 4096855 — Total Traffic: 6.8 GB
CPU Usage: u21245.7 s6862.09 cu0 cs0 — 50.5% CPU load
73.5 requests/sec
48 requests currently being processed, 0 idle workers
А по nginx — то он удобен и хорош в раздаче статики.
Memcache это конечно «волшебная палочка» для любого проекта, без больших изминений проекта можно добиться стабильности и скорости.
Кстати забыли написать про сессии в PHP — их тоже лучше хранить в memcache, для того что бы избежать проблем с I/O.
Сейчас вот что показывает:
Server uptime: 15 hours 28 minutes 34 seconds
Total accesses: 4096855 — Total Traffic: 6.8 GB
CPU Usage: u21245.7 s6862.09 cu0 cs0 — 50.5% CPU load
73.5 requests/sec
48 requests currently being processed, 0 idle workers
А по nginx — то он удобен и хорош в раздаче статики.
Memcache это конечно «волшебная палочка» для любого проекта, без больших изминений проекта можно добиться стабильности и скорости.
Кстати забыли написать про сессии в PHP — их тоже лучше хранить в memcache, для того что бы избежать проблем с I/O.
апач может и больше обслуживать в секунду.
nginx ставят для того что бы апач быстро отдавал контент и освобождал форки, которые, если медленно отдают сеть контент (клиенты на модемах), в силу синхронной природы занимают форки (по одному на запрос) и упираешься в MaxClients (в отличии от асинхронного nginx или lighttpd).
nginx ставят для того что бы апач быстро отдавал контент и освобождал форки, которые, если медленно отдают сеть контент (клиенты на модемах), в силу синхронной природы занимают форки (по одному на запрос) и упираешься в MaxClients (в отличии от асинхронного nginx или lighttpd).
Total accesses: 19283736 - Total Traffic: 24.0 GB CPU Usage: u1022.5 s28.86 cu0 cs0 - .232% CPU load 84.6 requests/sec - 110.7 kB/second - 1338 B/request 4 requests currently being processed, 11 idle workers
это я к тому что судя по вашим 48 воркерам у вас запросы по полсекунды генерятся, что уже не показатель быстрой работы.
А у меня и отработка быстрее, и проца меньше кушает. Правда не знаю чего он в статистике так мало рисует, там вообще где-то 30-40% нагрузка в среднем
30 тыс. посетителей в день на обычном сайте можно поднять и на среднем по мощности сервере безо всяких ухищрений.
безо всякого кеширования — чисто пхп+апач
1. Смотря как эти пользователи «размазаны» по суткам. Автор пишет, что основной пик вечером, а ночью глухо. Если выбросить 10 часов на «ночь», получается 1М / 30 / (24 — 10) = 2380 в час. В пике нагрузка легко может прыгнуть в 5 раз от «среднего». Далее, не зыбываем, что это уники, которые делают несколько просмотров.
2. Надо учитывать, что из себя представлят проект: новостной сайт и youtube.com — это разные проекты.
Так что «30 тыс. посетителей в день… на среднем по мощности сервере» — это весьма спорное утверждение.
2. Надо учитывать, что из себя представлят проект: новостной сайт и youtube.com — это разные проекты.
Так что «30 тыс. посетителей в день… на среднем по мощности сервере» — это весьма спорное утверждение.
Я бы ещё добавил замечание о файловом кэше. Если у вас был один сервер, а потом вдруг их стало два, то у каждого из них будет свой файловый кэш. Код может на это быть не рассчитан, причём сразу такие вещи имеют свойство быть не замеченными.
Мы установили, что узким местом является MySQL и опять позвонили хостеру. Они посоветовали master-slave репликацию MySQL со slave на каждом веб-сервере.
Я не понял. У них стало три mysql сервера? Один заявленный в начале мастер и по одному слейву на каждом веб сервере?
Я не понял. У них стало три mysql сервера? Один заявленный в начале мастер и по одному слейву на каждом веб сервере?
Что бы Вы ни делали, Ваш сайт все-равно рано или поздно упадет. Закон Мерфи.
Как это замечательно, не только у нас все делают через жёпу, а потом разгребают :)
Пустите программиста заниматься инфраструктурой сервиса и ресурсами сервера, и он точно упадет :)
Товарищам просто нужен был сисадмин: все кочки в статье уровня novice :)
Товарищам просто нужен был сисадмин: все кочки в статье уровня novice :)
А не из сисадминов ли и программистов вырастают архитекторы?
статья хорошая, написана с юмором
все грабли известные… Ну сколько можно на них наступать по 10 раз.
я долго смеялся.
надо изначально разрабатывать архитектуру нормально.
Понятно, что кто ни чеге не делает, тот не ошибается, но и учиться можно на чужих ошибках, а не на своих.
Ну и в заключение nginx+php-fpm надежней чем lighttpd + spawn-php
(спавнер имеет утечки)
все грабли известные… Ну сколько можно на них наступать по 10 раз.
я долго смеялся.
надо изначально разрабатывать архитектуру нормально.
Понятно, что кто ни чеге не делает, тот не ошибается, но и учиться можно на чужих ошибках, а не на своих.
Ну и в заключение nginx+php-fpm надежней чем lighttpd + spawn-php
(спавнер имеет утечки)
Анти-паттерны хороши! Ёжики кололись и плакали :) Когда уже прекратят тестировать на юзерах? Тогда, когда юзеры перестанут им это позволять. В корпоративном сегменте это лечится финансовыми исками, после чего вся миграция проходит только через тестовые стенды и несколько видов нагрузочного тестирования. И, да, мы тестируем.
Sign up to leave a comment.
6 способов убить Ваши сервера — познаем масштабируемость трудным путем