Pull to refresh

Comments 73

Шикарная статья… очень дельно всё. В мемориз…
Да и кстати в большенстве случаев проблема решается всё же покупкой нового сервера ибо так проще и во многом дешевле чем время простоев и специалиста.
Да вы правы в большенстве случаев нужно все покупать даже депломы и училку по рускому ненужно тратится по чем зря и серверы будут работать хорошо кто бы сомневался.
> нужно все покупать даже депломы и училку по рускому ненужно тратится по чем зря

По вам это, кстати, хорошо видно.
это была ирония к предыдущему комментарию (:
Зря минусуете, человек грамотно пишет, просто слишком саркастически пошутил.
Какая-то толстая ирония… хотя специально залез, посмотрел его другие комментарии — пишет грамотно.
Наоборот, слишком тонкая — так что даже не все замечают, что это, собственно, ирония.
Решает ли это проблему?
А потом Ваш сайт упадет…
Хостер как я понял у Вас терпеливый и с дельным подходом к клиентам, посоветуете?)
Мой совет, nginx (полноценный, т.е. без apache и прочего говна(php fastcgi)), лучше взять бобольше оперативы, и использовать apc либо memcache, постараться закэшировать все редкоизменяемые вещи (оперативка гораздо удобнее харда :) )
Живой пример тому rutracker.org
И еще, быстрее PHP только PHP, смарти хоть и удобен для дезигнеров, но от него лучше отказаться
Быстрее PHP только HTML, а смарти позволяет использовать кэширование в HTML с достаточно гибкими правилами инвалидации кэша. Вряд-ли вы сможете быстро переписать CMS для того, чтобы обеспечить и шаблонизацию, и грамотное разделение логики и отображения, и гибкие возможности кэширования. Ну, или как вариант, напишете еще один смарти. Да, можно использовать тот-же blitz, и другие решения, написанные на C, как и blitz, но CMS потребует очень глубокой переработки, сомневаюсь что это экономически целесообразно. Докупить сервер точно дешевле и проще будет.
Мой совет, nginx (полноценный, т.е. без apache и прочего говна(php fastcgi))
А что исполняет php в данной конфигурации?
Я имел в виду отказаться от шкафов, типа apache, lighttpd, вместо них используя php в качестве fastcgi
А, я подумал, что php fastcgi тоже относится к говну, ок :)
А Лайти-то чем «шкаф»?..
на деле все упирается в производительность базы и 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… т.е. только с костылями и через тернии
кстати, из статьи можно сделать вывод, что ваш хостер (администратор) был не профессионалом в своей области.
Нормальный админ никогда не поставит крупный проект на апач+мод_пхп
Ну я во-первых не администратор, тем более не профессиональный :)
А во-вторых можно хотя бы nginx поверх было поставить, для отдачи статики хотя бы.
А про fastcgi читал этот материал. Спасибо
На мой вкус статья банальна и очевидна. О каждом из пунктов в отдельности полно хороших статей.
Никто и не спорит :) Автор приводит свою историю получения опыта в highload в боевых условиях. А также подчеркивает, что оптимизация не завершается никогда и ей нельзя научиться заранее — узкие места бывают разные.
Истины вообще, как правило, банальны и очевидны. Делай зарядку по утрам, работай на любимой работе, а не ради денег, чаще гуляй на свежем воздухе, не пей, а если пьешь — закусывай.
И будешь богатым, умным и здоровым.

Такие уж они, эти истины. Но их банальность и очевидность нисколько не мешает людям на них класть снова и снова.
Об авторе — Steffen Konerow, автор High Performance Blog.

Я надеюсь, этого в реальности не происходило и описано только в статье. Потому что апач+mod_php, отсутствие memcached, файлы в одной папке — это «вон из профессии» сразу.
Если внимательно почиать статью, то на момент описываемого проекта у автора не было опыта в highload :)
Кешировани смарти, к сожалению, весьма глючная штука, приводящая, иногда, к непредвиденным результатам. Ждем финала Смарти3, хотя более подходящее решение уже найдено:
В нашем частном случае, мы статику кешируем через memcache и nginx отдает ее оттуда напрямую. Если не попал в кеш — проваливаемся в бекенд, который генерирует контент и сохраняет его в memcache
При этом имеем:
— возможность отдавать всю «статику» практически моментально
— при потере кеша он быстро восстанавливается
— динамические блоки собираются nginx через SSI (с предварительной проверкой на такую же закешированность в мемкеше). при этом собираются они параллельно и в случае отсутствия закешированного значения запросы «проваливаются» на разные бекенды одновременно (снижение нагрузки на каждый отдельно-взятый бекенд)
Походу админ крутой а программисты не очень раз такая система)
походу, и админ и девелоперы круты, но шибко большой трафик, а такая система — заслуга системного архитектора, и экономит от 4 до 6 серверов для компании ;)
смарти ещё и тормаз редкостный…
но, блин, гибкий, сцуко… за то и любим… :(
х)) а какие из его гибкостей вы используете?
в частности (из наиболее критичных):
1) динамически регистрирующиеся модификаторы и блоки
2) поиск шаблона по заданному дереву (удобно для whitelabelling)
3) замечательная изоляция в пределах инклюда (фетчинга) шаблона

