Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...DotNetNuke Speed - LetDotNetNuke Speed - Let's be honest
Previous
 
Next
New Post
7/11/2006 2:07 PM
 

We are a very experienced .NET development house. Since discovering DNN we have almost aligned all our web development projects to be based on the DNN framework. Me and the development team have now developed about 10 sites based on DNN (from 3.1.0 up until 3.3.2).

I would say we have about a years in depth experience of DNN, developed very custom large community sites on DNN and small company sites. The beauty of DNN is how powerful it is and the endless possibilities for scalability.

The down side it would seem is speed. DNN just seems to be terribly slow compared to a total bespoke web application. I have noticed this particularly when doing anything in the admin side. Updating site settings or loading and editing stuff in the Text/HTML module just takes ages. Now for us this is a problem; we can offer clients very powerful CMS based on DNN but at the expense of speed.

Does anyone agree with this? I have also recently noticed a tremendous slowdown in the dotnetnuke site itself. Is this as a result of the upgrade?

My opinion is that DNN needs a document that specifies clearly do's and don'ts. Things that make sites slow etc. What are reccommended hosting requirements? Especially from a custom module perspective. The dnn technology itself has been around for years, but I am pretty sure that speed is an issue in general. I am just not totally convinced about it being as fast as any other site out there. Does the core team have any plans to tackle performance issues?

 
New Post
7/12/2006 7:42 AM
 
I've been using DNN for about a year, and performance is still bothering me. I just moved several websites over to new shared hosting, and I hope things get a little better. One host told me I had to pay for extra db space, because my db was too big. I only have 20 pages and a few users, deleted the 2 DNN sitelog tables, sql shrink, no binary data in there, but the db is still over 60MB.

DNN is very resource intense, and I believe it's mainly due to the number of connections made to the database in one page load. That's just how portals usually are. There must be 10 connections in most average page loads. SQL Server is the one eating up all the resources on the dedicated servers I manage. I can't believe DNN even runs in a shared environment.

In contrast, your own standalone apps, you can easily control how many connections you make in one page load. You probably make 3 at the most, and that's if you're pegging the db each time for user authorization/authentication.

Also, in the page design, you have many style sheets loading, and a lot of other redundencies that force web designers to do things they wouldn't do with normal websites. This makes the generated html/js sent to users far more heavier than a standalone app.

My only advice is, for your own client's custom apps, do not bother using the DNN sql data provider. This will just create more roundtrips for no reason. Plus it's 3 times the work to use it IMO. Just use straight ms application blocks.


Jason Honingford - Web & Software Developer
www.PortVista.com
 
New Post
7/25/2006 3:26 AM
 

about SQL connections, since all the connections would be using the same SQL Connection string, i doubt if it is not optimal. SQL should itself implement connection pooling in case connection string is identical.

i had been observing very high CPU utilization myself. I have implemented the following:

  1. Turn off all schedules by Scheduler Mode to Disabled
  2. Module caching to Disk
  3. Site log storage to File System

I have also purged my site log history manually to reduce the DB size 3 GB to 40 MB  :)

this has speeded up my site significantly.

lemme know if these things work out for you.. my experience is based on DNN 3.3.3

 

cheers

Abhishek

 
New Post
7/25/2006 4:03 AM
 
raldo wrote

Does anyone agree with this?

no, not really. we also use/ offer several dnn portals / dnn based apps. in my eyes it depends on the architecture/ the servers. however ...

raldo wrote

My opinion is that DNN needs a document that specifies clearly do's and don'ts. Things that make sites slow etc. What are reccommended hosting requirements?

yes, that would really be nice. you'r right.

 
New Post
7/25/2006 4:58 AM
 
  1. Turn off all schedules by Scheduler Mode to Disabled
  2. Module caching to Disk
  3. Site log storage to File System

ad 1) only, if you don't need them

ad 2) this is preferable, if you are in webfarm or run out of memory, otherwise it will decrease performance

ad 3) in this case, you need 3rd party tool for log analysis, as the DNN log viewer does not read log files.


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...DotNetNuke Speed - LetDotNetNuke Speed - Let's be honest


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out