ASP.NET/数据库性能检查表_Asp.net_Performance_Sitecore_Sitefinity

ASP.NET/数据库性能检查表

asp.net performance sitecore

ASP.NET/数据库性能检查表,asp.net,performance,sitecore,sitefinity,Asp.net,Performance,Sitecore,Sitefinity,最近，我们的客户开始抱怨我们的一台服务器性能差。这包含多个大型CMS实现和许多使用Sitefinity的小型网站。我们的托管团队现在正试图找到我们环境中的瓶颈，因为加载时间存在一些主要问题。我的任务是指定一大串要注意的事情，分为不同的部分（IIS、ASP.NET、特定于Web的）。我认为最好根据Sitecore文档e.d.找出一台服务器上可以运行多少个Sitecore CMS实例。我们希望能够监控并找出目前的瓶颈所在。我们的一些网站加载速度非常慢，其他网站加载速度非常快。在该服务器上运行的

最近，我们的客户开始抱怨我们的一台服务器性能差。这包含多个大型CMS实现和许多使用Sitefinity的小型网站。我们的托管团队现在正试图找到我们环境中的瓶颈，因为加载时间存在一些主要问题。我的任务是指定一大串要注意的事情，分为不同的部分（IIS、ASP.NET、特定于Web的）。我认为最好根据Sitecore文档e.d.找出一台服务器上可以运行多少个Sitecore CMS实例。我们希望能够监控并找出目前的瓶颈所在。我们的一些网站加载速度非常慢，其他网站加载速度非常快。在该服务器上运行的大多数Sitecore实现的后端性能都很差，编译后的加载时间也很糟糕。我们的Sitecore解决方案在Win 2008 64服务器和Microsoft SQL server 2008 for db上运行。我知道指定关于我们设置的更详细信息可能很方便，但我希望我们能够获得一些关于如何监视和查找瓶颈e.d.的有用基本信息

你有什么工具/提示/技巧和窍门？

不要使用太多不同的asp.net池，在plesk中称为和作为专用池。在同一池中放置更多站点
内存更多，或停止服务器上未使用的程序/服务
检查应用程序池上是否有使池继续自动重新启动的内存限制
在数据库上，将恢复模式设置为简单
从程序内部收缩数据库文件并重新索引数据库
在所有这些磁盘碎片整理之后

使用检查内存。
要检查服务器的启动情况，请使用，但注意不要停止任何关键服务，否则计算机将无法再次启动。不要停止自动运行的服务，请使用服务管理器将类型更改为手动。还有许多sql服务，如果您从未使用过它们，它们就不需要运行
其他一些提示

将临时文件/或asp.net生成目录移动到其他磁盘

从临时目录（cd%temp%）中删除所有文件

使用process exporer确保可用物理内存不为零。如果接近零，则服务器需要内存，或者需要停止运行未使用的程序

要将多个站点放置在同一池下，您需要更改新共享池下站点的权限。这并不难，只要花点时间组织起来，知道哪个站点在哪个池下运行。现在假设您有10个站点，最好使用2个不同的池，并根据每个站点的负载将站点分布在该池上。
不能说明Sitefinity，但会提供一些有关Sitecore的提示

尽可能使用Sitecore缓存，特别是在XSLT上（因为它们往往比布局和子布局更简单，因此Sitecore缓存不会破坏它们，就像Sitecore缓存对asp.net回发所做的那样），只有在经常访问重设和子布局等时，这种ofc才会有帮助。使用/sitecore/admin/stats.aspx？site=website检查未缓存的内容

使用Sitecores探查器，在探查器中打开一个项目，查看哪些子布局等需要时间

仅对最简单的内容使用XSLT，如果它变得比更复杂，我会选择子布局（asp.net控件），这有点偏颇，因为我不喜欢XSLT，但经验表明.ascx的速度更快

在静态文件上使用IIS的内容过期（prob all/sitecore，如果您有一些图像、javascript和CSS文件），这是针对IIS 6的：

使用Sitecore Databasetest.aspx检查数据库访问时间（Sitecore 6的访问时间比Sitecore 5和6上的简单访问时间好得多）

这正是我脑海中所能想到的。
Sitecore性能调整没有立即的答案。但以下是一些重要提示：
1）缓存
缓存就是一切。默认的Sitecore缓存参数很少适用于任何应用程序。如果有大量内存，则应增加缓存大小：

不幸的是，这是开发人员在部署安装时应该注意的事情，而不是系统管理员应该关心的事情
2）数据库
数据库是最后一个要检查的瓶颈。我很少接触数据库。但是，通过适当的设置可以提高DB性能：
提高性能的数据库属性：

这篇关于索引分段的文章非常有用：

Sitecore有一个主要的缺陷，它使用guid作为主键（在其他选择不当的数据类型中），这会将表从第一次插入时分割开来，如果您有一个使用率很高的Sitecore数据库，则在一小时内碎片会超过90%。这不是一个设计良好的数据库，建议在其他产品修复此问题之前查看它们，这给我们带来了巨大的性能问题（时间和金钱）。
我们处于停滞状态，无法再添加RAM，无法更频繁地重建索引。此外，请将IIS设置为每天在特定时间仅循环一次应用程序池。我通常把时间定在凌晨3点。这样应用程序就不会进入睡眠、循环或其他状态。最好是减少启动时间
另外，将IIS配置为“始终运行”，而不是“启动时”。这样，当应用程序重新启动时，它会立即重新编译，并随时准备启动

Sitefinity真的是一款很棒的软件（希望我上面的提示能得到大家的赞许，而不是我对产品的认可）。哈哈
您的大多数用户使用的是Sitecore或Sitefini的15%