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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > 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" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Simon Pabst E-Mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]