А кто решает, где "норма", а где "не норма"? Если в нормальном режиме нагрузка на сайт не превышает 50 запросов в секунду, а он держит 100 - то это отличный показатель.
Вообще, более чем двукратный запас производительности - это пустая трата денег. Двукратный запас позволяет комфортно себя чувствовать при любых темпах роста посещаемости, хотя по экономическим соображениям обычно эффективнее иметь где-то 1.5 кратный запас.
Они бы хоть базу пользователей перевели на новый сайт, что ли! У меня на счету в allofmp3 баксов 5-10 лежало - не принципиально, конечно, но было бы приятно их сохранить :)
Лучше обратиться с таким вопросом к Александру Шуркаеву - он куда профессиональнее меня в области javascript (и в проектах, о которых я упоминал, боролся с утечками именно он).
Про сессии я это к тому, что механизм идентификации сессии все тот же - куки. Т.е. пункты 3 и 4 рядом смотрятся некорректно - с точки зрения клиента это одно и то же.
Подозрительность пользователей - по все тем же признакам: количество регистраций с одного IP (в течение периода времени), с одним email, с одного браузера (индентифицируемого все тем же cookie - uid и т.п.) и т.п.
Не, не все так просто :) Если считать просто количество топиков/комментов - то пользователи будут флудить ради силы. Надо считать количество топиков/комментов, заплюсованных другими пользователями (и вычитать - количество минусованных). Тогда общество будет саморегулируемым - главное, подобрать коэффициенты ;)
Так Вы потеряете то, что уже было в этом прототипе. Т.е. исключаете возможность "наследования" (да простят мне это слово, не знаю как правильно сказать :)
Вы знаете, когда отлаживаешь проект с большим количеством javascript под популярными браузерами, складывается ощущение, что "разработчики js-движков" не только ламеры, но и вообще безответственные лентяи. В примитивных случаях все ок, но как только кода становится много - память начинает течь, причем под разными браузерами в разных местах. И для борьбы с этим приходится выдумывать разные идиотские хаки. Так что не стоит рассчитывать на всякую "оптимизацию" - ее там почти что нет.
Спасибо за статью! Пусть она местами и спорная, но такие статьи нужны, поскольку разработчиков становится все больше, а суммарный уровень знаний растет медленно ;) Плюс в карму.
А замечания не буду писать - тут и так много написали.
Хабрахабр как раз и пытается решить эту проблему "современными" методами. Основная идея - отсрочить способность юзера совершать активные действия. Все перечисленные Вами способы имеют смысл, хотя и немного старомодны. Современная тенденция - комбинирование этих способов, причем не в "жесткой" манере (может - не может), а в "мягкой": показался пользователь подозрительным - увеличили ему срок пребывания в "песочнице".
Ваша идея с email вовсе не бессмысленна - во первых, практика показывает, что многим лень регистрировать кучу ящиков (это же усложняет процесс создания виртуалов), а во-вторых - можно отсылать письмо-подтверждение с задержкой (5-10 минут и больше, если пользователь показался "подозрительным"). Разумеется, пользователь без подтвержденного email при этом не может писать, голосовать и т.п.
Кстати, поясните Ваш пункт 4 - что значит "пользовательские сессии" и чем это отличается от п.3?
Я, как житель России, особого кайфа от прокладывания маршрута не испытываю (у Гугла знания о наших дорогах весьма поверхностные), зато пользуюсь возможностью рисовать свои маршруты. При этом возможность перетаскивать точки тоже очень помогает :) Правда это не новость - при рисовании своих точки уже давно можно перетаскивать.
Спасибо за статью - я рад, что тема высоких нагрузок и оптимизации все чаще всплывает в рунете. По самой статье пара замечаний:
1. При работе с FastCGI речь идет о процессах, а не о потоках. Каждый процесс занимает довольно много в памяти, поэтому делать их много нежелательно (так же, как нежелательно разрешать слишком много процессов апача). И конечно, сервер надо настраивать так, чтобы при нехватке процессов пользователи просто висели в ожидании, а не получали 500 ошибку.
2. Mysql query cache в большинстве случаев весьма неэффективен. Проблема в том, что у него совершенно тупой механизм инвалидации кэша: при любом изменении в таблице сбрасываются все закэшированные результаты запросов, относящиеся к этой таблице. Если вы пишете cms, то это еще куда ни шло, но в интерактивных веб-приложениях данные меняются часто, поэтому кэш почти не работает. В общем, query cache имеет смысл включать (с помощью хинтов) только для некоторых запросов.
3. Не сказано ни слова про memcached. Для такой актуальной статьи это даже странно ;)
P.S. Если вдруг еще не в курсе - осенью будет HighLoad 2007. Приходите - как участник, а может и как докладчик :)
Вообще, более чем двукратный запас производительности - это пустая трата денег. Двукратный запас позволяет комфортно себя чувствовать при любых темпах роста посещаемости, хотя по экономическим соображениям обычно эффективнее иметь где-то 1.5 кратный запас.
Подозрительность пользователей - по все тем же признакам: количество регистраций с одного IP (в течение периода времени), с одним email, с одного браузера (индентифицируемого все тем же cookie - uid и т.п.) и т.п.
А замечания не буду писать - тут и так много написали.
Ваша идея с email вовсе не бессмысленна - во первых, практика показывает, что многим лень регистрировать кучу ящиков (это же усложняет процесс создания виртуалов), а во-вторых - можно отсылать письмо-подтверждение с задержкой (5-10 минут и больше, если пользователь показался "подозрительным"). Разумеется, пользователь без подтвержденного email при этом не может писать, голосовать и т.п.
Кстати, поясните Ваш пункт 4 - что значит "пользовательские сессии" и чем это отличается от п.3?
1. При работе с FastCGI речь идет о процессах, а не о потоках. Каждый процесс занимает довольно много в памяти, поэтому делать их много нежелательно (так же, как нежелательно разрешать слишком много процессов апача). И конечно, сервер надо настраивать так, чтобы при нехватке процессов пользователи просто висели в ожидании, а не получали 500 ошибку.
2. Mysql query cache в большинстве случаев весьма неэффективен. Проблема в том, что у него совершенно тупой механизм инвалидации кэша: при любом изменении в таблице сбрасываются все закэшированные результаты запросов, относящиеся к этой таблице. Если вы пишете cms, то это еще куда ни шло, но в интерактивных веб-приложениях данные меняются часто, поэтому кэш почти не работает. В общем, query cache имеет смысл включать (с помощью хинтов) только для некоторых запросов.
3. Не сказано ни слова про memcached. Для такой актуальной статьи это даже странно ;)
P.S. Если вдруг еще не в курсе - осенью будет HighLoad 2007. Приходите - как участник, а может и как докладчик :)