如何在Kubernetes中配置Selenium Grid的三项核心环境变量

针对你提到的1000+并发会话、单会话至少10分钟、最长等待90分钟的场景，下面是三个关键环境变量的具体分析和配置建议：

1. SE_SESSION_REQUEST_TIMEOUT #

这个变量控制会话请求在Hub队列中的最大等待时长，超时后Hub会直接拒绝该请求并返回错误给客户端。

你的场景中，部分会话需要等待90分钟才能分配到节点资源，而Selenium Grid默认超时时间通常仅5分钟（300秒），不调整的话，这些长时间等待的请求会直接超时失败，导致业务中断。

配置建议： #

• 直接设置为比最长等待时间更长的值，比如95分钟（5700秒），预留5分钟缓冲时间，应对节点扩缩容延迟或突发资源紧张情况。
• 不要设置得过于夸张（比如超过2小时），避免无效挂起请求占用Hub内存资源。
• 配合客户端重试逻辑：若出现超时，让客户端自动重试，降低单次请求失败的影响。

2. SE_NEW_SESSION_THREAD_POOL_SIZE #

这个变量定义了Hub用于处理新会话请求的线程池大小，决定了Hub同时处理会话分配请求的能力。

默认线程池大小通常在5-10之间，对于你1000+并发会话的场景完全不够——大量请求同时涌入时，线程池会出现排队，不仅增加会话等待时间，还可能导致Hub因请求堆积性能下降。

配置建议： #

• 必须配置该变量，不能使用默认值。
• 初始取值建议设置为100-200：这个范围既能应对批量请求峰值，又不会过度占用Hub CPU资源。
• 后续根据监控调整：若Hub CPU使用率持续低于70%，可逐步调高到250-300；若CPU使用率超过80%，则适当调低，避免Hub成为瓶颈。
• 参考逻辑：线程池大小可参考总并发会话数的1/5到1/10，同时结合Hub CPU核心数（比如8核Hub设150左右，16核Hub设250左右）。

3. SE_NODE_SESSION_TIMEOUT #

这个变量控制单个会话在节点上的无活动超时时间——如果会话在节点上持续无操作（比如客户端崩溃、网络中断导致会话挂起），节点会自动回收该会话资源，释放slot给新会话。

你的场景中，单会话至少需要10分钟完成，这个变量的核心作用是清理僵尸会话，避免无效占用节点资源，保证节点利用率。

配置建议： #

• 设置为比业务会话最长执行时间多20%-30%的余量，比如业务会话最长10分钟，就设为12-15分钟（720-900秒）。
• 不要设置过短：比如设成10分钟，可能误杀执行时间刚好卡在10分钟的正常会话。
• 不要设置过长：比如超过30分钟，僵尸会话会长时间占用节点slot，降低节点可用资源，影响新会话分配效率。
• 结合节点动态扩缩容：若节点资源紧张，可适当缩小缓冲时间（比如从15分钟调到12分钟），但必须保证不覆盖正常会话的执行时长。

内容的提问来源于stack exchange，提问作者Anvesh Muppeda