tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <m...@filip.net>
Subject RE: Tomcat throws 302 errors over load - clustering test
Date Fri, 02 May 2003 15:22:36 GMT
I'm I am always accessing /mywebapp/index.jsp why should I get 302 the
requested resource has moved temporarily. And yes, this does only occur when
you put some load on the servers, because the JSP does not issue a 302
sendRedirect.

Since it is a redirect, I don't count this as a error, instead my test
client submits the exact same request again.

Re:Java load balancer,
this solution is extremely simple, and uses two threads per client socket
instead of java.nio. When putting a lot of load, the context switching in
this process is so high that takes forever. the C load balancer simple
performs better, and I believe it would even if I optimized the Java LB.

The test client is running HTTP1.0, ie, a new connection for each request
hence the LB will redirect to different servers each time, there is no
stickyness configured what so ever.

I have also noticed that running Apache/mod_jk in front of Tomcat, causes
session replication to fail pretty frequently, I will investigate more.

Filip

> -----Original Message-----
> From: Remy Maucherat [mailto:remm@apache.org]
> Sent: Thursday, May 01, 2003 11:27 PM
> To: Tomcat Developers List
> Subject: Re: Tomcat throws 302 errors over load - clustering test
>
>
> Filip Hanik wrote:
> > running the same test with a native C load balancer, the
> average response
> > time went from 4.5seconds to 1.9seconds.
>
> I don't understand what you really tested, or what you mean by getting
> 302. 302 is a redirect, why does it indicate an error ? And why would
> you get more 302s under load ?
>
> You had a Java LB in front of the two servers ? Just switching to a
> native LB improves performance, then ? But does it have any stickiness
> policy configurable ?
>
> Remy
>
> >>hi all,
> >>I recently performed a load test on the clustering solution for
> >>tomcat 4.1.x
> >>(http://cvs.apache.org/~fhanik/)
> >>
> >>If my unit test is correct, I received 0 replication errors,
> >>however tomcat
> >>keeps throwing 302 errors during overload. For those who are
> >>interested all
> >>the stats are below,
> >>
> >>Even if I run my test against a single tomcat server, I still
> receive the
> >>302 errors indicating that this is not a replication error. So in
> >>case of a
> >>302 I just resubmit the request once more.
> >>
> >>The test WAR and client are available upon request.
> >>
> >>
> >>Setup
> >>Linux Redhat 7.2, 512MB RAM, 800Mhz P3
> >>- 2x Tomcat 4.1.24 (C,D)
> >>- HTTP Loadbalancer
> >>
> >>Win XP Home, 512MB RAM, 2.4GHz P4
> >>- 2x Tomcat 4.1.24 (A,B)
> >>- Replication test client
> >>
> >>Network
> >>- 100Mbs LAN
> >>
> >>Test
> >>- 120 concurrent connections (keep-alive=false)
> >>- Round robin for each request
> >>- 100ms between each consecutive request (each connection sleeps
> >>100ms when
> >>one request is finished)
> >>
> >>Client statistics:
> >>Thread count=120
> >>        Average response time=4434ms
> >>        for 600000 requests.
> >>        Nr of replication errors=0
> >>        Nr of 302 errors=18257
> >>
> >>
> >>Win XP Statistics (server B):
> >>[InMemoryReplicationManager] Replication Statistics
> >>        Messages sent=116292
> >>        Message serialization time=94067ms
> >>        Average serialization time=0.80888623ms
> >>        Average session send  size=1808.64bytes
> >>        Messages received=465114
> >>        Message deserialization time=1816989
> >>        Average deserialization time=3.9065454ms
> >>
> >>Linux Statistics (Server D):
> >>[InMemoryReplicationManager] Replication Statistics
> >>        Messages sent=232578
> >>        Message serialization time=625110ms
> >>        Average serialization time=2.6877434ms
> >>        Average session send  size=1803.0104bytes
> >>        Messages received=348859
> >>        Message deserialization time=4482228ms
> >>        Average deserialization time=12.848251ms
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message