Там должен так или иначе улучшить производительность inetd?
Если Вы открыты для решения Microsoft/IIS 7, одна опция состоит в том, чтобы использовать Маршрутизацию запроса приложения (ARR) IIS7.
Существует введение/учебное руководство здесь в этой статье о learn.iis.net: Выравнивание нагрузки HTTP с помощью Маршрутизации Запроса приложения. Существует функция, названная "Разгрузка SSL":
Когда эта опция активирована, вся коммуникация между сервером ARR и серверами приложений сделаны в открытом тексте, даже для Запросов HTTPS от клиентов к серверу ARR. Когда и сервер ARR и серверы приложений развертываются в надежной сети, такой, поскольку в том же центре обработки данных, включая разгрузку SSL не жертвует безопасностью.
Кроме того, активация этой опции может далее помочь максимизировать ресурсы сервера на серверах приложений, так как они не должны тратить циклы в шифровании и дешифровании запросов и ответов.
Если Вы хотите копаться в предмете, вот другая статья о ARR, который объясняет, как использовать механизм в сочетании с аппаратными подсистемами балансировки нагрузки.
Одна из проблем при пробежке inetd - то, что это собирается представить наверху в производительности. Если производительность является беспокойством, которое это, не используйте inetd и используйте автономного демона.
Лучший способ улучшить производительность состоял бы в том, чтобы вынуть inetd из изображения. Но если Вы действительно, действительно должны использовать inetd, вот некоторые идеи:
- Renice inetd к отрицательному приоритету.
- Выключите / от входа inetd
- Журнал к более быстрому диску / набег.
Другая возможность состоит в том, что Ваш сервис обрабатывает один запрос или небольшое количество запросов, и затем закрывается. Если это так, затем при загрузке inetd использует много времени, повторно запуская Ваш сервис. Таким образом, Вы хотите избежать того сценария.
Заключительная возможность состоит в том, что проблема, которую Вы видите, вызывается серверными процессами, не завершающимися правильно и бродящими вокруг израсходования ресурсов ядра. В худшем случае они могут даже вращаться. Стоило бы использовать контрольные инструменты Вашей системы для наблюдения то, что на самом деле происходит, когда система работает медленно.
Можно ли дать нам некоторое представление о различии между "очень очень медленно" и "очень быстро"? Могло случиться так, что inetd делает что-то как выполнение обратного поиска IP-адресов на каждом соединении (я не знаю наверняка, это - просто предположение), и возможно Вам не настраивали сервер DNS для ответа, таким образом, это получает 1 или 2-минутный тайм-аут на каждом соединении.
Если различие будет "10 в секунду" по сравнению с "12 в секунду", то у Вас будут другие вопросы, чем если различие будет, "занимает 90 секунд для ответа" по сравнению с, "отвечает сразу же".
-
1
Это кажется, что Ваш сервис TCP запускается для каждого запроса, поступающего к inetd, затем закрывшись сразу.
Разветвление нового процесса как это для каждого запроса является довольно медленным, таким образом, я думаю, что лучшее место для взгляда изменяет сервис TCP для оставлений в живых для обработки x количества запросов перед закрытием.