天蓝色缓存性能不佳

Posted 2023-05-07

【中文标题】天蓝色缓存性能不佳

【英文标题】：poor performance with azure cache

【发布时间】：2012-02-04 00:18:44

【问题描述】：

在将几个数据库调用切换到缓存之后，我们的性能实际上更差了。根据新的遗物，我们注意到 CLR 时间和响应时间大幅增加。请参阅所附图表以了解跳转（缓存于 0:00 于 1/5 引入）。 唯一改变的是 Azure App Fabric Cache 的引入。我们的缓存客户端使用单例模式，因此 Web 服务实例只有一个。缓存工厂只创建一次，然后存储起来，因此我们不必承担每次打开连接的开销。

此外，NewRelic 报告说缓存平均需要 15 毫秒。很多情况下，15ms 可能比数据库还慢！！！

nto 我们要粘贴的对象是两个字节数组的缓存常量，一个长度约为 421，另一个长度为 8。

不太明白为什么引入缓存后我们会看到响应时间增加。字节数组对缓存不友好吗？

我的类看起来像这样（在被推入类之前填充的唯一两个属性是两个字节数组，其他所有内容都保留为默认值）

[Table]
public class GameState

    [Column(IsPrimaryKey = true, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)]
    public int Id  get; set; 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "game_id")]
    public int GameId  get; set; 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "player_id")]
    public int PlayerId  get; set; 

    [Column(UpdateCheck = UpdateCheck.Never, DbType = "VarBinary(max)")]  //has a length around 421
    public byte[] State  get; set; 

    [Column(UpdateCheck = UpdateCheck.Never, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)]
    public DateTime Created  get; set; 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "update", IsDbGenerated = true, DbType = "timestamp")] //has a length of 8
    public byte[] TimeStamp  get; set; 

谢谢

更新

我们与几位 Microsoft 工程师进行了交谈，没有人可以帮助我们解释为什么它如此缓慢。一位工程师报告说缓存层构建在 SQL Azure 之上，这解释了高请求时间。另一位工程师否认了这一说法，但不确定共享缓存是如何实现的。

我们始终无法让 Azure 缓存快速运行，最终从 Azure 切换到 Amazon ec2。一旦在类似硬件上的 Amazon ec2 上，我们的响应时间下降到大约 60-70 毫秒。

对于其他考虑这一点的人来说，这是我们在转换中学到的。

SQL Azure 是共享数据库托管。你没有自己的数据库，你在一个有一堆其他数据库的服务器上，如果你有任何体面的流量，你会受到限制。他们不断告诉我们一些购票成功的故事，但在那种情况下，他们有 750 个 DB 来处理交易。分片并不好玩，一个更好的成功案例是您使用 1DB 处理了所有这些请求。

我们使用 SSL，让 IIS 管理 SSL 真的会杀死你的 CPU。亚马逊让你的 ELB 做 ssl，然后你的 IIS 盒子就不需要了。这释放了 IIS 框以更快地处理请求。

Amazon 允许您运行 memcache。内存缓存很棒。拥有一个轻快的高速缓存层（能够远远超过 4GB），为我们的数据库减轻了巨大的负担。

我们在 2012 年 1 月进行了切换，因此它的 Azure 可能在去年变得更好，但是我没有计划给它第二次机会。

【参考方案1】：

Azure Cache 的性能并不那么令人满意。基本上是因为 Azure Cache 在通信时有自己的负载平衡。但是你可以尝试开启本地缓存功能，这样会提高加载性能。

【讨论】：

本地缓存功能有什么作用？你能详细说明这会有什么帮助吗？

本地缓存是缓存的另一个配置选项。这意味着缓存中的项目会在内存中存储一​​段时间，因此如果再次请求它，则不需要连接到缓存服务。这只有在数据变化不大的情况下才有用。如果缓存中的项发生更改，则不会将其推送到本地缓存中具有相同项的其他实例。 msdn.microsoft.com/en-us/library/ee790816.aspx

【参考方案2】：

网络配额有三种变化：

交易 带宽 并发连接

在您的性能测试中，我怀疑并发连接数限制是罪魁祸首，来自 MSDN：

每个缓存产品对可以同时打开到同一个缓存的连接数有不同的限制……使用 Windows Azure 缓存的应用程序必须了解如何打开到缓存服务的连接。每个缓存产品对可以同时打开到同一个缓存的连接数有不同的限制。

来源： https://azure.microsoft.com/en-us/documentation/articles/cache-dotnet-how-to-use-service/

如果这没有多大帮助，那么您可以考虑比较不同的并发模型。 AppFabric 支持乐观和悲观并发模型，请参阅http://msdn.microsoft.com/en-us/library/ee790890.aspx 了解更多信息。

【讨论】：

我只是将每台服务器的并发连接数从 2 个增加到 6 个，但没有任何效果。我们也在使用乐观缓存，没有任何东西被锁定。

您能否尝试关闭 Nagling，因为您的数据小于 1,500 字节，它可能会提前关闭连接

我没有看到为 azure 缓存关闭 Nagling 的选项，仅适用于 azure 存储。