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 Wed, 16 Jul 2003 16:42:40 GMT
np Norm :-)
fixing this should be possible in mod_jk2 at least,
think i'll post this at bugzilla.apache.org

Checked the user distribution on our server today and its nearly even on 
all Tomcats :o)
Thanks a lot to Bill for that hint with worker mpm.


At 07:21 16.07.2003 +1000, you wrote:
>Good morning Simon.
>Thanks for the research.
>Norm
>
>
>----- Original Message -----
>From: "Simon Pabst" <simon.pabst@web.de>
>To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
>Sent: Wednesday, July 16, 2003 3:58 AM
>Subject: Re: Re: mod_jk round robin problem & stateless session beans
>
>
> > I did a short test with Apache 2 worker mpm today and now mod_jk2 seems to
> > distribute the sessions more evenly,
> > will post more results tomorrow.
> >
> > So round robin code is broken with current mod_jk1/2 and prefork Apache
> > (1.3.27 and default Apache 2 configuration)
> > Unfortunately you can't use Apache 2 everywhere, i think it doesn't
>compile
> > with worer mpm on solaris for example.
> >
> > To install Apache 2 with worker mpm you need to build it from source and
> > use the following configure:
> > ./configure --with-mpm=worker ...
> >
> > This should be fixed so Apache 1 users get a working round robin too.
> >
> > Although i don't know much about the mod_jk(2) code, I agree to Bill, this
> > should be a relatively easy fix.
> > In jk2 there's a shared memory file at least, should be enough to store
>the
> > information about the last used worker if there's no other way.
> >
> >
> > At 11:37 15.07.2003 +0200, you wrote:
> > >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
> >
> >
> > ---------------------------------------------------------------------
> > 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


---------------------------------------------------------------------
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