> Sorry if I missed it, early on in the thread, but what
> servlets etc are you
> testing the configurations with? In order to assess the
> performance of the
> engine, you should be using simple, easily analysed servlets, doing a
> minimum of functionality. Say, a snoop servlet, a session servlet, and
> similar in JSP. If you're testing the whole app you've
> written, the engine
> may be a small part of the performance overhead, ie if a
> request in 3.1
> takes 50ms, and the servlet takes 500ms to produce the
> content, moving to
> 3.2 which *may* give 25ms for a similar call, will not
> actually produce a
> large apparent gain in performance.
Whereas I appreciate that theory, that does not quite seem to be the case.
We time certain of the methods in our API internally and then check the
results also at the client side. Whereas I would expect more minor gains at
the client side for precisely the reason you have identified, the timing of
the API call is basically timing the performance of a request coming to the
servlet, being processed in the servlet (a fairly short execution) and being
returned from the servlet. For example, I can demonstrate that turning off
the reloadable flag dropped timing results for certain API calls from about
200 ms down to about 45 ms (just picking some ballpark figures). I can show
that the same timings dropped down to about 35 ms if you had JRE 1.3 running
in place of 1.2.2. But the change of 3.1 to 3.2 produced almost negligible
differences as did the change from mod_jserv to mod_jk.
Now, I am working as part of a test team. The stress we're placing on the
system using multiple clients forming and dropping connections as fast as
they can while only executing perhaps 1 API call in between (and these are
powerful test platform systems running a java based test tool which can
spool up many connections at once) is apparently heavy. Now, since I can't
quite quantify the number of connections/sec (mostly because I don't have
the data), I suppose you can argue we're not hitting the load-extents at
which JK with AJP13 or 3.2 might show their true colours. If this is so,
then ultimately (as far as we're concerned, given we're trafficking the
system heavily to our perspective) the performance gains from 3.1 --> 3.2 or
from mod_jserv to mod_jk with AJP13 aren't useful to us because they don't
affect the load region we appear to be working in.
But it is a good point and well worth considering.
> What kind of load are you running? The pool tcp connectors
> will only really benefit high volume hits, again you're saving the time to
construct an object and garbage it, with only having to synch and do a stack
pop.
I would have thought so. But does anyone have any data to quantify what
number of connections per sec would be necessary to call this advantage
noticeable? <Of course, I bet the answer to that would involve specifying a
system setup too... because more powerful computers probably make mod_jserv
and the SimpleTcpCOnnector look good>.
> If you've a lot of classes, reload=false will be a big
> benefit. Again, if you're running a lot of code, jdk 1.3 will benefit your
app
> and the engine.
>
> Please supply more info on how you're testing this.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
