Низкая задержка (высокая скорость отклика) Windows Network Service?

Да, это возможно и не слишком трудно, но решение является очень субоптимальным, так как SSH работает на основе TCP и имеет разумные издержки.

Сервер должен иметь в его конфигурационном файле sshd_config:

PermitTunnel point-to-point

Затем необходимо быть корнем на обеих машинах. Вы соединяетесь с использованием сервера:

ssh -w any root@server

После соединения используйте команду ip link в обеих системах для знания, какое tunN устройство было создано в каждом и использует его в следующих командах. Обратите внимание, что я использую пример локальные для сайта адреса, которые являются устаревшими, но хорошо для этого введения.

На сервере:

server# ip link set tun0 up
server# ip addr add fec0:1::1/112 dev tun0

На клиенте:

client# ip link set tun0 up
client# ip addr add fec0:1::2/112 dev tun0

Это достаточно так, чтобы можно было проверить с помощью ping-запросов другую сторону через туннель, если нет никакого блокирования правила брандмауэра. Следующий шаг должен установить маршруты по туннелю (не забывайте сеть ipv6.conf.default.forwarding=1), и затем скорректируйте ссылку MTU для получения оптимальной производительности.

server# sysctl net.ipv6.conf.all.forwarding=1

client# ip -6 route add default via fec0:1::1

Это позволит Вашему клиенту проверять с помощью ping-запросов другие сети, к которым сервер имеет доступ, учитывая, что цели имеют маршруты назад Вашему удаленному клиенту.

Необходимо будет также исправить ссылку MTU так, чтобы клиент не отправлял пакеты, которые сервер не сможет передать вперед. Это зависит от MTU ссылки IPv6 самого сервера. Не полагайтесь на путь исследование MTU, так как это не будет работать правильно по туннелю SSH. Если в сомнении, запустите с низкого значения MTU, как 1280 (минимальный MTU допускал IPv6).

1
задан 25 September 2013 в 09:30
1 ответ

Вы запрашиваете чрезвычайно низкие и предсказуемые задержки от языка со сборщиком мусора. GC будет приостанавливать вашу программу на X миллисекунд каждый интервал Y, пока выполняется поток GC.

Вы можете использовать Windows Performance Toolkit, чтобы проверить это, если хотите.

Вы можете немного настроить сборщик мусора с помощью

GCSettings.LatencyMode = GCLatencyMode.LowLatency;

Но его все равно придется запускать.

Это одна из причин, по которой вы не видите много блокбастерных 3D-игр, написанных на C #.

Настройте GC, если хотите, но я думаю, что это лучшее решение для этот тип приложений переключается на собственный код.


Вы также работаете в Windows 7, которая настроена на более короткие кванты потоков, чем серверная ОС, что означает, что контекст переключается чаще. (По иронии судьбы, так машина кажется более быстрой. )

Вы можете изменить это с помощью настройки « Настроить для наилучшей производительности фоновых служб ». Это общесистемный параметр, установленный для Windows Server. Что он делает, так это удлиняет кванты системного потока, что означает, что потоки запускаются задолго до того, как будет принято другое решение о планировании потоков, что означает меньшее количество переключений контекста. Идея состоит в том, что с более длинными квантами потока серверный поток, однажды выбранный для выполнения планировщиком потоков, сможет продолжать работать дольше и иметь больше шансов завершить свою работу (то есть обслужить запрос клиента) до того, как будет прерван / вытеснен другим потоком в системе.


Наконец, если ничего из вышеперечисленного вам не помогает, это может быть что-то другое. На этом этапе вам нужно проанализировать систему с помощью Windows Performance Toolkit,

3
ответ дан 3 December 2019 в 18:50

Теги

Похожие вопросы