Is that the first access to the JSP? What are the numbers for subsequent access? And how exactly are you measuring those numbers?
It is for subsequent accesses. I am measuring them using: http://www.webpagetest.org/ you could try a variety of other online tools like that. The results are similar. Please note as mentioned if i render a flat image not through the JSP it is 50ms. Even though the bytes being transferred is higher than the JSP's simple HTML code.
1 of 1 people found this helpful
Joshua van Aalst wrote:
I am measuring them using: http://www.webpagetest.org/ you could try a variety of other online tools like that.
So basically you are testing network connectivity from some external site, hosted far far far away from your server. But not actually testing response time that your server/application can give you. So is this intentional or you just don't know any other way to test performance?
try using apache bench http://en.wikipedia.org/wiki/ApacheBench
which you can get on any linux distro by installing ab package (on rhel/fedora you can do yum install ab)
and then test your application from same machine you have it on, or at least from same network.
then try testing with
ab -n 100 -c 10 http://localhost:8080/your-page.jsp
this will issue 10 concurrent connection that will each do 100 requests.
and you will get response times from them.
ab is not perfect tool for high load testing but for basic tests like this it is great.
Normally i'd agree with you but not this time...
I have a 57kb image in the war file that you can access here: http://188.8.131.52:8082/images/TestImage.jpg . Using webpagetest.org the single image shows a rendering time of 50ms.
So i do not think it is a network connectivity issue. As the image is 5x faster than the simple jsp both in the same war on the same app server on the same box on the same network.
I will try the ApacheBench software you recommended.
Servlets, JSPs and other (real) server side resources unlike static image files obviously involve more processing. So it can potentially take time relatively more than accessing a static image.
Do you have a benchmark for the dynamic resources against which you are comparing the response times? In other words, why do you think 250ms is a bad performance? It may or may not be bad, but we need to understand the benchmark against which you are basing this.