60 or More Current Anonymous Users On DNN - No Problem
6/10/2008 1:07:24 PM
What do you consider a heavily traffficated DotNetNuke site? 10, 20, even 90 current anonymous users? Our network receives over 50,000 users per day hitting the site generating hundreds of thousands of requests per day. Since this particular network is aimed at the tween set, our traffic balloons right after school hours.
What do you consider a heavily traffficated DotNetNuke
site? 10, 20, even 90 current anonymous users? Our network
receives over 50,000 users per day hitting the site generating hundreds of thousands of requests per day. Since this particular network is aimed at
the tween set, our traffic balloons right after school hours. How do you keep a large DNN site responding when under
a heavy load? The thing that is critical to high traffic applications
is SQL. You really need to understand how SQL is impacting the IO on
your SQL Server machine and make sure there are no bottlenecks. Granted
there are many issues that can impact an application getting this kind
of load, but you should start by making sure your SQL box is optimized
at its fullest. We found in this case, that many of the bottlenecks we
encountered early in the development process was IO issues on our SQL
box. Here are some things to look out for.
- TempDB - Move the tempdb onto it's own
drive if possible. We noticed some of the procedures on DNN making
heavy use of the tempdb. Make sure you move it on to it's own drive.
Also create more tempdbs. Usually about one per CPU in the machine. If
it is a multicore CPU, then 1 per each core.
- Break Out the Logs and Data - This is a given, each requires its own kind of IO access. Break them out.
- Memory - Load up on memory on the SQL box so it can cache and reduce the amount of disk IO.
- Keep an eye on it -
Make sure you watch the SQL processes and see if there are an queries
that are causing a bottleneck, It may require a better caching strategy
on DNN.
Those are just a few items to look for. Make sure to
check IO, memory, and CPU performance counters on both the web servers,
and the SQL server to see where your bottleneck may be. Sure there are others issue like cache settings, compression, but in my research SQL was the biggest bottleneck for a site like this. Don't just blame poor performance on DNN.
|