Load Balance by using mod_jk + apache server2.0

1)Add following code to C:/Program Files/Apache Group/Apache2/conf/httpd.conf

# Include mod_jk configuration file

Include "C:/Program Files/Apache Group/Apache2/mod_jk/mod_jk.conf"

2)Create mod_jk.conf to C:/Program Files/Apache Group/Apache2/mod_jk/mod_jk.conf

# Load mod_jk module

# Specify the filename of the mod_jk lib

LoadModule jk_module "C:/Program Files/Apache Group/Apache2/mod_jk/mod_jk-1.2.28-httpd-2.0.52.so"

# Where to find workers.properties

JkWorkersFile "C:/Program Files/Apache Group/Apache2/mod_jk/workers.properties"

# Where to put jk logs

JkLogFile "C:\Program Files\Apache Group\Apache2\mod_jk/mod_jk.log"

JkLogLevel info

JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

JkRequestLogFormat "%w %V %T"

#Mount your webapps eg WebApplication1 using JkMount

# Add shared memory.

# This directive is present with 1.2.10 and

# later versions of mod_jk, and is needed for

# for load balancing to work properly

JkShmFile /var/log/apache2/jk.shm

JkMount /* router

<Location /router/>

JkMount router

Order deny,allow

Deny from all

Allow from 127.0.0.1

</Location>

3) Create worker.properties on C:\Program Files\Apache Group\Apache2\mod_jk\worker.properties

# The advanced router LB worker

worker.list=router

# Define a worker using ajp13

worker.worker1.port=8009

worker.worker1.host=127.0.0.1

worker.worker1.type=ajp13

worker.worker1.lbfactor=1

# Define preferred failover node for worker1

worker.worker1.redirect=worker2

# Define another worker using ajp13

worker.worker2.port=8009

worker.worker2.host=127.0.0.1

worker.worker2.type=ajp13

worker.worker2.lbfactor=1

# Disable worker2 for all requests except failover

worker.worker2.activation=disabled

# Define the LB worker

worker.router.type=lb

worker.router.balance_workers=worker1,worker2

4) Download iso mod_jk-1.2.28-httpd-2.0.52.so from http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.28/

to C:\Program Files\Apache Group\Apache2\mod_jk\

5) For sticky session

Edit tomcat's server.xml for all tomcat

Comment <!-- <Engine name="Catalina" defaultHost="localhost"> -->

Uncomment <Engine name="Standalone" defaultHost="localhost" jvmRoute="worker1">

References

Step by step - http://www.devside.net/guides/windows/tomcat

Help for worker.properties

http://tomcat.apache.org/connectors-doc/reference/workers.html

http://tomcat.apache.org/connectors-doc/generic_howto/loadbalancers.html

JSF1 RichFaces Performance Tuning

1) JSF components tree state takes big enough memory. In the server-side
state saving ( default JSF behavior ) these objects are stored in the
session. For a many concurrent user connections every user gets own
session object. Possible solution - switch to the client-side state saving.
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>

Other possible solution is Facelets behavior that allows to build view
before request processing instead of state saving, but that solution has
sometimes unpredictable side effects. Use web.xml init parameter
together with the <f:view transient="true" > attribute.
<context-param>
<param-name>facelets.BUILD_BEFORE_RESTORE</param-name>
<param-value>true</param-value>
</context-param>
As an intermediate solution, it is makes sense to create custom FaceletsViewHandler subclass with special state processing for a some pages like menus which does not depends for a saved state. That custom handler could call buildView method instead of real restoreView procedure for a such pages.
2) Facelets library in the "debug" mode stores information about
components and beans up to 5 times for an every user. To disable this mode:
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>false</param-value>
</context-param>

3) Most filters use buffering for request processing. According to the
profile information, these buffers took big enough memory in the
application. I see a buffer-related parameter in the RichFaces Ajax filter:
<init-param>
<param-name>maxRequestSize</param-name>
<param-value>100000</param-value>
</init-param>
For a production server, it makes sense to reduce value to a real page
size or remove that parameter at all.
4) TIDY xml filter is DOM-based, thus it requires a lot of memory. It
would be better to use more optimized "NONE" or "NEKO" one :
<context-param>
<param-name>org.ajax4jsf.xmlparser.ORDER</param-name>
<param-value>NONE</param-value>
</context-param>