+
4) пре-компиляция в качестве «гибкости» засчитывается?
5) упрощенная логика приложения в шаблоне для неособо умного дизайнера засчитывается?
1. а какие именно?
2. это что такое? типа xsl:apply-templates?

4. не, что тут такого? %-)
5. логики там вообще не должно быть
но, блин, гибкий, сцуко… за то и любим… :(
Хабрахабр — Голосования
Some error… We know…


предыдущее сообщение прошу считать недействительным. смарти дважды гибкий, но не дважды любимый!
UFO landed and left these words here
теоретически, вероятный вариант
а) nagios (или иная система) сидит внутрисети, а упали внешние каналы
б) nagios (или иная система) долбит мало-зависящий от внешних факторов скрипт в качестве проверки живучести сайта
в) nagios (или иная система) проверяет живучесть с интервалом в каждые 3-5 минут. у нас иногда Call Centre или Customer Support звонит на минуту-две раньше, чем приходит СМС с проблемой…
Ничего не написано про сам проект, непонятно какой он был. Иногда на сайте много картинок, тогда нужно оптимизировать одно, иногда много запросов к базе, тогда другое. Просто миллион посетителей в месяц — это примерно 30 тысяч в день, что на самом деле не так много для рядового сайта, поэтому очень не хватает описания специфики работы.
Я один такой, скажите в чем профит от варниша(ваниша)??? Чем им кеш в nginx неугодил? там если юзать +perl+memcache можно вообще оч крутую систему кеширования организовать
А причем тут, собственно, Perl?

Про Варниш — строгий 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.
апач может и больше обслуживать в секунду.

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 тыс. посетителей в день… на среднем по мощности сервере» — это весьма спорное утверждение.
Я бы ещё добавил замечание о файловом кэше. Если у вас был один сервер, а потом вдруг их стало два, то у каждого из них будет свой файловый кэш. Код может на это быть не рассчитан, причём сразу такие вещи имеют свойство быть не замеченными.
Мы установили, что узким местом является MySQL и опять позвонили хостеру. Они посоветовали master-slave репликацию MySQL со slave на каждом веб-сервере.

Я не понял. У них стало три mysql сервера? Один заявленный в начале мастер и по одному слейву на каждом веб сервере?
Да типа того… Селекты можно вгребать из локальных слейвов очень быстро
Что бы Вы ни делали, Ваш сайт все-равно рано или поздно упадет. Закон Мерфи.
Как это замечательно, не только у нас все делают через жёпу, а потом разгребают :)
Пустите программиста заниматься инфраструктурой сервиса и ресурсами сервера, и он точно упадет :)

Товарищам просто нужен был сисадмин: все кочки в статье уровня novice :)
Пустите сисадмина строить архитуктуру — и все разом упадет.

Сисадмин нужен для быстрой и точной настройки всего и вся. Продумать же стратегию развертывания для конкретного решения должен архитектор.
архитектор это главный строитель домов :)
А не из сисадминов ли и программистов вырастают архитекторы?
статья хорошая, написана с юмором
все грабли известные… Ну сколько можно на них наступать по 10 раз.
я долго смеялся.
надо изначально разрабатывать архитектуру нормально.
Понятно, что кто ни чеге не делает, тот не ошибается, но и учиться можно на чужих ошибках, а не на своих.

Ну и в заключение nginx+php-fpm надежней чем lighttpd + spawn-php
(спавнер имеет утечки)
Анти-паттерны хороши! Ёжики кололись и плакали :) Когда уже прекратят тестировать на юзерах? Тогда, когда юзеры перестанут им это позволять. В корпоративном сегменте это лечится финансовыми исками, после чего вся миграция проходит только через тестовые стенды и несколько видов нагрузочного тестирования. И, да, мы тестируем.
Only those users with full accounts are able to leave comments. Log in, please.