StackExchange.Redis超时

4 回答

• 3

  有3种情况可能会导致超时，而且很难知道哪些情况有效：

  • 图书馆正在绊倒;特别是，有一些与TLS实现相关的已知问题以及我们如何在库的v1 . *版本中处理读取循环 - 这是我们为v2投入大量时间的事情 . *（但是：它不是总是很容易更新到v2，特别是如果你使用库作为依赖于特定版本的其他代码的一部分）

  • 服务器/网络正在绊倒;这是一个非常现实的可能性 - 如果它是服务器端的话，查看_732103可以提供帮助，但我没有任何可见性

  • 服务器和网络都很好，库正在尽其所能，但是客户端和服务器之间有一些巨大的blob正在推迟其他操作;这是我正在进行更改以帮助识别的东西，如果这表明它是一个常见问题，我们可以增加带宽，但可以减少阻塞操作的延迟） - 这将是仅限v2的更改，请注意

  回复于 2024-05-13T10:43:24+08:00
• 3

  懒惰连接

  作为最佳实践，请确保使用以下模式连接到StackExchange Redis客户端：

  private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() => {
      return ConnectionMultiplexer.Connect("cachename.redis.cache.windows.net,ssl=true,abortConnect=false,password=password");
  });
  
  public static ConnectionMultiplexer Connection {
      get {
          return lazyConnection.Value;
      }
  }
  

  如果上述方法不起作用，则有Source 1中描述的更多调试路由，涉及区域，带宽和NuGet包版本等 .

  IO线程

  另一种选择可能是增加最小IO线程 . 通常建议将IOCP和WORKER线程的最小配置值设置为大于默认值的值 . 关于这个值应该是什么，没有一个通用的指导，因为一个应用程序的正确值对于另一个应用程序来说太高/太低 . 一个好的起点是200或300，然后根据需要进行测试和调整 .

  How to configure this setting:

  • 在 ASP.NET 中，使用machine.config中<processModel>配置元素下的 minIoThreads 配置设置 . 根据Microsoft的说法，您无法通过编辑web.config来更改每个站点的此值（即使您以前可以这样做），因此您在此处选择的值是所有.NET站点将使用的值 . 请注意，如果将autoConfig设置为false，则不需要添加每个属性，只需输入 autoConfig="false" 并覆盖该值即可： <processModel autoConfig="false" minIoThreads="250" />

  重要说明：此配置元素中指定的值是每核设置 . 例如，如果你有一台4核机器，并希望你的minIOThreads设置在运行时为200，你可以使用<processModel minIoThreads =“50”/> .

  • Outside of ASP.NET ，使用ThreadPool.SetMinThreads() API .

  • 在 .Net Core 中，添加环境变量COMPlus_ThreadPool_ForceMinWorkerThreads以覆盖默认的MinThreads设置，根据Environment/Registry Configuration Knobs - 您也可以使用与上述相同的 ThreadPool.SetMinThreads() 方法 .

  来源：

  • Microsoft Azure - Investigating timeout exceptions in StackExchange.Redis for Azure Redis Cache

  • StackExchange.Redis

  回复于 2024-05-13T10:43:24+08:00
• 0

  打开网络流量监控器以确认/拒绝blip.Ave解决了问题，但原始问题 . 选项1 - 尝试在azure中重新启动托管redis instamce .

  回复于 2024-05-13T10:43:24+08:00
• 0

  我的猜测是网络稳定性存在问题 - 因此超时 .

  由于没有人提到 responseTimeout 的增加，我会玩它 . 默认值为 50ms ，可以轻松访问 . 我会尝试围绕 200ms 查看是否有助于消息 .

  取自configuration options：

  responseTimeout={int}   ResponseTimeout     SyncTimeout     Time (ms) to decide whether the socket is unhealthy
  

  在github上打开了多个问题 . 结合所有的可能是#871 The "network stability" / 2.0 / "pipelines" rollup issue

  还有一件事：你是否尝试使用 ConnectionMultiplexer.ConnectAsync() 来代替 ConnectionMultiplexer.Connect() ？

  回复于 2024-05-13T10:43:24+08:00