我应该将哪个超时设置为外部服务？

Question

此服务是remote session pool。我需要要求一个会话与其他服务一起工作。在大多数情况下，这个池将有一个会话可用，所以在15ms我会有一个响应。但有时，它需要按需创建会话，需要最多800毫秒来创建它。

我有两种选择来处理这种情况：

1. 设置15ms的超时时间，并以指数退避实现重试策略，直到800ms。无论我是否与其连接，此服务都将创建所需的会话。

2. 设置800毫秒超时，并保持与服务的连接，直到我可以使用会话。

在这两种情况下，都不能保证我会在800ms后开会。

所以问题是：每个选项的优缺点是什么？

Answer 1

  

1。设置15ms超时，并以指数退避实现重试策略，直到800ms。无论我是否连接到该服务，该服务都将创建所需的会话。

临

1. 检测到会话无法立即使用，不需要等待几秒钟。
2. 由客户端再次请求会话或以其他方式进行，您可以更灵活地处理不同的用例。
3. 每次回退策略进行时，您都可以区分等待会话超过15毫秒的非期望事件，这对于异常会话池行为检测非常有用。

缺点

1. 由于回退行为，代码更复杂。
2. 由于不同的超时而导致的多个参数。

  

2。设置800毫秒超时，并保持连接到服务，直到会话可用为止。

临

1. 简单直接的实施
2. 简单参数化

缺点

1. 您无法注意到会话池中的会话创建事件延迟。这对于跟踪和诊断很重要，这种简单的方法可能会隐藏会话池问题。
2. 针对不同客户的用例不灵活实施。

-

我认为决策驱动因素是您是否需要针对此用例的正常工作的解决方案，或者此方法是否将用于不同的客户端和用例。

---

PS：如果您需要为不同的客户创建解决方案，那么创建更复杂的协议也是值得的，例如：

// just takes a session if available, no more than 15msec delay expected
get_session(...)  : session 

// if not available, creates one
get_session_or_create(...) : session 

available_sessions(...) : int

//  between 0 and 1, the proportion of available sessions
availability(...) : double  

...

由客户决定如何使用它。

根据会话创建延迟差异，将超时参数的大小设置为某个安全％。