@hirthwork кукарек

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

@etw охуительный метод решения проблемы. почему блять нельзя было синкать на каждый мессадж? как раз бы и получились те самые несколько (7.2) тысяч.

@anonymous синкать и *потом* высылать подтверждение наверное потому что долбоёбы потом своим однопоточно-последовательным тестом померяют длину вместо ширины и скажут что у монгодб намного лучше всё это.

@anonymous Потому что тогда узким местом стала бы дисковая подсистема и ты бы 7,2 к точно бы не получил.

@etw а где ещё может быть узкое место такой системы? цпу штоле. только ио, дисковое как самое тормозное. я напиздел чутка конечно, 7.2к - это в минуту. получается лаг 10мс. не супер, но вполне приемлемо. а на количестве запросов в секунду это скажется примерно никак, если писать на диск подряд.

@anonymous > я напиздел чутка конечно, 7.2к - это в минуту На этом вопрос, думаю, можно закрыть. И ты забыл еще рассказать, зачем mq durability в уеб-задачах.

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

@hirthwork плюнул на спину

@anonymous > тупой штоле, это не максимальное количество месседжей в секунду, это лаг на месседж Кого вообще ебет лаг, если ты уже схватился за mq, а значит тебе нужна асинхронная обработка данных? Да пусть хоть по 2 секунды на каждое сообщение тратит, если бы нужен был реалтайм, дергался бы напрямую api приемника без всяких очередей. > пускай дальше денвер пердолят, в самый раз. все с тобой ясно, продолжай дальше пердолить опердень.