On 30/03/07, Tatu Saloranta <[EMAIL PROTECTED]> wrote:
--- Paul Fremantle <[EMAIL PROTECTED]> wrote:
> I've tried JMeter in the past, but its not very fast
> itself, so
> typically it requires a much bigger machine that the
> server, or a
> network of clients to work effectively. We'll take a
> look at the
> benchmark clients you posted though.
I'm glad I'm not the only one with such experiences.
Service I tried to test has peak rate of above 2k per
second, and testable using simple load testing client
(on top of HttpClient, or even Sun's default http
connection). But via JMeter I could never get over
about 250 per second, on a reasonably new desktop.
I've just tried a very simple test with 30 threads doing a GET https:
against Tomcat running on the same laptop (dual-core), and I got over
1000 requests per second.
This was with the current nightly build of JMeter; JMeter 2.2 has some
problems with SSL support which can cause unnecessary errors to be
logged, especially against self-signed certs. I don't have a real SSL
site that I can subject to huge loads.
But what I was wondering was what exactly causes such
overhead... ie. is it due to design (really meant for
low-to-medium request rates), implementation problems,
or just overhead from visualization components.
Yes, Listeners are expensive - especially the ones which need to save
every sample.
Has anyone had better luck in getting higher
throughput rates from JMeter? Any specific tuning,
settings that might help? I know that this is more a
JMeter question, but given that this seems to affect
generic XML-over-HTTP requests, which usually use
HttpClient, I hope it's somewhat relevant question
Using non-GUI mode reduces the resource requirements considerably.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
