А какой фреймворк вы использовали, если не секрет?
Просто странно — я удивляюсь, как сайт может работать быстро с такими бешеными нагрузками. У вас первоначально пользователи по ajax обращались к таблице в 72 миллиона записей каждые 10 секунд?
Без фреймворков и библиотек (кроме php-memcached) — чистый php, даже без абстракции базы данных — только mysql_query/mysql_real_escape_string.
Нет, к 72 миллионой обращение идет только раз — при первоначальной загрузке страницы и потом еще 400 обращений к 17 миллионной базе отдельных слов (хотя фактически эти все обращения сейчас идут к memcached).
Было бы быстрее, если бы боты не обращались 100-200 тысяч раз в день.
А хотя бы сейчас — можно поинтересоваться кол-вом генерируемых страниц или даже скорее — обработываемых запросов в сутки — при пиковых нагрузках и среднестатистических )))
в сторону RarestNews :) это другой проект, он мне куда более интересен сейчас, но с ним я в тупике. а этот просто висит, народ развлекает. а про этот еще дорасскажу, наверное, если интерес будет — это далекоооо не все, что там надо было оптимизировать.
В категоризации новостей.
«Turkey» — это страна или индейка? Python — язык программирования или monty python? Полисемия меня уже бесит, я уже даже выучил как это называется.
Как вычислить автоматически вычислять семантическое ядро для категорий типа «Atlanta Falcons», если во всех страницах про них, в основном пишется про них и какую-нибудь еще команду, например «Denver Broncos»?
Как автоматически сделать иерархичность, что Denver Broncos — это NFL?
И т.п. т.п. т.п. короче, автоматизированная лингвистика загнала меня уже. Получается процентах в 50 случаев процентов на 90 угадать тематику, в 10 процентах случаев угадываемость около 30-40 процентов, но если считать, что тема обобщена, то есть по запросу «спартак» — мы просто интересуемся «футболом». В остальных 40% категоризации вообще нет или неправильна )
просмотрел в общих чертах — тестировал я что-то подобное и даже сейчас что-то подобное работает — вот эти ВЕРОЯТНОСТИ выше и получаются ) не знаю правда что будет при тех моделях — я свои придумывал.
я думаю вы меня не так поняли. когда такие нагрузки — нужно стремиться к двум вещам:
1) выборки только по primary key
2) как можно меньше join, order, group
именно к этому сейчас фактически проект и пришел, к сожалению, экспериментальным путем поломок и убитых винчестеров.
unbuffered дал бы выигрыш, если бы я все 72 млн записей выбирал ) в моем случае из этой базы выбирается только 1 (денормализованная) строка по праймари ключу — я писал об этом подробно в первой части.
я с вами не согласен…
нельзя подходить к проекту — работает и хорошо…
работать должно так, что если к вам придут 2 миллиона юзеров, то вы им скажите — а у меня все работает :) а не будете 18 часов кодить :)
1) я не уверен, что это достижимо без шардинга
2) если шардинг (кластеризация) — это нужны процессы следящие за состоянием серверов и т.п. и т.п. и т.п.
3) платить за несколько серверов сразу
так вот — это долгая и очень серьезная работа (недели, а может и месяцы), а теперь ответьте на вопрос: «а если НЕ придут 2 миллиона?» )) и в принципе я более чем уверен, что на этот проект — не придут. это игрушечный проект, там им делать нечего — миллионам.
Так исторически сложилось — просто у меня есть библиотека функций, которыми много лет пользуюсь и она uptime назвалась по названию команды, так и осталось, хотя и Вы правы — меряет она loadavg :)
кстати, запуск процесса uptime, а также preg_match — сами по себе достаточно тяжелые функции.
лучше юзайте
$a=split(" ",readfile("/proc/loadavg"),2);
return $a[0];
Какая боль! Толпы против Веб — 2:0. Эпизод два — клоны заходят в полдень