----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
Cott Lang wrote:
>
>
> I have no idea what you're replying to.
>
> ...
>
> Apache times out on the JServ after 300 seconds, which is plenty of time
> for hundreds (thousands?) of requests to all pile up on a locked Jserv.
>
Say we have an apache server that can only handle one request at a time
and a JServ VM with a pool capacity of 50. As you mention, apache times
out on JServ after 300 seconds, so if JServ performs an excruciating
computation freezes all the time, our apache server could only handle 1
request every 300 seconds, and JServ would only have one thread serving
that 1 request. So we reduce the apache timeout to 30, but expect the
same JServ performance. The result will be, given the same 300 second
timeslice, apache timing out 10 times, and JServ having 10 threads
spinning on the excrutiating computation. Since we want our apache
server to handle as many requests as possible, we reduce the timeout to
5 seconds. The result will be, given the 300 second timeslice again, 50
apache timeouts and 10 'jserv busy' errors, with the maximum JServ pool
capacity reached.
Now we can amplify the effects of that one apache thread by however many
you expect to run apache with. Because apache timeouts in no way, shape,
or form, influence JServ connection/thread activity, the correct
adjustment on the apache side actually exascerbates the scalability
problem on the JServ side.
> >if the resource is frozen waiting on a JDBC response, at least the
> >thread is in an efficient wait state. (OK that's a minor one)
>
> Irrelevant if all threads hit this wait state and you end up with 5,000
> threads.
Yes, exactly. You don't want to reach 5,000 connections. And you
shouldn't have to *if* you could kill JServ connections whenever apache
times out the client connections.
> >if you decide to dump content at the end of jserv processing rather than
> >streaming it out, you have an architectural issue impacting scalability.
> >This is precisely the problem the Cocoon group was facing with their
> >first version. Essentially, they would read in a dataset and then send
> >the result (there was a transformation in between, but this is the basic
> >sequence). They have since moved to a more streamed approach with great
> >results for scalability.
>
> What was the scalability problem - using too much memory storing
> up the response? increased response time?
>
Correct on both counts.
John Milan
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
