Система сбора статистики

AnToXa

prodigy-одаренный ребенок
Я бы все-таки оценил нормальный 2-хпроцессорный сервак где-нибудь в 2-3 мульта хитов картинок...
ну ты хотя бы сказал для какой задачи оцениваешь, а вот выше эта цифра давалась вообще без указания задачи.

<пафос>
кстати картинок, если статических, можно отдать с такого сервера(это я про dual Xeon 2.8 / 4GB) наверное миллионов 100 в сутки, просто надо уметь их готовить :)
</пафос>

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

MadMike

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

-~{}~ 15.05.06 19:08:

Сергей Тарасов
В общем, я тебе точно говорю, никто здесь ничего толкового по теме не скажет.
 

slach

Новичок
2MadMike ;) чешется язык ответить грамотно и развернуто =))

Автору вопроса

СБОР статиститки, вообще нада отдавать отдельному демону на Си, в котором примитивный веб-сервер и парсинг параметров полученных из QUERY_STRING

хранить вообще не в MySQL (конечно MyISAM + INSERT DELAYED может и делает довольно шустро, но по моему на серьезной нагрузке все равно сдохнет), а где нибудь в shared memory или memcached
который ставить на отдельной машине =)

второй демон уже делает
"первичную агрегацию"
а именно разбивает поток ХИТОВ на Сессии и складывает в базу

а вообще надо ОТКАЗЫВАТЬСЯ от концепции ХОСТЫ\ХИты уже давно ;) позавчерашний день

надо переходить к концепции - ПРОФАЙЛ ЮЗЕРА + ЗОНА САЙТА+ ДЕЙСТВИЕ + ПАРАМЕТРЫ ДЕЙСТВИЯ
тогда и данных будет СУЩЕСТВЕННО меньше
правда и вычислений БОЛЬШЕ =)
 

AnToXa

prodigy-одаренный ребенок
2MadMike чешется язык ответить грамотно и развернуто =))
это пройдет :eek:)))

СБОР статиститки, вообще нада отдавать отдельному демону на Си, в котором примитивный веб-сервер и парсинг параметров полученных из QUERY_STRING
веб сервер там не нужен, если честно, лучше реюзать тот же nginx, написать в него маленький модулик. в общем-то можно поставить туда даже пхп с акселератором.

хранить вообще не в MySQL, а где нибудь в shared memory или memcached
да, собсна мемкеш и есть тот самый "отдельный демон на C",если последовать моегому совету и не городить своих веб серверов, то nginx+php fcgi+ZPS+memcached и вся любовь.

правда с другой стороны имхо все же удобнее буддет mysql, потому что возможностей для анализа данных сильно больше, а с мемкешем - только вытягивать из него все записи, что не очень тривиально :)
 

slach

Новичок
ну если тебе так хочется, пусть будет модуль к nginx ;)
php с акселератором IMHO все таки не стоит ставить на СБОР

слишком много оверхедов, это СКРИПТОВЫЙ язык, тут даже native кодом не пахнет

в общем размышлять над архитектурой можно долго
надо не языки чесать, а делать =)
 

AnToXa

prodigy-одаренный ребенок
slach
php с акселератором IMHO все таки не стоит ставить на СБОР
зависит, конечно, от нагрузки, но такая схема, если пхп будет только ходить к демону в гости, даже по tcp внутри одной машины - я думаю ты зае...шся ее убивать :)

Сергей Тарасов
делаем.
 

MadMike

Новичок
Я, собссно, потому про нестатические картинки и говорил - nginx+fastcgi :)
Нужно "оперативные данные" хранить в мемкеше, а статы для интерфейса - в мускуле. Дальше, строим немеряное кол-во агрегированных статов etc.
Естественно, load balancing - как угодно, по слоям юзеров, dns, round-robin etc.
Главное, чего нужно добиться - отсутствие "главного" сервера, который масштабируется только покупкой более мощного.
 

Сергей Тарасов

Профессор
Спасибо за дельные советы... Придется покупать еще парочку машин в Peterstar'е... :)))

-~{}~ 15.05.06 20:19:

Кстати, пока таких огромных нагрузок не предполагается. Главное, чтобы систему можно было потом расширять.
 

AnToXa

prodigy-одаренный ребенок
Главное, чего нужно добиться - отсутствие "главного" сервера, который масштабируется только покупкой более мощного.
тебе подарить губозакаточную машинку? :)
почти всегда это есть overkill, для данного случая - 100% на данный момент, а то потом начнется, Load balancer резервируем, диски, машины, базы, мемкеши и это уже никогда не взлетит просто :)
 

MadMike

