Я помню, что были правила как гарантия 100kbit/sec в течение первых 2 секунд затем 10 кбит
как
класс tc добавляет родителя dev eth0 1:1 classid 1:30 hfsc \sc m1 100 кбит d 2 000 мс m2 уровень ул. на 10 кбит 1000 кбит
Это на самом деле, в чем Вы нуждаетесь, но помните, что современные браузеры могли использовать длинные активные очереди, которые Вы могли заблокировать с такими правилами также.
Может быть задействовано множество очередей; Я думаю, что ваше описание неполное.
IIS позволяет вам указать, что определенные части сайта запускаются в разных пулах приложений, каждый из которых выполняется в отдельном рабочем процессе.
Каждый пул приложений имеет очередь запросов в режиме ядра. (по умолчанию 1000 запросов), используемый для гарантии того, что в случае переработанного W3WP (рабочего процесса) запросы не будут потеряны, но это также становится практическим максимальным пределом для невыполненных запросов в данный момент.
Если это очередь заполняется, вы получаете 503.
Фреймворки приложений, такие как .Net или классический ASP, также могут реализовать свою собственную очередь запросов пользовательского режима, которая выполняется в рабочем процессе. Я не верю, что в рамках фреймворка можно расставлять приоритеты для различных запросов (если нет ASP. Net, которая делает это, с которой я не знаком).
Если у вас ограниченное количество потоков в пуле потоков каждого процесса, разделение приложений на (например) пулы приложений статического и активного содержимого может помочь сохранить базовый Отработайте пул потоков загруженного процесса приложения. (Точно так же добавление дополнительных потоков является (возможно) разумным подходом к этому).
Я не верю в это, но у вас может быть два сайта, один для потребительского трафика и один для трафика инфраструктуры, тогда у каждого из них будут свои очереди.