меньше 100.

Я думаю, их где-то около 30-ти.

я не настолько хорошо знаю русский инет.
вот у рамблер почты, как известно, в пике было 4Krps.
а дальше задачка на память -- вспомнить ресурс и сравнить с.

Да я на топ мейлрушный ориентируюсь и на свои знания о том, какой величины разброс по хитам у ресурсов в топе - это ж пик кривой распределения.
Но да, их меньше ста, и еще некоторое время эта тенденция сохранится, так что ты все верно ответил.

все ли ресурсы присутствуют в маэлрушном топе? я не знаю.
считаем ли банерокрутилки?

Нет, я думаю, мейлрушный топ это процентов 15 выборки.
В нем всего 4 ресурса таких.
Да, баннерокрутилки можем считать, кстати, тогда и счетчики надо считать.

Пик вообще - 6k.

4k - средний дневной максимум. Ну, то есть то, что бывает почти ежедневно, и гарантированно - еженедельно. С введением некоторых новых features за следующие 2-3 месяца посещаемость подрастет еще раза в полтора-два минимум.

А что, под такую нагрузку надо уже тюнингом заниматься ? ;-)

Ну а как же.
Приложение ведь уже было написано заранее, его ж не сразу под такие объемы писали.

а это именно тюнинг, а не полная замена под видом покраски?

Тюнинг.
Полную замену нельзя было делать - клиента интересовал алгоритм существующего движка. Понятно, что в случае действия непреодолимых сил клиент согласился бы и на замену алгоритма, но тогда ведь пришлось бы изобрести новый алгоритм, а это время и деньги.

можно и при сохранении алгоритма всё переписать. с перла на C++, например, как некоторые любят ;)

Дадад, заколдованный круг - это уже третья отсылка к Слонику-в-домене за последние сутки. :)

иногда при 5 rps xeon'ы падают на раз
пхп, такой пхп

Угу, мы как раз начинали тюнить с 5 rps.

обоги, а че за зверь такой был?

Это OpenX
Правда, по виртмашиной, но все равно - страницу с phpinfo() эта виртмашина отдавала в 10 раз чаще

Кстати, раз об OpenX зашла речь.
С http://projects.icapsid.net/adjector не доводилось сравнивать? Или может есть что-то иное не на php? У меня в стеке из LAMP только L есть, а рекламу крутить нужно.

в переделах десятка
да

"There are only two hard things in Computer Science: cache invalidation and naming things"
вот про cache invalidation очень было бы интересно.

Ага, я во внутрикорпоративном докладе рассказывал про cache invalidation, кстати. Про это неплохо докладывал один коллега на одной из конференций Олега Бунина года три назад (как там она называется, Highload, вроде).

я подозреваю что ничего кроме названия от этого доклада не осталось.

and off-by-one errors

10-100, скорее ближе к 10, чем к 100.

Ну вообще один хостинговый сервер до 1000 rps.
Хлам всякий Joomla и т.п.
Не одно преложение впрочем и оптимизации со стороны решений не поддается. Но LAMP.

О, это вешалка, я часто читаю стенания Щорса по этому поводу.
Joomla, WP и прочие деяния можно оптимизировать, но не в массовом порядке, так как шаблоны нагрузок у разных проектов разные.

ну всякие жумлы и прочая неплохо прячутся за varnish даже с дефолтными настройками

Это если нет требований, чтобы каждый запрос получал динамически сгенерированный ответ.

ну тогда кеш только для статики оставить
если 100% динамика, то либо железо покупать, либо код переписать
хотя если код гогно, то никакое железо не поможет

Не знаю, но такая нагрузка представляется мне довольно-таки straightforward и хорошо поддающейся оптимизации. Ну там кэш поставить, прелоадить его, сделать push-сервера, заполняющие кэш контентом, а реквесты пусть из кэша всегда читают.

Вот раздавать поток котировок (50 сообщений в секунду в одном потоке) и принимать ордера на исполнение от нескольких тысяч клиентов сразу, где нужно stateful-соединение — вот это весело.

(кроме того, я в недоумении, почему LAMP до сих пор не умер)

Так а довольно дешево выходит - сначала некий программист (допустим, Вася) делает какой-нибудь open source проект на PHP с целью изучения этого замечательного языка. В процессе изучения он понимает, что он не хочет это больше изучать, а проект уже живет отдельной жизнью и по прихоти судьбы обрастает какой-то юзербазой. И вот один из счастливых юзеров находит программиста Петю и просит его посмотреть, а чего это у него все тормозит. Как говорил мой коллега, и тут из кустов появляемся мы.

так незачем ему умирать
кроме трейдерских платформ есть и другие, и под другие задачи

Не знаю, но такая нагрузка представляется мне довольно-таки straightforward и хорошо поддающейся оптимизации. Ну там кэш поставить, прелоадить его, сделать push-сервера, заполняющие кэш контентом, а реквесты пусть из кэша всегда читают.

Ну да, это совсем не rocket science.
Но общественность многие вещи воспринимает как проявления магии, какой только фигни я не слышал от младших коллег по вопросам оптимизации производительности.

Вот раздавать поток котировок (50 сообщений в секунду в одном потоке) и принимать ордера на исполнение от нескольких тысяч клиентов сразу, где нужно stateful-соединение — вот это весело.

Когда я первый раз услышал порядок нагрузки в трейдерских системах, я протер уши и попросил еще раз повторить. Да, там другие порядки совсем.

какие там алгоритмы и на чем народ пишет, не секрет?

Некоторые на окамле пишут.

http://www.janestcapital.com/technology/ocaml.php

ну там наверняка не только в ЯП дело, архитектура тоже должна специфичной быть

