Здравствуйте, IB, Вы писали:

V>>А если система принципиально способна давать ответы со скоростью их поступления, и если кривая быстродействия положительная (а она обязана быть положительной у грамотно спроектированной системы) — там "класть" физически нечего. Нет механизма "кладки".
IB>Ты серьезно утверждаешь, что NoSQL имеет бесконечную производительность? Типа dev/null ?

Я серьёзно утверждал нечто другое:

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

IB>Огонь, жги дальше )))

Пффф...
Жесть — это когда претендующий на специалиста по серверным СУБД (ключевое "серверным"), настолько злостно плавает в азах ТМО/СМО.
Злостно — потому что вместо того, чтобы спросить, опять торопится "клеймить".
Ты неисправим. ))

Кароч, левая часть формулы Литтла должна отвечать неравенству >= по мере продвижения запросов м/у подсистемами комплексной системы, тогда гарантируется конечность длины очередей на всех участках комплексной системы.

Для тех кто в танке: достаточно достичь мгновенной плотности обработки запросов в целом по системе не меньшей, чем максимальная ожидаемая плотность входящих в самую первую подсистему запросов и ву а ля. (Для тех, кто вовсе в "Армате" — последнее переводится в банальную пропускную способность сети через среднюю длину запросов в байтах + длину служебной инфы протокола).

Т.е. речь всегда не о мифической "бесконечности", разумеется, а лишь о системе соблюдающихся неравенств.

Например, в моей области (которое тоже сплошное ТМО/СМО) порой используется банальный подстраиваемый throttling + прочие разновидности квотирования для целей выравнивания производительности подсистем. Иначе в какую-нить "Чёрную Пятницу" ресурсы быстро исчерпаются из-за перекоса и всё тупо ляжет.