Is Moving All Jars To a Shared lib Folder Beneficial?

by | Feb 28, 2012 | Aggregated, Developer tips |

We will be running more than one web application on the same tomcat (7.0.22), so we wondered whether there will be a benefit in moving all jars to tomcat/lib instead of having them in each application’s WEB-INF/lib (since our applications have almost identical dependencies). What this gives as benefit for sure, without even testing, is that the classes are loaded by the parent classloader, and are loaded only once, rather than by each app’s classloader.

Here are the results on my machine, with 2 applications:

Startup times (4 runs):

WEB-INF/lib
INFO: Server startup in 77554 ms
INFO: Server startup in 62391 ms
INFO: Server startup in 62598 ms
INFO: Server startup in 61002 ms

tomcat/lib
INFO: Server startup in 72321 ms
INFO: Server startup in 71151 ms
INFO: Server startup in 69841 ms
INFO: Server startup in 71047 ms

Memory (2 runs):

WEB-INF/lib
PermGen: size=278, Used=198
Heap: size=1,029, Used=465

PermGen: Size=276, Used=198
Heap: Size=1,049, USed=501

tomcat/lib
PermGen: Size=199, Used=151
Heap: size=1,043, Used=412

PermGen: Size=195, Used=151
Heap: size=1,035, Used=418

The only difference is in the used PermGen size, which differs with ~50 MB per app (size differs with ~80). (Used Heap goes up and down, hence the difference). This is without working wit the app, which would add a bit more difference, but most of our classes are loaded eagerly by the spring context. So this is not enough benefit for the deployment complications it introduces – you can no longer package your application directly from maven/ant – you have to post-process it to clear the jars, and also make sure your environments have up-to-date tomcat/lib folders.

We will be running more than one web application on the same tomcat (7.0.22), so we wondered whether there will be a benefit in moving all jars to tomcat/lib instead of having them in each application’s WEB-INF/lib (since our applications have almost identical dependencies). What this gives as benefit for sure, without even testing, is that the classes are loaded by the parent classloader, and are loaded only once, rather than by each app’s classloader.

Here are the results on my machine, with 2 applications:

Startup times (4 runs):

WEB-INF/lib
INFO: Server startup in 77554 ms
INFO: Server startup in 62391 ms
INFO: Server startup in 62598 ms
INFO: Server startup in 61002 ms

tomcat/lib
INFO: Server startup in 72321 ms
INFO: Server startup in 71151 ms
INFO: Server startup in 69841 ms
INFO: Server startup in 71047 ms

Memory (2 runs):

WEB-INF/lib
PermGen: size=278, Used=198
Heap: size=1,029, Used=465

PermGen: Size=276, Used=198
Heap: Size=1,049, USed=501

tomcat/lib
PermGen: Size=199, Used=151
Heap: size=1,043, Used=412

PermGen: Size=195, Used=151
Heap: size=1,035, Used=418

The only difference is in the used PermGen size, which differs with ~50 MB per app (size differs with ~80). (Used Heap goes up and down, hence the difference). This is without working wit the app, which would add a bit more difference, but most of our classes are loaded eagerly by the spring context. So this is not enough benefit for the deployment complications it introduces – you can no longer package your application directly from maven/ant – you have to post-process it to clear the jars, and also make sure your environments have up-to-date tomcat/lib folders.