2014-11-25 90 views
1

目前我们已经为我们的web应用以下设置:Azure的云服务性能差异

预生产:

1层中的实例(Web角色运行的是Windows 2012) 1 Web层的SQL Server 存储占斑点

直播:

2大对象(网络角色r unning窗口2012) 1个Web层的SQL Server 存储帐户的斑点(共享相同的帐户作为预PROD)

所有的服务器,存储账户都位于同一地区(北欧)

的我们遇到的问题是预生产服务器在服务页面时比现场设置更快,但我们无法弄清楚原因。它们的设置完全相同,只是指向不同的数据库。

不同之处在于主控制面板页面在预产品盒中需要300毫秒,而在现场需要600毫秒。当bot应用程序没有被我们使用时,我们测试了这个功能,所以它不会被加载到盒子上。

我们在两个设置(内存的30%)中也都有角色内缓存查看服务器,它既不是CPU使用率也不是内存使用率过高。

有没有人知道任何明显的事情,我们应该检查为什么现场部署比预产更慢?

回答

0

实际问题原来是我们在应用程序中进行的一些日志记录。日志服务器在美国和共享平台上,解释了为什么我们在现场发生延迟。它看起来像我们第一次检查这可能是导致它的日志记录设置的性能很好,但认为这可能是由于它检查的时间。

1

希望一切都好! :)

有我会看两两件事:

  1. 取决于你如何管理你的预生产DB和多大你的网站,你的生产数据库可能有更多的数据在其中 - 所以当你计算你的统计数据时,要花很长时间才能完成。根据我的经验,Web和Standard数据库的性能较差 - 比您运行SQL 2000的10年前的服务器预期的要糟糕。因此,当您运行计算或收集大量数据时,它确实对这些版本产生了很大的影响。商业版速度更快,与P1相似,但性能不稳定,所以可能值得升级。
  2. 数据库是否托管在同一台服务器上?从网络/业务模式转向基本/标准/高级定价模式的主要(官方)原因是为了提供一致和可靠的性能。如果你在另一台服务器上有一个数据库,那么你可以与正在锤击数据库并降低性能的人共享这些资源。

我发现,该数据库是在Azure上的瓶颈和2层中的实例用了一天1周万名左右的游客舒适地应付,所以你也许可以降低这些实例的成本来抵消升高的成本关于使用业务数据库。

,可能是有用的唯一的另一件事是,在Windows Azure管理,下数据库>显示器,他们升级的指标,而后面一点点地包括像CPU%,IO%等,但他们不是在图表上默认。如果您添加这些指标,可能会提供更多信息进行调试。

北欧在西欧国家还有一个原因吗?