I will have a load balancer in front of my webservers. A fault tolerant system is not yet requested, so at the moment I do not care about session replication. We expect a number of 50000 users of the system in total, as concurrent connections we expect in the worst case a maximum of 5000. The pages as I already said are mainly static but with a few dynamic ones (i.e. jsp-pages) inbetween. These pages are grouped into modules, whereby the size of each module may vary between 10-50 MB of static data. All modules together are currently 4-5GB in size but are expected to grow in the future. Via the upload/remove form I need it mhas to be possible to remove single modules and to upload new modules. I do not need to exchange single files yet.
Bjoern > -----Ursprüngliche Nachricht----- > Von: Bruno Georges [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 23. November 2005 23:01 > An: Tomcat Users List > Betreff: Re: Where should I store my static content in a > clustered environment > > 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]
