AppFabric缓存性能问题与Velocity [英] AppFabric Caching performance issue vs Velocity

问题描述

我们看到AppFabric缓存（WindowsServerAppFabricSetup_x64_6.0）与Velocity Ctp3的获取/放置时间较慢。

We are seeing slower get/put times for AppFabric Caching (WindowsServerAppFabricSetup_x64_6.0) vs Velocity Ctp3.

- 服务器对于两者都是相同的，2008 Std，已满在安装AppFabric之前卸载Velocity

- 总计4GB，保留的缓存量设置为2GB。

- 只安装了缓存，没有托管（IIS7关闭）。没有其他主要服务运行（数据库等）。 VM仅保留用于缓存


- VMWare esx 3.5.0

- .Net 4.0 / 3.5均已安装。

- 缓存的TTL = 360。

- 日志中没有错误。

- 防火墙已关闭

-- Server is same for both, 2008 Std, with full uninstall of Velocity before installing AppFabric
-- Ran in 4GB total, with amount reserved for caching set at 2GB.
-- Only caching is installed, no hosting (IIS7 turned off). No other major services running (database, etc.). VM is reserved for caching only
-- VMWare esx 3.5.0
-- .Net 4.0/3.5 both installed.
-- Cache has a TTL=360.
-- No errors in the logs.
-- firewall is off

我们正在测试的步骤序列涉及客户端清除缓存区域，然后是下一个请求重建业务将对象重新放入缓存中。对于Velocity和AppFabric（在单独的服务器上的相同客户端
应用程序），重建过程是相同的，因此我们假设put中存在滞后。 AppFabric为Velocity = 3s vs 20s重建+ put。

The sequence of steps we are testing with involves the client clearing a region of the cache, followed by the next request rebuilding the business object to place again in the cache. The rebuild process is identical for Velocity and AppFabric (same client application on a separate server), so we assume there is a lag in the put. Rebuild + put for Velocity = 3s vs 20s for AppFabric.

推荐答案

此问题已得到解决。在Microsoft技术支持的建议中检测应用程序的过程中，我们确定生产和测试之间存在DLL修订不匹配，这是长延迟时间的来源。

This issue has been resolved. In the process of instrumenting the application at Microsoft Tech Support's suggestion we determined that there was a DLL revision mismatch between production and test that was the source of the long delay times.

这篇关于AppFabric缓存性能问题与Velocity的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！