Комментарии 43
А какой фреймворк вы использовали, если не секрет?
Просто странно — я удивляюсь, как сайт может работать быстро с такими бешеными нагрузками. У вас первоначально пользователи по ajax обращались к таблице в 72 миллиона записей каждые 10 секунд?
Просто странно — я удивляюсь, как сайт может работать быстро с такими бешеными нагрузками. У вас первоначально пользователи по ajax обращались к таблице в 72 миллиона записей каждые 10 секунд?
+1
Без фреймворков и библиотек (кроме php-memcached) — чистый php, даже без абстракции базы данных — только mysql_query/mysql_real_escape_string.
Нет, к 72 миллионой обращение идет только раз — при первоначальной загрузке страницы и потом еще 400 обращений к 17 миллионной базе отдельных слов (хотя фактически эти все обращения сейчас идут к memcached).
Было бы быстрее, если бы боты не обращались 100-200 тысяч раз в день.
Нет, к 72 миллионой обращение идет только раз — при первоначальной загрузке страницы и потом еще 400 обращений к 17 миллионной базе отдельных слов (хотя фактически эти все обращения сейчас идут к memcached).
Было бы быстрее, если бы боты не обращались 100-200 тысяч раз в день.
+4
Я в третьей части подробнее расскажу об этом всем (если доберусь до нее когда-нибудь :) )
+2
А хотя бы сейчас — можно поинтересоваться кол-вом генерируемых страниц или даже скорее — обработываемых запросов в сутки — при пиковых нагрузках и среднестатистических )))
циферки — оченя люблю, соревновательный дух поддерживает — люблю посоревноваться )))
зы. гугл — к соревнованию не предлагать, я до него попозжя дойду, пока времени на него нет ))
циферки — оченя люблю, соревновательный дух поддерживает — люблю посоревноваться )))
зы. гугл — к соревнованию не предлагать, я до него попозжя дойду, пока времени на него нет ))
+1
Ну так я ж говорю 100-200к в сутки, из них около 4000 от реальных людей.
+1
Как планируете развитие? в какую сторону?
0
в сторону RarestNews :) это другой проект, он мне куда более интересен сейчас, но с ним я в тупике. а этот просто висит, народ развлекает. а про этот еще дорасскажу, наверное, если интерес будет — это далекоооо не все, что там надо было оптимизировать.
+1
в чем тупик заключается?
0
В категоризации новостей.
«Turkey» — это страна или индейка? Python — язык программирования или monty python? Полисемия меня уже бесит, я уже даже выучил как это называется.
Как вычислить автоматически вычислять семантическое ядро для категорий типа «Atlanta Falcons», если во всех страницах про них, в основном пишется про них и какую-нибудь еще команду, например «Denver Broncos»?
Как автоматически сделать иерархичность, что Denver Broncos — это NFL?
И т.п. т.п. т.п. короче, автоматизированная лингвистика загнала меня уже. Получается процентах в 50 случаев процентов на 90 угадать тематику, в 10 процентах случаев угадываемость около 30-40 процентов, но если считать, что тема обобщена, то есть по запросу «спартак» — мы просто интересуемся «футболом». В остальных 40% категоризации вообще нет или неправильна )
«Turkey» — это страна или индейка? Python — язык программирования или monty python? Полисемия меня уже бесит, я уже даже выучил как это называется.
Как вычислить автоматически вычислять семантическое ядро для категорий типа «Atlanta Falcons», если во всех страницах про них, в основном пишется про них и какую-нибудь еще команду, например «Denver Broncos»?
Как автоматически сделать иерархичность, что Denver Broncos — это NFL?
И т.п. т.п. т.п. короче, автоматизированная лингвистика загнала меня уже. Получается процентах в 50 случаев процентов на 90 угадать тематику, в 10 процентах случаев угадываемость около 30-40 процентов, но если считать, что тема обобщена, то есть по запросу «спартак» — мы просто интересуемся «футболом». В остальных 40% категоризации вообще нет или неправильна )
+2
я извиняюсь, а ссылочку на проект не подбросите?
0
А вы не пробывали использовать
ru.php.net/manual/ru/function.mysql-unbuffered-query.php
— в вашем случае должно немного увеличить производительность.
ru.php.net/manual/ru/function.mysql-unbuffered-query.php
— в вашем случае должно немного увеличить производительность.
+1
я думаю вы меня не так поняли. когда такие нагрузки — нужно стремиться к двум вещам:
1) выборки только по primary key
2) как можно меньше join, order, group
именно к этому сейчас фактически проект и пришел, к сожалению, экспериментальным путем поломок и убитых винчестеров.
unbuffered дал бы выигрыш, если бы я все 72 млн записей выбирал ) в моем случае из этой базы выбирается только 1 (денормализованная) строка по праймари ключу — я писал об этом подробно в первой части.
1) выборки только по primary key
2) как можно меньше join, order, group
именно к этому сейчас фактически проект и пришел, к сожалению, экспериментальным путем поломок и убитых винчестеров.
unbuffered дал бы выигрыш, если бы я все 72 млн записей выбирал ) в моем случае из этой базы выбирается только 1 (денормализованная) строка по праймари ключу — я писал об этом подробно в первой части.
+1
прекрасно. молодец. респект.
+4
Хроника боевых действий прямо.
+3
НЛО прилетело и опубликовало эту надпись здесь
еще бы я посоветовал использовать mysqli — оно быстрее — либо если получится модуль от самого мускла — он еще быстрее
еще можно использовать mysqli_pconnect
+ заменить апачи на nginx — он быстрее
поставить fast-cgi — тоже + к производительности
еще можно использовать mysqli_pconnect
+ заменить апачи на nginx — он быстрее
поставить fast-cgi — тоже + к производительности
+3
да он уже терпимо вполне работает и врядли это 200к запросов превысит скоро, не летает, конечно, но дождаться загрузки можно )
+1
я с вами не согласен…
нельзя подходить к проекту — работает и хорошо…
работать должно так, что если к вам придут 2 миллиона юзеров, то вы им скажите — а у меня все работает :) а не будете 18 часов кодить :)
нельзя подходить к проекту — работает и хорошо…
работать должно так, что если к вам придут 2 миллиона юзеров, то вы им скажите — а у меня все работает :) а не будете 18 часов кодить :)
+1
«Преждевременная оптимизация — корень всех зол»
+1
1) я не уверен, что это достижимо без шардинга
2) если шардинг (кластеризация) — это нужны процессы следящие за состоянием серверов и т.п. и т.п. и т.п.
3) платить за несколько серверов сразу
так вот — это долгая и очень серьезная работа (недели, а может и месяцы), а теперь ответьте на вопрос: «а если НЕ придут 2 миллиона?» )) и в принципе я более чем уверен, что на этот проект — не придут. это игрушечный проект, там им делать нечего — миллионам.
2) если шардинг (кластеризация) — это нужны процессы следящие за состоянием серверов и т.п. и т.п. и т.п.
3) платить за несколько серверов сразу
так вот — это долгая и очень серьезная работа (недели, а может и месяцы), а теперь ответьте на вопрос: «а если НЕ придут 2 миллиона?» )) и в принципе я более чем уверен, что на этот проект — не придут. это игрушечный проект, там им делать нечего — миллионам.
+1
да и конечно же прогнать скрипты под xdebug или аналогичной тулзой на предмет профайлинга…
посмотреть что занимает основное время выполнения
посмотреть что занимает основное время выполнения
+2
Подскажите адресок сервиса? Можно быть плохо искал, но ссылку не нашел.
+1
ради бога, переименуйте функцию uptime() в loadavg()
+4
bolknote.ru/2008/09/18/~1863/
+2
прямо как в хитчхайкере Дугласа Адамса
с ответом — сорок два
Главный Вопрос Жизни, Вселенной,
с ответом — сорок два
Главный Вопрос Жизни, Вселенной,
0
Вопрос. Почему memcache, а не shared memory cache (тот же eaccelerator)?
0
Даааа! Интересно!!! ОЧЕНЬ даже! Спасибо, за серию статей!
p.s.: хотел, спросить, а что кроме интереса вы преследуете? (можно в приват)
p.s.: хотел, спросить, а что кроме интереса вы преследуете? (можно в приват)
0
кстати, запуск процесса uptime, а также preg_match — сами по себе достаточно тяжелые функции.
лучше юзайте
лучше юзайте
$a=split(" ",readfile("/proc/loadavg"),2);
return $a[0];
+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какая боль! Толпы против Веб — 2:0. Эпизод два — клоны заходят в полдень