Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Итак, из одной очереди сделали две (основная и очередь нитей на эвенте, связанном с лимитом). Какие бонусы мы от этого получили? никаких, кроме аллокации памяти на сами IRPs, которые сидят в основной очереди, и залоканных страниц в MDL буферах, связанных с этими IRPs. Это обычно совсем не заметно, а если лимит наложен в кернеле — то и этого грошового выигрыша нет — в драйвер приходят уже сформированные IRPы с залоканными MDLями.
MSS>Таким образом, искусственные лимиты есть как правило зло они привносят в систему еще один, причем дефицитный, ресурс, и ничего не улучшают.
Искусственные лимиты полезны — мы можем дать гарантию, что запрос обработается максимум за N секунд, если он таки был принят на исполнение. Если же у нас нет лимита — возможна ситуация, когда очередь будет расти неограничено.

MSS>Теперь — как правильно накладывать эти лимиты. Правильно — это понять, какую именно нагрузку хочется "отмодерить", и накладывать лимит именно туда, на самый низкий уровень. Надо отлимитировать сетевой трафик, создаваемый кодом? поставьте Sleep после send(). Надо отлимитировать дисковый трафик? поставьте Sleep после Read/WriteFile. На какую длительность Sleep? рассчитать от числа пропущенных через IO байт и временных меток начала-конца операции. Элементарно, не буду тут в это вдаваться, напомню только, что точность Sleep — что-то вроде 100ms.
За такие хаки я бы лично ногами бил разработчиков. Код должен работать на максимум пропускной способности. Ограничивать ее — дело операционной системы (планировщиков IO, процессора, сети — они лучше свою работу знают).

Такие sleep-хаки могут привести к паталогическим случаям, если две программы будут просыпаться в одно и то же время — они будут обе считать, что процессор загружен на 100%.