любой хайлоад это прежде всего архитектура + расширяемость. выжимать соки из железок дело хорошее, но тупиковое. я делал 2 хайлоада. сейчас делаю третий. во втором расчетная нагрузка 10 лямов хитов в день. все построено на кластерном решении. не хватает мощи. втыкается нода (обычный сервак, не крутой). синкается с мастером и все. прирост мощи обеспечен.
это примерно на сколько уникальных посетителей?сколько по трафику выходит, какую бд использовали? DBM файлы приходилось применять для кеширования?
там немного не то. там система продажи трафика, т.е. на систему сливают траффик, а она его перераспределяет. когда я оттуда ушел, там было 4 сервера. 1. фронт. балансер. админка. mysql управлялка кластера. 2.3 MySQLCluster на 2-х нодах + ноды на обработку запросов. 4. сервер статистки. работает все так. фронт принимает запрос. сбрасывает на ноды. нода пишет в кластер в табличку. на нодах висят скрипты, которые вытаскивают хиты, обрабатывают и записывают в статистику. далее сервер статистики вытаскивает данные из промежуточной статистики и уже строит нормальную статистку и пихает ее обратно в кластер. там статистика самое тяжелое место. принять хиты ваще не попрос.
а они сразу такую систему захотели или была какая то попроще и перестала справляться?были оставлены места для "наворотов" имею ввиду с нуля пришлось писать?
там история немного прикольней. до меня так кто-то начинал. хотели поднять все на 1 сервере. когда я пришел я сказал. пишу с нуля как положено или нафиг. они выбрали с нуля. так все и завертелось. http://www.trafficshop.com/ пысы. это траффик с CJ (порнуха). Было очень позновательно посмотреть на это дело изнутри.
часто в проектах куски php кода приходится переписывать на C?Вот сейчас читаю литературу как правильно все организовывать, анализ\построение диаграмм, вам приходится этим заниматься в больших проектах? на этом зарабатывать, по моему, можно только за бугром
а в чем преимущество использования демона перед обычным скриптом? т.е. я просто не понимаю куда его засунуть
в моем понимании, демон это служба/сервис который постоянно доступен. как он запускается и на чем написан дело десятое. раньше я просто пуксал скрипт с while(true). теперь форкаюсь и сижу на событиях. зависит от задач и их реализации. если надо по крону выполнять то и не надо демонов мутить. просто как уже сказали выше. демон/служба уже запущена и всегда доступна как сервис.
демонов? ну сейчас в проекте (ММОРПГ) у нас висят демоны юзеров, локаций, боев и чата. это как бы промежуточная прослойка между фронтом и БД, которая (демоны) оперирует высокой абстракцией и сбрасывает ее в БД уже на низком уровне.
на низком уровне, это т.е. объект юзера обходится итератором и рассовывается по БД к примеру? а почему не хранить объекты в базе? или я не правильно понял?
при хайлоаде нужен быстрый доступ к данным. БД такого не обеспечивает. Так же нужно быстро уметь ее менять. В демоне все данные подготовлены и находятся в памяти. Отсюда и скорость. А из демона по таймеру в БД отдельным потоком сбрасываются данные в БД. Т.е. в этом случае мы имеем мгновенный доступ к данным + синхронизация с хранилищем. Как пример. У юзера около 160 различны параметров. в БД лежит сериализованный массив. Что бы изменить какой-то параметр (к примеру восстанавливается здоровье) классическим подходом надо: 1. выбрать юзера из БД. 2. развернуть. 3. поменять. 4. сохранить. с демонами я просто делаю $oUser->health += 10, к примеру, и не думаю что там куда. БД дергается не на каждый чих, а когда производиться сброс данных в БД.
ничего не зафлудили. очень познавательная инфа относительно чрезмерно высоконагруженных проектов. упс! промахнулся чтоли? вот блин, здесь еще две страницы было оказывается )))