Я не вижу проблем в 50rps и тысячах клиентов, хоть убей. У меня RabbitMQ делает без тюнинга 20k и несколько сотен клиентов, а это Эрланг (примерно python по перформансу).

50rps - это копейки.надо  в третью степень возводить хотя бы, чтоб были нагрузки

Я думаю, там опечатка - видимо, 50 тыс. реквестов в секунду.

я одну такую систему на 150к _проектной_ нагрузки знаю. там правда экзадата)

А вот кстати, где они такой поток событий берут? Датчики с большого адронного коллайдера?

трейдинг) там ваще диковиного много

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

а вот об очередях. а что там такого сложного?
я вот сейчас качаю apache-activemq-5.4.2-bin.tar.43gz. 43 MB.

сорок три мегабайта.
чего я не понимаю?

а на жабе бывают маленькие приложения? :)

но 43 мегабайта!
не 4.3, а 43!
что там даже на жабе такого можно наворотить?!

Ну "всё своё ношу с собой", а про своё вот тут можно глянуть - http://repo2.maven.org/maven2/org/apache/activemq/activemq-core/5.5.0/activemq-core-5.5.0.pom
каждая зависимость вполне может в несколько метров выйти и больше

и зачем это все?
какой в этом смысл?
чего я не понимаю?

Ну ты ведь не удивляешься, что приложению на Ruby/Python/Perl/C++/Whateva могут требоваться библиотеки?
Про конкретный набор и величину библиотек - к авторам, я тут аргументированного ответа дать не смогу.

зависит от приложения.
если приложению "хелло мир!" требуется два десятка библиотек -- меня это несомненно удивляет.

что такого в очередях, что там требуется столько странных библиотек?

Вы спрашиваете будто я эти ActiveMQ трогал...

ну что-то же общее во всех очередях есть?

Ну, про LAMP как таковой - не слишком интересно.
А вот про грабли и тот же cache-invalidating или обеспечение нормального HA силами LAMP - было бы интересно.

Граблям посвящено примерно две трети доклада, а вот про cache invalidating я не упоминаю, не успеваю просто, к тому же, я про это в Датаарте уже читал. Возможно, включу в доклад краткое упоминание, но в моем случае инвалидейшн скорее тривиален.
С нормальным HA есть одна проблема - у нас все highly available, кроме баз, так как на M-M replication уже просто не было ни сил, ни времени, но я про это упоминаю. Опять же, HA HA рознь, если речь о том, чтобы система просто оставалась на плаву - это легче, чем когда речь о том, чтобы на любой запрос гарантированно был ответ.

Да и про ламп как таковой интересно - много кому очень полезно. Я вообще последнее время очень проникся пхп - особенно когда сомому писать на нем не надо) Все просто как валенок и вполне контрлируемо - не говоря уже о том что найти вменяемого еловека (и показать ему как надо) сильно проще чем с перлом/с и прочими жабопитоноотрубями)

главная проблема найти вменяемого человека. научить его нужному языку гораздо проще.

- а хз, порядка 20-30
- да, может узнаю что-то новое

а кстати, 300-500rps -- это на систему или на ноду?
а то я лицемера вспоминаю, так там 200rps на ноду выходило. и нод 10.
ну не LAMP. собствнно по всем буквам мимо. FNPR.

и что, таких всего 30?

На систему.
Лицемер - это серьезная штука, да, их таких мало.
Вот сейчас приложений для вконтакта больше становится, но все равно, даже для браузерки типа той же мейлрушной Легенды 500 rps это выше крыши.

вообще-то самая большая проблема с лицемеровским трафиком -- это его собственно получить. ну в смысле популярности добиться.

с технической кочки там при оптимизации были интересные моменты, но это ж насколько кривые руки надо иметь, что бы такой производительности не достичь? или это у нас черезвычайно прямые были?

но это ж насколько кривые руки надо иметь, что бы такой производительности не достичь?

Я, за неистечением срока давности, пока не могу рассказывать, а как оно бывает, но записки веду - через годик сроки начнут истекать, и я выложу в открытый доступ. Пока я могу только про OpenX рассказывать, у создателей OpenX были не самые кривые руки, а вот ведь - пришлось 12 нод ставить, чтобы выйти на расчетные мощности.

или это у нас черезвычайно прямые были?

Да, безусловно.
Обычные люди имеют тенденцию обсираться буквально на каждом шагу.

Я, за неистечением срока давности, пока не могу рассказывать, а как оно бывает, но записки веду - через годик сроки начнут истекать, и я выложу в открытый доступ. Пока я могу только про OpenX рассказывать, у создателей OpenX были не самые кривые руки, а вот ведь - пришлось 12 нод ставить, чтобы выйти на расчетные мощности.
ну так иногда это правильней.
тот же лицемер можно было наверное не на 10 нодах запустить, а на двух-трех.
но оплата двух девелоперов на поднимание нужного бутерброда и его отладки, я думаю были бы гораздо выше стоимости аренды этих нод.

Да, безусловно.
Обычные люди имеют тенденцию обсираться буквально на каждом шагу.
ну осталось найти где нужна такая квалификация.

OpenX - то такой бесплатный движок-крутилка рекламы? Я могу вам кое чего порассказать про эти самые крутилки, так как сделал их парочку в свое время. Джаббер gabaden at gmail точка com.

Ну и на самом деле написать крутилку на java не сильно сложнее, чем на php, а несколько тысяч req/sec получить можно запросто на ноду.

Про python/postgress в аналогичных условиях тоже хотелось бы почитать или послушать.

и s/послушать доклад/прочитать статью/
(ну или если будет видео с четким звуком)

Да. Когда и где?