糟糕的DotNetNuke性能 [英] Terrible DotNetNuke performance

查看:67
本文介绍了糟糕的DotNetNuke性能的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我参与了一个使用 DotNetNuke版本05.01.04社区版的项目。我们正在使用它来构建新的Intranet,但是性能却很糟糕。



我们有5个人在其中添加页面和内容,每15-30秒至少需要10秒的暂停时间或更长的时间,然后系统才能继续运行并加载下一个屏幕。



该服务器是Windows 2003,3.8GHz,带有1GB RAM。服务器管理员告诉我,CPU和内存性能似乎不是瓶颈。



我们目前在系统中有350个页面,我们有一个计划加1000。所以我们需要解决此性能问题,以便我们可以输入内容并可以上线。



我只是看不到瓶颈在哪里。为什么在使用DotNetNuke时确定瓶颈?



已安装模块




  • 发布:订制(当前未在
    中使用)

  • Page Blaster (未出现当用户
    使用集成
    身份验证登录时提供缓存)

  • SimpleGallery

  • XMod

  • 内容管理器



IIS设置

应用程序回收完全禁用(除了凌晨2点回收)



新发现:2010年3月18日

主要瓶颈是由于5.1.4版存在一个错误,该错误导致数据库内存缓存损坏,导致平均页面上有1300次数据库往返。我们已经升级到5.2.4,已经解决了此瓶颈。



现在,下一个最大的瓶颈是导航。我们已经使用了 DDR:Menu 和DDN:Nav,但是两者都对性能产生重大影响。 / p>

是否有一个导航界面不会严重影响性能?

解决方案

我认为您需要开始使用性能分析工具对此进行调查。对于DNN应用程序本身,我会使用类似JetBrains DotTrace 或Red Gate的 ANTS Performance Profiler



对于数据库,SQL Server Profiler将是首选,或者是诸如Red Gate的 SQL响应



如果不对应用程序进行概要分析,则您将无所适从。



并且正如Tim在评论中所指出的那样,使用YSlow加载项在Firefox中安装Firebug,以查看哪些资源需要最长的时间提供给浏览器。


I'm involved with a project using DotNetNuke version 05.01.04 Community Edition. We are building our new Intranet using it, but performance is terrible.

We have five people adding pages and content to it and every 15-30 seconds they experience a pause of 10 seconds or longer before the system continues and the next screens loads.

The server is Windows 2003, 3.8GHz with 1GB of RAM. I'm told by our server admin that the CPU and memory performance don't appear to be the bottleneck.

We currently have 350 pages in the system, we a plan to add 1000. So we need to resolve this performance problem so that we can enter content and so we can go live.

I just can't see where the bottleneck is. Is there a good why to determine the bottleneck when using DotNetNuke?

Modules installed

  • Publish:Engage (Not currently in use)
  • Page Blaster (Doesn't appear to providing caching when users logged in using Integrated Authentication)
  • SimpleGallery
  • XMod
  • Content Manager

IIS Setup
Application recycling completely disabled (Apart from a 2am recycle)

New findings: 18th March 2010
The main bottleneck was due to version 5.1.4 having a bug which caused 1300 database roundtrips on an average page, due to broken database in-memory caching. We've upgraded to 5.2.4 which has resolved this bottleneck.

Now the next biggest bottleneck is the navigation. We've used both DDR:Menu and DDN:Nav, but both have a major impact on performance.

Is there a navigation interface out there that doesn't drain performance so badly?

解决方案

I think you need to start investigating this using performance profiling tools. For the DNN application itself I'd grab something like JetBrains DotTrace or Red Gate's ANTS Performance Profiler.

For the database SQL Server Profiler would be the first choice or a tool such as Red Gate's SQL Response.

Without profiling the application these you're going to be pulling at straws.

And as Tim pointed out in his comment, installing Firebug in Firefox with the YSlow add-in to see what resources are taking longest to serve to the browser.

这篇关于糟糕的DotNetNuke性能的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