ЦМС/фремворк готовая выдержать 1кк/сутки

Статус
В этой теме нельзя размещать новые ответы.
Кластеризацию можно сделать, выделенный сервер, зеркальный RAID-1 тоже для ускорения. И веб сервер ессно лучше свой, чтобы рядом стоял.
 
Еще фреймворки

Знакомый(+20 программеров :) ) работает над проектом с посещаемостью которая в разы больше данной, их выбор Symfony но если пойти таким путем то от твоей джумлы ничего не останется.
А мой выбор Zend Framework
 
Я бы оптимизировал железо )

В аське могу ткунуть пальцем в сайт на Joomla который держит 30к хостов.

Там Athlon 4800+ x2/4 Гб ОЗУ/
ngnix+eАкселератор

Выносишь все картинки и графику на отвельный поддомен назначаешь ему выделеный ip и вешаешь на него ngnix
eАкселератору назнаечаешь кеширование только в ОЗУ (если много, в приведеном примере 2Гб отведено под кеши).
Наслаждаешься.

Правда на 50-70к сдохнет сама жумла ) а кеширование на основе движка не нужно использовать на сайтах с такой посещяемостью, гораздо лучше и быстрей кешировать все на сервере )
 
вобщем,
от остановились на Kohana... :)

CodeIgniter отвалился по одной причине - перенаворочен И изначально разрабатывался под полную совместимость пхп4 и пхп5, а значит - более громоздкий код - нафик не нужно

хотя Kohana и базируется на принципах CodeIgnite, но оттуда было удалено много и оставлена исключительно только совместимость с пхп5 - то что надо...

что касается железа - безусловно...
сейчас работаем с апачем (увы и ах...) для выдачи страниц сайта и lighttpd для имаг с поддомена

сейчас сервак - Core2Quad 2,4, 8Gb, 4*250Gb Raid 1+0
порядка 200к уников держит на старых скриптах как нефик :),
но вот... увеличь мы х10 нагрузку - начинаются траблы уже при 2х кратном увеличении...

а вот теперь шок:
200к это на ООООООООЧЕНЬ "кастрированной" жумле!
НО! это все еще жумла :)))))))))))))
кеширование - жесткое, 50% функционала фронтенда выкинуто, дофига лишних мускуль запросов - отсечено...
генерация главной страницы - от 0 до 4 мускуль реквестов...

ЗЫ. гыг... если сессии хранить в мускуле - табличка с сессиями падает... :D

вобщем...переписываем все эту хню :)

сейчас новое (то что на Kohana) тестим на Core2Quad 2,4, 4Gb, 2*250Gb Raid 0,
стоит: дебиан 4, апач 2.2, пхп5 последний, мускуль 5.1, еАкселератор (с кешем НА ДИСКЕ!)

апачбенчмарк в 20 потоков, с 10 сервов (2 серва из того же датацентра) на 20 разных страниц...
0,001 - 0,1 - среднее время генерации страницы
получается 1кк держит без проблем за 10 интенсивных часов (основное время "напряга сервака")...

вобщем, железка должна справляться :) НО... это БЕЗ подгрузки графики с того же сервака... по сути, кеш еАкелера на диске - жалкое подобие создать дополнительную нагрузку на харды и, к тому же, реид 0

вобщем... если все это перекинуть на новый серв (наверно прийдется брать что-то типа 2*коре2квад, 16Гб, 2*75 SAS 15к + 4*500 реид10) все должно 3кк выдержать... нверно...

Дилема:
либо выепениватсья и ставит ДИН ахеренный сервак или
ставить 2 в стоку... один какосновной, второй для подгрузки графы... или может один как основной, второй для картинок...

интересно, как у яндекса реализовано? :)))))))
 

дайте сцлыко посмотреть хоцца на это чудо которое такую нагрузку держит
 
Реально не в ту сторону копаете.

Парень выше, itex, правильную мысль вам предлагал: поставьте nginx.

Там понятная дока, ставится в принципе без проблем, с конфигом чуть-чуть порасчехляться придется, раз у вас многоуровневая система доступа, но зато потом - потом будет абсолютно ПО ФИГУ, какая у вас джумла, сколько там sql-запросов на страницу и как это все чудо можно переписать. Условно говоря, nginx сокращает обращения к апачу до уровня 1-2 запроса в минуту. Любая, даже жутко тормознутая cms'ка с такой посещаемостью вполне справится.

То есть еще раз повторю: абсолютно все равно, что у этой cms там внутри. Вы перед апачем ставите стену из nginx, через которую только редкие запросы достигают апача и заставляют вертеться всю громоздкую махину php&sql, основная же часть запросов отсекается еще до апача, причем зачастую даже вообще без обращений к диску. Настоятельно рекомендую ознакомиться. Сайт Для просмотра ссылки Войди или Зарегистрируйся
 
ну прям панацею нарисовал.
узким местом при высокой посещаемости, как правило, является SQL-составляющая. И без оптимизации sql-части + кэши (как на диске так и в памяти), никакой nginx не поможет при такой посещаемости.
 
ну прям панацею нарисовал.
узким местом при высокой посещаемости, как правило, является SQL-составляющая. И без оптимизации sql-части + кэши (как на диске так и в памяти), ни какой nginx не поможет при такой посещаемости.

вот!
о том и речь!

кеширование не всегда вообще возможно!

к примеру, в другом нашем проекте -
каждый юзер обращаясь к сайту зачастую получает уникальную информацию!
нгинкс тут никак не поможет... а вот пхп+еАксель с кешем в оперативе - разгрузил сервер ахренеть как...


а кохана, кстати, тоже радует как сделана!
 
nginx + PHP/FastCGI полюбому поможет, так как nginx держит гораздо больше коннектов чем апач.
но одним им сыт не будешь при высокой посещаемости.
 
FastCGI - До сих пор непойму почему ему оды поют, 3-5% разница получается в производительности и приходится менять стиль написания, кое-что работает не так.

А как работает rewrite мне даже с бубном понять неудалось, точне работать то заставил но не понял принципа.

ngnix - согласен полезная штука но там тоже нюансы в настройке.

2 DOLARiON

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