Я работаю над проектом на стороне сервера, предоставляющим услугу запрос / ответ через TIBCO EMS, и ищу советы по передовой практике для архивирования масштабируемости и низкой задержки в этом сервисе.Я делаю это в .NET, но так как TIBCO EMS предположительно реализует спецификацию JMS, я предполагаю, что рекомендации для других реализаций JMS, а также платформ (Java) были бы уместны.
В настоящее время мы используемодно соединение, один сеанс, один получатель и прослушивание сообщений с использованием обратного вызова на этом единственном получателе.Каждый запрос обрабатывается в потоке обратного вызова, синхронно отвечает в другой очереди (но в том же сеансе).Это работает, но, похоже, не масштабируется - загрузка ЦП незначительна даже при высоких скоростях транзакций, но время ожидания запроса продолжает расти.
Я предполагаю, что происходит то, что EMS использует один поток для обратного вызова, и поэтому время обработки, а также время, необходимое для отправки ответа, блокирует обработку других запросов, но - что лучшеспособ получить это в масштабе?
Одним из способов будет немедленное планирование фактической обработки входящего запроса в пуле потоков после его получения.Это быстрое решение, которое масштабируется, но добавит дополнительную задержку и вызовет проблемы с потоками при использовании сеанса.Другой - иметь несколько объектов Session или даже объектов Connection?Может кто-нибудь, пожалуйста, совет по наилучшей практике для этого, я думаю, это должен быть один из наиболее распространенных шаблонов использования там ...