Do you _need_ several tomcat instances? Modern machines are _very_ powerful. My advice would be really understand your software architecture so you can keep it simple and well tuned. I don't mean hand optimising just taking advantage of various levels of cache in an elegant way.
The level of complexity goes through the roof when you start trying to distribute your workload across multiple boxes and at the same time effeciency hits the floor. If you don't have a budget then a protocol aware router would be a better way to go but you get into horrible issues of session affinity and failover etc and I've found even expensive solutions (like arrow point - couldn't cope with HTTP/1.1) to be buggy. Having a well filled hibernate cache, putting version number and never expires for static content, avoiding trips to db etc etc will buy you a lot of headroom. If you want uptime more than throughput spend more on good hosting and hardware. If you do a complex deployment on a budget blown PSUs and brain dead ISPs turning off routers will hurt your downtime more. Think about your boss ringing you on a friday night when it is your partners birthday saying that the website is "slow". How much stuff do you want to have to debug? Which set of servers was he using was the problem in apache or jk or tomcat or your code or wicket or spring or hibernate or terracotta or postgres or linux or network or JVM...? beam wrote: > > Thank you very much! > But if I use several tomcat's instances then I still need some load > balancing server, like apache with mod_jk, so why don't use it for content > delivery too ? Or do I need to investigate another load balancing > mechanism? > > > Sam Hough wrote: >> >> [serving static content] >> The argument I heard was that Java apps were not able to cope as well >> with badly behaved clients (dropped connections etc). Apache httpd >> probably is more efficient than Tomcat etc at serving static content. >> However modern cheap hardware can almost always shove out more than most >> connections can cope with. If you want to manipulate, control access etc >> to your static content and your app is in Java I would be tempted to stay >> with pure Java. You also have less to worry about which bit of your >> platform is causing trouble. Tomcat also has a native plugin that you >> might want to investigate... I would guess that careful tuning of what >> you serve (compression, cache management) will buy you a lot. >> >> > > -- View this message in context: http://www.nabble.com/Wicket-%2B-Hibernate-%2B-Spring-%2B-Terracotta-%2B-Tomcat-%2B-Apache-tf4528720.html#a12936536 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
