To me, one of the big problems is that the main install includes too many modules that most people never use. In asp.net 1.1 at least, every time an app starts (i.e. first time you browse to a site after a timeout), it has to go through every DLL and compile/load it...

A minute for first browse is definitely on the slow side, it should be more around 10 seconds, I would guess your machine doesn't have sufficient resources. But something that should help is to remove all modules not being used.

The core team really needs to consider having the base install install a small subset of modules and then adding a screen that makes it easy to install additional core modules that are in a directory waiting to go (rather than having to out, find PAs and upload them). This is what is done in Joomla and other PHP based frameworks I've used.

There should probably also be a "kitchen sink" build that installs all modules from the get go, but that doesn't make sense for most installs.

---

David O'Leary
Efficion Consulting

I would interested to hear if someone did that what the actual difference was.  I would guess it's pretty small.

 

mj

---

Michael Jackson
Brillnat.com
Custom module development
Database access tokenized HTML modules

You guys are going off in all directions in how you discuss this. Caching isn't really the answer, since the data being served is no longer ever live. Some modules by nature will not function with caching on.

As I stated in another post, the main problem is that 100's of connections are opening and closing the database when just ONE person makes ONE request to your DNN site.

If the app pool recycling is a problem for you, then most likely you don't have enough traffic coming to your website to even warrant HAVING a website in the first place! lol! This is a .NET thing, and having fewer DLL's in your bin does speed up the load time dramatically yes.

---

Jason Honingford - Web & Software Developer
www.PortVista.com