Forum .LRN Q&A: Re: Help Needed in Setting up .LRN to Scale

Posted by Andrew Piskorski on
Martin, you just dumped a whole lot of info on us but I don't see the some of the most simplest and most important stuff. Do you have the OpenACS Developer Support package installed? If not, install it, right away.

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 (expensive) 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.