Bjoern Do you need some sort of fault tolerant system? Can you clarify the requierments you have, do you need load balancing, session sync replication, async replication? Traffic, SLA, concurrent connections, ...
All these will have an impact on the choice and design of your infrastructure. Cheers Bruno Georges Glencore International AG Tel. +41 41 709 3204 Fax +41 41 709 3000 ----- Original Message ----- From: "Duan, Nick" [EMAIL PROTECTED] Sent: 23.11.2005 21:21 To: "Tomcat Users List" <users@tomcat.apache.org> Subject: RE: Where should I store my static content in a clustered environment A simple solution would be to have all static pages hosted on an Apache httpd server in front of tomcat clusters. If you need more performance, just cluster the httpds. Tomcat is not really designed to server static pages. Apache httpd can also serve as a LB. In this case, certainly you have to treat static pages separately from dynamic webapps. In other words, you can't bundle static pages with your war files. ND -----Original Message----- From: Eickvonder Bjoern [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 23, 2005 4:23 AM To: users@tomcat.apache.org Subject: Where should I store my static content in a clustered environment Hi, lets start with describing my current task where I would appreciate any advice from you. I have to construct a clustered system (with lots of webservers) that has few dynamic pages but a lot of static ones, whereby all resources have to be protected by security-constraints of a webapp (so letting Apache deliver this content won't work). Moreover there should be the possibility to upload/delete static components via a web form. My main problem is now where should I store the static data (mainly html pages, images, ...; but over 4 GB(!) large in total)? As far as now I'm considering the following solutions: 1.) Storing the content within the webapp of each webserver. This would include that the servers know each other as the upload/delete operations must be propagated from one server to all the others. Moreover the update of the dynamic parts would not be as easy any more as just uploading a new war-file as this requires deleting the old webapp directory (that contains the content is this case as well). 2.) Storing the content in a separate directory but still on each webserver. This would still include that servers must know each other, but updating the dynamic part would be easier. The downside is that I would have to write a servlet that delivers all static content with all the problems of mime-types, character encoding and so on which I would have to handle myself. 3.) Storing the content in a database on a separate server. The advantage would be that webservers only need to know their database server and updating the webapps would be easy (just uploading new war-files). The downside here is that I need a servlet too and I think it's maybe not the fastest solution as all requests of all servers to each single chuck of static content would require a connection to the database server. 4.) As 3.) but storing data on a single separate server in the filesystem. The advantages/disadvantages should be similar to 3.) whereby I do not know which solution might be faster. 5.) As 3.)/4.) but additionally implementing a caching-mechanism on the webservers. This means if a webserver gets a request for a specific page for the first time he connects the database server to retrieve that page, then stores it in its webapp directory and then let tomcat deliver that page. On the second request it is just checked if that page is already there and if so it is delivered directly. Of course I must implement some mechanism such that the webservers get to know if their cached data is outdated but so far this seems to me the best solution. Anyone ever faced this kind of problem? Any kind of remark to my possible solutions or any other possibilities you might know of are appreciated. Thanks you in advance for your help. Bjoern --------------------------------------------------------------------- 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] LEGAL DISCLAIMER. The contents of this e-mail and any attachments are strictly confidential and they may not be used or disclosed by someone who is not a named recipient. If you have received this email in error please notify the sender by replying to this email inserting the word "misdirected" as the message and delete this e-mail from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
