Не знаю, но такая нагрузка представляется мне довольно-таки 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 трогал...

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