Разгон и торможение Windows NT


         

Если же продолжительность замера превышает


Если же продолжительность замера превышает 20 мс, планировщик Windows автоматически перераспределяет процессорное время так, чтобы переключение контекста основного потока (и этим потоком будет тестовый поток!) происходило как можно реже, а его накладные расходы стремились к нулю. Естественно, остальные потоки системы сажаются на голодный паек, работая рывками (и, как мы увидим далее, даже при умеренной загрузке системы на "плохих" ядрах, потоки получают управление не чаще чем один раз… в десть секунд. Не "тиков", а именно секунд! И хотя интегральная производительность системы не только не уменьшается, но даже возрастает, работать с ней становится невозможно).

Тоже самое относится и к имитатору WEB-сервера. Допустим, один ядро обрабатывает сто тысяч запросов за минуту, а другое – сто пятьдесят. Какое из них производительнее? А если первое обслуживает всех своих клиентов плавно, а второе отдает информацию "плевками" с паузами по десять-пятнадцать секунд? К сожалению, известные мне тесты этого обстоятельства не учитывают и потому их показания при всей своей объективности толкают на выбор неправильного ядра. Помните анекдот про машину, которая ездит быстро, но тормозит медленно? Производительность – это не только отношение количество проделанной работы к затраченному времени, это еще и качество предоставляемого сервиса!

Сформулируем главное требование, предъявляемое нами к системе: планировщик должен исхитриться перераспределить процессорное время между потоками так, чтобы обеспечить наилучший баланс между производительностью и плавностью работы даже при большом количестве одновременно выполняющихся потоков. Теперь для достижения полного счастье остается лишь найти ядро своей мечты…


Содержание  Назад  Вперед