Remember my question on "How Scalable are your Domino Apps?", well guess what? The tests were quite good. Our web app proved to scale to 140 concurrent users hammering the system. We could actually handle more users but we wanted to keep most of our response times to below 5-6 seconds for submits and less than 2-3 seconds for normal browsing (opening views, documents, etc.). So now my question for you, can we do any better without any code changes? We've contacted our current ISP to start the quote process of replacing our current xSeries 345 server with a new server(s) and I'm just curious how some of you would configure a Domino server that only was used for web apps.
From a Domino config perspective:
1. Watch your thread usage. Check out the stat Domino.Threads.Active.Peak -- trim your threads to 20% above that number. If you're hitting that number, gradually add more threads until you're "in the clear". Be careful, though - too many threads can actually degrade performance (your cpus will spend the majority of their time context switching). If you up the threads and things seem significantly slower with just you as a single user, you're seeing the hit.
2. Turn OFF DNS lookup in your HTTP server settings (it's off by default, but better safe than sorry).
3. Turn on HTTP persistent connections. If you can spare extra threads without much of a problem then consider upping your "Maximum requests over a single connection" and "Maximum requests per consistent connection" settings, too. This will let a browser pull down images, frames, etc. en-masse, resulting in a faster user experience.
4. If you're using authentication then on your Domino Web Engine tab set your maximum cached users equal to the number of active users you're expecting. This is a HUGE deal. If this is set too low then you begin forcing a group/role match lookup on occasion, and that slows things down drastically.
5. Up your design cache. The more design notes that can be cached by your web server, the better.
6. Trim your tasks. Do you need Calconn on a web-app-only server? Probably not. I usually run "lean and mean", with update, amgr, http, and maybe replica.
7. Configure the server to use another dedicated mail-only server for mail it needs to send out. A web server that spends time running the router task and delivering mail via SMTP is missing out on a lot of memory and cpu.
8. Set your HTTP cache headers, either through the Administrator controls, @SetHTTPHeader, or a DSAPI add-on.
That's about all I could rip off the top of my head in 5 minutes, but it should be a good start.
Hi Erik,
Thanks for the great info! I'll definitely look into each of these points that you bring up. We're still on R5 so a few of these we won't be able to do till we get ND6. However, it looks like you have given me more ammo to justify an upgrade.
I do have a couple of questions for you (and anyone else reading).
1. Can we gain anything with Domino partitioning?
2. Does each partition have its own CPU or do all of the partitions share the CPU(s) on the server?
3. What about memory? As I understand it, Domino running on a Windows server can only address 2GB. Is this true for all versions of the Window server? Do Domino partitions get their own 2 GB memory each or do all partitions have to share the same 2 GB?
4. What about RAID levels? From our past experience and testing, RAID 0 seems the best for raw performance on our data directory. Should we do the same for our transaction logs, view rebuilds, log files (http traffic and log.nsf).
5. Speaking of transaction logs, do you really gain any performance improvements using them? We have trans logging configuring on our current server and it is setup to use its own separate drive. We've just never tested our app with it turned off. Anyone else tested with it on and then off?
6. I've read many places to have the OS on one drive and the Domino executables on another. If you are short on the number of drive bays you have, is it ok to put them both on the same drive?
Thanks in advance for your help!
Jack
Hmmmm.... Domino's partitioning doesn't work as slick over the web as it does with Notes. There's a fair amount of discussion on it in the LDD forums. In general you'll get failover capabilities, but they may not be completely seamless.
Domino does only address 2GB (actually *slightly* over that) on all versions of Windows. Domino 7 might be different, but I doubt it. As for memory between the partitions - check the forums again. There's a lot more detail than what I can rattle off here.
RAID 0 is very fast due to the data being spread across multiple spindles, but you get no redundancy. The more disks you can devote to specific tasks, the better. A dedicated view rebuild drive is very useful, as is a dedicated transaction drive and separate log drives. If you want redundancy and speed, go RAID 1+0.
As for performance increase with transaction logs - YMMV. Some people experience almost no performance boost, some get an extra 10% of write speed, some more than that. Are you expecting lots of writes? Then you may get a speed boost. The main performance payoff for transaction logs is restarting a crashed server. Playing back transaction logs is MUCH faster than waiting for databases to consistency check.
You can have both the OS and Domino executables on separate drives, but that should be the last drive split you do. In order of priority I'd put the following on their own drives:
1. Domino data
2. View building
3. Transaction log
4. Domino executables or swap file
Thank you for the info!