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.