Новичок
Стопудов можно добиться. Это же очевидно, не мне тебе объяснять :)
Можем поговорить об этом на phpconf + php-party :)
 

AnToXa

prodigy-одаренный ребенок
MadMike
добиться-то можно, но я к тому, что на это нужно потратить столько времени, думания и денег, что оно влзетит очень не сразу, если деньги раньше не кончатся раньше :)
 

MadMike

Новичок
Конечно. Бабла уйдет немеряно на сервера и достаточно долгий процесс разработки. Зато если взлетит! :)
 

Сергей Тарасов

Профессор
Я понимаю, что использовать самописный сервер, наверное, намного эффективнее в данном случае, сем тяжелый Apache. Но вот насколько?
И что использовать в этом случае GD? или опять-таки самописную систему?
 

MadMike

Новичок
Тебе ведь уже сказали - nginx+(fastcgi|свой модуль).
fastcgi - проще и гораздо быстрее в плане разработки :)
Никаких самописных серверов не надо точно.
 

Alexandre

PHPПенсионер
ну, меня тут по стенке размазали ( за мои до 25 -30 тыс уникув в день). Мой сервак -где-то так и выдерживает, больше - глохнет. Хотя по железу - он уже немного староват и там 2Gb) На нем еще и БД крутится, которая съедает большую часть памяти. Не буду утверждать, что все идеально там спроектированно...а лучше промолчу. Но общаясь с коллегами, я сделал вывод, что это средняя нагрузка на пхп портал.

Но не стоит забывать, что проектируемая система - это сервер статистики, а не контентный портал, и здесь кеширование мало подойдет)

Архитектура должна быть масштабируемой и распределенной.
Конечно - на стартапе все можно иметь все на одной машине... Но - если система должна быть "национального" масштаба, то:
мое предложение - БД выносим на отдельный сервак, этим мы разгружаем память.
Эпять же - был предложен мемкеш - а сколько он жрет памяти? каков хеш памяти предполагается для него зарезервировать?

а сколько жрет памяти процессы мускуля или постгреса?

Вообще-то лучше раскошелиться на промышленную БД, она оптимизирована под большие нагрузки.

Сервер сбора запросов - не имелось ввиду - что это будет отдельный WEB сервер. Сервер - это программа, которая сидит в памяти и ждет обращения от программы клиента. В частности, как одно из решений было предложено (ngnix + модуль ) Можно демона на С, но это чуточку сложнее. Я имел ввиду первое, хотя это не обязательно должен быть ngnix. Главное, чтоб в последствии - можно это решение можно вынести на отдельную машину. Опять же - решение мемкеш - оно использует доступ по сокетам, и его вполне можно использовать в случае разнесения.

И последняя часть - отображение статистики WEB сервер+ php. Ну как хит сезона - предлагался (ngnix + FastCGI php5 ), значительнее быстрее чем на апаче.

Можем поговорить об этом на phpconf + php-party
+1 встретимся и обсудим, не против.

-~{}~ 16.05.06 13:07:

Я понимаю, что использовать самописный сервер, наверное, намного эффективнее в данном случае, сем тяжелый Apache. Но вот насколько?
раза в два, примерно
 

MadMike

Новичок
раза в два, примерно
lol.
сколько жрет памяти
ровно столько, сколько ты скажешь, и ни метром больше.
Но не стоит забывать, что проектируемая система - это сервер статистики, а не контентный портал, и здесь кеширование мало подойдет
Мы говорим не про кеширование, а про хранение hot data в памяти.
И последняя часть - отображение статистики WEB сервер+ php. Ну как хит сезона - предлагался (ngnix + FastCGI php5 ), значительнее быстрее чем на апаче.
В выдаче статистики СОВЕРШЕННО не важен веб-сервер. Главное здесь - правильная архитектура базы и собссно быстрый сервер базы.
 

Alexandre

PHPПенсионер
ровно столько, сколько ты скажешь, и ни метром больше.
это ежу понятно, имелось ввиду количество,
мало дашь памяти - тормозить будет,
много - тормозить будут остальные процессы. По этому, как я говорил - просчитывать надо, хватит ли нагрузки на сервак.
В выдаче статистики СОВЕРШЕННО не важен веб-сервер
важен, чем быстрее отдается контент, тем меньше висит процесс, тем больше можем обслуживать поток процессов.
Главное здесь - правильная архитектура базы и собссно быстрый сервер базы.
Полностью согласен.

MadMike, смотрю, у тебя есть опыт в проектировании подобных архитектур.
 

Фанат

oncle terrible
Команда форума
MadMike
ты ещё не понял, с кем ты разговариваешь, а, главное - сколько это может продолжаться? =)
 
Сверху