Forum .LRN Q&A: Re: Help Needed in Setting up .LRN to Scale
Your first order of business is to determine where and how AOLserver is spending its time, and so far I don't think you've done that. You posted your AOLserver thread settings above, good.
Now, find a particularly slow page. Hit it, and look at the Developer Support data. Very Important: Note whether or not this was the first time this thread served this page. Developer Support currently doesn't tell you this directly, so this isn't quite as simple as it could be, but by looking at the Developer Support info and/or the AOLserver log, you should be able to figure it out.
Now hit the same page again, and get it to run in a Thread which has served this same page before. Compare the Developer Support numbers between the 1st-time-in-this-thread and Nth-time hits on that page. This is key.
For all hits other than the 1st hit per thread per page, the
page should be fast. If it is not, that is interesting and
we want to know why. If only the 1st hit per thread per page
is slow, and nearly all the time is being taken up in
adp_parse_ad_conn_file, then that's normal.
That's why Don was asking you about ns_cache, etc. above. If your
cache isn't big enough, presumably the cached compiled Templating
System pages might get thrown out, and then you'd end up running the
adp_parse_ad_conn_file stuff over and over
again many times per page per thread - not good.
Yes, nsv_buckets can certainly be performance relevent, but it's very unlikely that your slow pages are being caused by mutex contention for the nsv buckets. If you want to check, make sure you have "ns_param mutexmeter 1" in "ns_section ns/threads" in your AOLserver config file, then use the AOLserver nstelemetry page to check for lock contention.