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

Collapse
36: Re: Help Needed in Setting up .LRN to Scale (response to 1)
Posted by Nima Mazloumi on 04/08/04 06:44 PM
The differences I have seen to my installation so far:

1. sample request info:
It says 2215 ms for request duration, 2146.0 ms for the /dotlrn/www/index.adp page with a total of 704 ms for database stuff.

Mannheim:
49 database commands totalling 677 ms
page served in 1091 ms

Question: The database stuff seems equivalent. So where is the 1sec loss in Heidelberg?

2. config.tcl

Should be the problem since as far as I know at present you don't have many active connections anyway:

Heidelberg:
ns_param  maxconnections    5
ns_param  maxdropped        0
ns_param  maxthreads        5
ns_param  minthreads        5

Mannheim:
ns_param  maxconnections    100
ns_param  maxdropped        0
ns_param  maxthreads        50
ns_param  minthreads        50
ns_param  threadtimeout      3600

Database settings:

Heidelberg (3 x)
ns_param  connections        5

Mannheim (3 x)
ns_param  connections        10

3. authentication, kernel and main site parameter settings
I don't know yet. Just wanted to compare all of them. Can you save the html pages and send them to me? I will convert them and post it for you (leaving away the heidelberg info stuff) - if you like.

4. authorities
I had performance changes with multiple authorities enabled. Just give it a try.

Collapse
37: Re: Help Needed in Setting up .LRN to Scale (response to 36)
Posted by Janine Ohmer on 04/08/04 08:03 PM
Where did the extra time go?  Good question!  I just ran the same login again, and this time it looks like this:

+57.1 ms: Applied transformation from /web/product/www / dotlrn/index -> ? - 7.7 ms
+71.2 ms: Served file /web/product/packages/dotlrn/www/index.adp with adp_parse_ad_conn_file - 2937.4 ms
+3010.5 ms: Applied GET filter: (for /dotlrn/index ds_trace_filter) - 10.5 ms
returned filter_ok

So it's even slower this time, but the time spent in the database is still only 651 ms, 53 ms *less* than last time even though the overall time is roughly 800 ms longer.

The difference is all in serving the file, but there's nothing here to tell us why or how it took so much longer.  I imagine that's where the difference is between our numbers and yours, too.

Hmm. Will have to think about this.  Of course, if my hypothesis is correct and the system is out of RAM, then *everything* will be running somewhat slowly, so it's still possible that this is the problem, that nsd is just puttering along.

As far as the connections go, ideally those numbers would be increased but I don't think this system can handle any more connections, so I think it best to leave that as-is until we figure out the problem.

i will get back to you on the other questions.