tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Pabst" <Simon.Pa...@web.de>
Subject Re: Re: mod_jk round robin problem & stateless session beans
Date Tue, 15 Jul 2003 09:37:51 GMT
Thanks for you wisdom guys :-)


I'll try and test if Apache 2 with worker mpm works better,
although i still suspect the stateless session beans are part of the problem.

Since like i said with sticky_session off 
or the SessionExample with sticky_session on 
the round robin seems to works fine.

Besides the behaviour of "sticky_session off" should be theoretically similar as when 
any new user logs on to the server and hasn't established a session yet, right?


The mod_jk lb_factor and lb_value also seem to do pretty nothing (on prefork Apache):
- Tested low lb_factor on first Tomcat and increased lb_factor on following Tomcats,
  last Tomcats with higher lb_factor still got no requests
- lb_value is almost always the same as lb_factor in JK2's jkstatus page
  when you access the application the lb_value changes to exactly twice as the lb_factor 
  (on first Tomcat mostly) and then goes down to value of lb_factor again 
  (before request: lb_factor 100, lb_value 100 
  after request: lb_factor 100, lb_value 200
  a bit later: lb_factor 100, lb_value 100 again)


How the Load Balanciung of mod_jk could be enhanced to be a real "load balancing", not just
round robin:
Have some rules regarding the Status/Load of Tomcat/JVM, which you can put in any order you
prefer (mod_backhand does sth. similar) (those will propably need jni or sth. else to work):
- byJVMThreads
- byJVMMemoryUsage
- byJVMCPUUsage
- byRoundRobin (and one which actually works ;-)
etc.


We considered alternative methods for load balancing too, but they all have some other downsides,
so the best thing would still be if mod_jk round robin works as its supposed to be:

- DNS Round Robin or Apache mod_rewrite Round Robin (similar sub-URLs for one app on same
server - saves you from buying several SSL certificates)
	Problems: 
	- Bookmarks
	- No real "load" balancing (ok mod_jk doesn't seem to have this either) 
	- Requests go to down Tomcats also, no failover 


- Apache Loadbalancing with mod_backhand
   Nice approach of several Load Balancing decision rules (byCPU, byApacheChilds, byRandom
etc.), which the user can put in any order he likes
   See http://www.backhand.org/mod_backhand/FAQ.shtml#question7

	Problems:
	- HTTPS Apache in Front with mod_backhand using Proxy Connections to connect to Apache/Tomcats
in back causes problems because of URL Redirects from Tomcat/Java
	- Requests go to down Tomcats also, no failover 
	- Not sure if keeping Sessions works (backhand could use JSESSIONID for sticky sessions,
have yet to test that)


- Hardware Load Balancer (dind't investigate much on that)
         Problems:   
         - IP based, read sth. that this ain't a particular good solution too




mod_jk 
"Tomcat Users List" <tomcat-user@jakarta.apache.org> schrieb am 15.07.03 07:45:11:
> 
> This is a pretty good description of what goes on, and it results in the
> highly skewed distributions that you are seeing.  I had thought that if you
> are using Apache-2 with the 'worker' MPM, that you should get a better
> distribution (but haven't tried it myself).  With Apache-1.3.x or Apache-2
> with the 'pre-fork' MPM this is as good as it gets at the moment (since the
> 'pre-forked' processes don't talk to each other).  In theory, it should be a
> relatively easy fix in Jk2 to get 'pre-fork' working, but AFAIK, it hasn't
> been implemented yet.
> 
> "NormW" <normw@bocnet.com.au> wrote in message
> news:019701c34a55$643d7250$b441ca0a@nwinc.org.au...
> > Good morning Simon.
> > 'RoundRobin' is less likely the more Tomcat's you add I suspect. The
> > balanced worker program always searches for a new worker by starting
> > pointers from 1 rather than the last successful worker used, (AFAICT), and
> > if a worker is free for the task it makes for muddy water indeed if you
> > bypass it in the hope of finding something better... You need to remember
> > which one was used 'last', which is a 'state' not remembered if/once
> session
> > ID's are used (which go to the worker that handled it the last time). If
> you
> > think about 'balancing' it is 'mindgame' to decide how a 'load' might be
> > distributed... based on session counts? based on request handling time?
> and
> > what 'integration' period would you use? ... and then there are
> preferences
> > based on load, server grunt, network traffic, background tasks...  at the
> > end of the day, the idea is to handle user requests, so if they're getting
> > processed in a 'timely' manner perhaps you can put the 'unused' Tomcat's
> > behind another Apache? ... or start a new thread here on how balancing
> might
> > be better handled in different situations...
> >
> > Another 'possible' might be to add more balance workers and split your
> url's
> > to these, in turn connected to more ajp13 workers using some of the
> Tomcat's
> > currently sitting idle.
> > Norm
> >
> >
> > ----- Original Message -----
> > From: "Simon Pabst" <simon.pabst@web.de>
> > To: <tomcat-user@jakarta.apache.org>
> > Sent: Tuesday, July 15, 2003 7:17 AM
> > Subject: mod_jk round robin problem & stateless session beans
> >
> >
> > > We have the following setup:
> > > One Apache with HTTPS/SSL with mod_jk (one load balancer, sticky
> sessions
> > > on) in front
> > > Eight Tomcats in back
> > >
> > > Round Robin doesn't work, but instead the Users are distributed on the
> > > Tomcats like this:
> > >
> > > Tomcat No.| User Count (approx. daily)
> > > T1 70
> > > T2 30
> > > T3 15
> > > T4 6
> > > T5 1
> > > T6 0
> > > T7 0
> > > T8 0
> > >
> > > This occurs both with Apache1.3.27/mod_jk1.2.x and
> Apache2.0.45/mod_jk2.x
> > > (mod_jk 1 and 2 built from source of
> jakarta-tomcat-connectors-4.1.24-src
> > > and later also of tomcat-connectors-1.1M1-src).
> > >
> > > Anyone ever experienced something similar or has any insight in this?
> > >
> > > According to the application developer the application is using
> stateless
> > > session beans.
> > > (Since i'm just a stupid server admin and no Java Programmer i don't
> > really
> > > now what that is :-)
> > >
> > > I tested the Load Balancing with the Tomcat SessionExample and round
> robin
> > > seemed to work fine.
> > > If i switch of sticky session round robin also works fine, but not the
> > > application :-)
> > >
> > > Do stateless session beans even work with mod_jk's sticky session stuff?
> > > (in this discussion
> > > http://www.theserverside.com/discussion/thread.jsp?thread_id=409
> > > somebody said:
> > > "if the application stores the stateless session bean in the
> httpsession,
> > > the application risks having all of the workload to only one of the
> nodes
> > > in the cluster")
> > >
> > > If anyone knows how sticky sessions of mod_jk(2) work, please enlighten
> me
> > :-)
> > > Is it IP based in any way, are Cookies involved or JSESSIONID or
> anything
> > else?
> > > Could it be a problem that all Tomcats are on the same machine? (i
> tested
> > > this with pseudo network addresses 127.0.0.1-8 for each Tomcat too, but
> > > didn't help either)
> > > Could HTTPS cause any troubles for this?
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > >
> > >
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 

-- 
Simon Pabst

E-Mail: Simon.Pabst@web.de


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


Mime
View raw message