У меня есть настольное приложение на базе Windows, которое обменивается данными с серверами приложений через TCP. (Windows 2003). Никаких липких сессий между звонками клиентов. У нас есть ровно 2 сервера для балансировки нагрузки, и мы думаем использовать аппаратную NLB F5.
Приложение представляет собой тяжелонагруженный тип, не выполняющий много служебной логики в службах, но в большинстве случаев извлекающий довольно большой объем данных. Может быть в среднем от 5000 до 10000 записей в любое время. Используется в основном для хранения и удаления данных и не требует специальной обработки данных или вычислений на стороне сервера.
Я предпочитаю «прогнозирующий», учитывая, что моим службам время от времени требуется время для возврата данных, и, следовательно, отслеживание обратной связи может дать лучшую маршрутизацию, чем при прогнозировании.
Я не уверен, достаточно ли предоставленных данных, чтобы предложить некоторые идеи, но, учитывая их, какие предложения \ вещи следует рассмотреть \ лучше всего между прогнозируемым и наименьшим количеством подключений?
Спасибо.
Насколько я помню, прогнозирование в контексте F5 - это постоянный мониторинг времени отклика службы. Это лучше всего работает, когда ожидается, что веб-запросы, проходящие через BiP, будут иметь одинаковое время ответа. Если внутренний сервер загружен, его TTR увеличится, и BiP будет уменьшать количество подключений, которые он отправляет, до тех пор, пока TTR не нормализуется.
Если запросы вашей службы имеют очень изменчивый TTR, значение, предоставляемое прогнозом, будет менее значительным. Имейте в виду, что BiP рассматривает ответ как передний край ответа; до тех пор, пока первый ответный пакет приходит надежно, не имеет значения, составляет ли поток 15 пакетов или 50 000. Если ваша служба ждет, пока не соберет все данные перед потоковой передачей, вы получите меньше пользы от прогнозирования.