I'm not a big fan of making changes to your INI files to tune up your Domino server. Most of the time, I've seen servers in worse shape due to excessive use of everyone's favorite parameter changes. It goes without saying that there is no such thing as "RunFaster=1" -- there are not universal "always set this" parameters. If there were, they'd be set that way by default.
That said, here are a few I've found that have helped me deal with some issues lately. -- And a shout out to Gab Davis, the top Domino Admin Guru in the industry and a my good friend. She gave me the scoop on one of the ones which had the most impact, simply from me describing the problem.
MailLeaveSessionsOpen=1 ; -- I have a server that does a lot of mail transfer. This parameter tells Domino to keep the server sessions open for transfer rather than constantly and feverishly creating and destroying them. I'm still watching to see if this is making a difference for me.
These next few are in place to solve a specific problem I've been having. A database with a very large directory as well as a very later database which is constantly getting massive updates and yet must be full text indexed is causing a server to slow down and at times seem almost unavailable. The full text indexer gets so busy that the indexer can't keep up with the queue for keeping the Domino Directory indexes up to date. These parameters have really helped a great deal. While I'm working to address the root cause, these have effectively hidden the issue from users.
Update_Fulltext_Thread=1 ; -- this may be the closest thing to "runfaster" I've seen. It doesn't actually run faster of course, but it does free the View Update task to do its business while full text indexing happens on its own thread. I'm not sure I can think of a situation where this would not be a good idea.
ftg_use_sys_memory=1 ; -- this one moves the memory used by the full text indexer outside the Domino server memory pool. The documentation indicates that the memory is freed sooner when completed, and isn't as prone to being fragmented when this is used.
These next two are used in combination. The first essentially tells the server that if it can't keep up with indexing the directory, it can use the last known good index to continue to let users access the server. The second fine tunes which actually causes the server to decide it must update the directory indexes.
SERVER_NAME_LOOKUP_NO_UPDATE=1
DEBUG_ENABLE_UPDATE_FIX=8191
If you're having the kinds of issues that the server I'm referencing did, research these a bit and give them a try.
Comment Entry |
Please wait while your document is saved.
This one comes pretty damn close.
HttpQueueMethod=2
The only reason not to use it is if no web content served could take longer
than half a second. That includes view rebuilds, searches, that bit of complex
processing that takes a couple of seconds.
The more hits you make on the server the more true it becomes.
Why is it not the default? The only reason I can think of is that the default
gives you greater overall through put and so looks better or benchmarks, but it
does this at expense of real world user experience.
Oops, sorry, my pet ini settings rant button got pressed. ;)