Network timeout with HTTPClient and Tomcat

[Jimi Hullegård]

I'm using HTTPClient (http://www.innovation.ch/java/HTTPClient/) to test my
webapplication (Apache Tomcat), trying to simulate the load of several
simultaneous online users. Each user in an own thread, logged in with an own
session, and repetedly requests the same page 100 times in a row, with a
pauss of about one second between each request.
At the moment the program creates 17 user threads.
But I'm getting Network timeouts, and I'm not sure what is causing them.

The page requested is a very simple jsp-page, that simply prints the name of
the current user. I.e no DB access or anything.

The test code:
www.hullegard.com/java/HttpTest.java

When I run this code, all works fine for a while, but then when the threads
are at about 60
requests, several of the threads gets "java.net.ConnectException: Connection
timed out". The output from the program shows that the requests take about
2 seconds maximum and about 60ms in average, in the beginning. But then
after about 50-80 requests, the time out starts to happen, and the printouts
shows that the threads waited about 21 seconds for the response. But the
average waiting time (not counting the timeouts) are still very low (about
60-90ms). How come these sudden time outs?

The thing is, I wanted to simulate users that access my site over the
internet, so the program connects to my no-ip address (from www.no-ip.com)
instead of just localhost. When I tried localhost, I got (not surpricingly)
alot lower response times (max 40ms, in average close to 0ms), and no
timeouts.

Does this mean that the problem is no-ip.com related? Maybe they detect the
burst of connections from a single ip number, and purposly slow them down?
Or would I expect the same behaivor if these connections came from unique ip
numbers?

I know this might not be really java related, but I thought that if I asked
this question in some "network" group, they probably would have questions
about the HttpTest java program.

But to make this a little more java related:
Can anyone recommend a better way to stress test my webapplication? I have
searched the net, and found many programs. But all have either been too
complex, expensive or too limited. What I want is a way to create multiple
threads (maybe several thousands) that should simulate multiple simultaneous
online users. I prefere simple no-nonsense programs. A fancy GUI is not a
priority.

Any suggestions or ideas are very welcome!

Regards
/Jimi

 

[Chris Uppal]

Jimi Hullegård wrote:

[replying out-of-order]

Can anyone recommend a better way to stress test my webapplication? I have
searched the net, and found many programs. But all have either been too
complex, expensive or too limited. What I want is a way to create
multiple threads (maybe several thousands) that should simulate multiple
simultaneous online users.

There is no simple way to use thousands of threads -- not unless you are
willing to look for, and /pay/ for, a JVM implementation that has been
specifically designed to use lightweight threads.

However, I don't see why you /need/ thousands of threads -- your server
certainly isn't going to be capable of dealing with thousands of ongoing
requests at the same time (it may be capable of dealing with thousands of users
at the same time, but they won't all be issuing page requests simultaneously).
So you need a (much!) smaller number of threads, each of which simulates
several users. Unfortunately I don't know of any products that do that for
you -- they definitely exist, but I don't know their names.

The thing is, I wanted to simulate users that access my site over the
internet, so the program connects to my no-ip address (from www.no-ip.com)
instead of just localhost. When I tried localhost, I got (not
surpricingly) alot lower response times (max 40ms, in average close to
0ms), and no timeouts.

I don't think that the no-ip service will be having any effect here. Neither
to mess up your test, or to help it work better (more representatively). The
hostname that you use will be resolved to an IP address in /one/ DNS lookup at
no-ip.com, and will thereafter be kept in the TCP implementation's cache So
no-ip will not be involved at all after that. You could get exactly the same
effect (as far as TCP performance and/or problems are concerned) by using a
numeric IP address in your test setup (though you might need to use a "real"
hostname in the HTTP requests to make the server recognise them properly). The
IP address would not be 127.0.01 ("localhost") but the externally visible IP
address that you (also) provided to no-ip.

BTW, attempting this kind of testing with the server on the same machine as the
clients is a bad idea[*] -- for one thing, the CPU cycles that the clients
consume will not be available for the server to use, for another you are not
guaranteed to be using a real network with real network limitations (bandwidth,
latency, etc). Ideally you would have your server on one machine, and
/several/ client machines (actual, real, separate machines -- not threads)
would provide the load. If you can find a testing framework then it'll
probably include ways to simulate (on a LAN) the effects of bandwidth and
latency limitations of the real Internet.

([*] in fact probably a complete waste of time, except for testing the test --
if you see what I mean, getting the test code working before you measure
anything.)

Anyway, back to the problem. If you manage to put the server and clients on
different machines, and the problem doesn't go away, then there are a few
things to look at. The first place I'd look at is the router (or whatever)
that I presume you have sitting between your LAN and the rest of the Net.
Since you have been testing using a public-visible IP address, I assume (I may
be wrong) that it is actually the router that "owns" that address, and that it
is using NAT/PAT to forward requests from that address to your actual server
(which -- if my assumption is correct -- will have a different local address on
your LAN). If that's the way your system is set up then the problem could be
purely down to the router's performance. I'd take it out of the loop, myself,
or at least check its logs for errors.

If that isn't how your network is set up, then I can't guess from here what the
problem might be. Perhaps someone might be able to help if you provide some
more details. Come to think of it, the Apache logs might also provide some
hints.

-- chris