Я написал сетевую службу Windows с использованием C #, которая предназначена для работы на машине с Windows 7. Он разработан, чтобы иметь возможность обрабатывать несколько запросов за одну миллисекунду, с чем, похоже, он справляется по большей части без задержки.
Иногда, через каждые несколько тысяч миллисекунд, сервер может испытывать длительную задержку до 40 мс, когда в течение этого времени клиент отправил столько же пакетов, но не получил ни одного ответа. Внезапно сервер проснется и ответит на все запросы в течение нескольких миллисекунд (время обработки каждого запроса находится в районе 0,1 мс).
Как я могу изменить свой код или настройки службы Windows, чтобы сервер стал более отзывчивым? Было бы лучше минимизировать всплески длинных задержек (10 мс - терпимо, <5 - более разумно, <1 мс - цель), но регулярность задержек также вызывает беспокойство.
Спасибо.
РЕДАКТИРОВАТЬ: Серверная машина, на которой я все тестирую, - это ноутбук с процессором Core 2 Duo и хранилищем SSD.
Вы запрашиваете чрезвычайно низкие и предсказуемые задержки от языка со сборщиком мусора. GC будет приостанавливать вашу программу на X миллисекунд через каждый интервал Y, пока выполняется поток GC.
Вы можете использовать Windows Performance Toolkit, чтобы проверить это, если хотите.
Вы можете немного настроить сборщик мусора с помощью
GCSettings.LatencyMode = GCLatencyMode.LowLatency;
Но в конечном итоге его все равно придется запустить.
Это одна из причин, по которой вы не увидите много блокбастерных 3D-игр, написанных на C #.
Если хотите, настройте GC, но я думаю, что лучшим решением для этого типа приложений является переход на собственный код.
Вы также работаете в Windows 7, которая настроена на более короткие кванты потоков, чем серверная ОС, что означает, что контекст переключается чаще. (По иронии судьбы, так машина кажется более быстрой.)
Вы можете изменить это с помощью настройки 'Отрегулируйте для лучшей производительности фоновых служб'. Это общесистемный параметр, установленный для Windows Server. Что он делает, так это удлиняет кванты потоков системы, что означает, что потоки запускаются задолго до принятия другого решения о планировании потоков, что означает меньшее количество переключений контекста. Идея состоит в том, что с более длинными квантами потока серверный поток, однажды выбранный для выполнения планировщиком потоков, сможет продолжать работать дольше и иметь больше шансов завершить свою работу (то есть обслужить запрос клиента) до того, как будет прерван / вытеснен другим потоком в системе.
Наконец, если ничего из вышеперечисленного вам не помогает, возможно, дело в другом. На этом этапе вы захотите проанализировать систему с помощью Windows Performance Toolkit, и вы можете обнаружить, что всплески задержки на самом деле вызваны драйвером сетевого адаптера, платформой фильтрации Windows, чем-то в стеке ввода-вывода ... кто знает .