That's the cache problem. But...
After reading your message I quickly googled "ehcache distributed cache", expecting to find the old news that ehcache (Hibernate's native cache) is not distributed and hoping to find some pointers to others that are. Now surprisingly good news is that ehcache 1.2 _is_ distributed-aware. Correlated with Tomcat's availability for clustering it removes all the issues discussed. I would then go for - a load balancer - (several Apaches as frontend for plain files, if really needed) - several Tomcat instances in cluster configuration - Velocity (without Struts if you like) - Hibernate with newest ehcache - one DB backend (or clustered if you like :) ....) - great care with transactions (if required) Now _that_ would be a nice setup to work at.... But again, I'm a Java guy and there may be a PHP solution as well...... Hey, what?! This is a Java list! Go the Java way! :) Good luck, Florin ----- Original Message ----- From: "Dominik Bruhn" <[EMAIL PROTECTED]> To: "Velocity Users List" <velocity-user@jakarta.apache.org> Sent: Thursday, April 13, 2006 3:44 PM Subject: Re: Switching from PHP to Java/Velocity, Performance? > Hy, > thats a fact i was aware of. Thats why I save the userid and the hash of the > password in a cookie for logged in Users. Uppon every request I check this > data. To save a databasequery to the user-table to check the data I save this > data in a HashMap. When there is a entry for the user in this table the data > is checked against the cache, if it not exists there a query of the database > is issued and the result is saved in the Cache. I think this produces no > problem as long as you never change the userdata. Because if, let say, the > user changes his password I have to change/clear the cash on ALL servers and > this might become difficult. > > I found a solution to the whole problem, but I think its quite exotic and I > never heard of any experiences. There is Soution called MemCacheD. Its a > daemon running on a single machine. Via network you can put data in this > cache or retrieve it. I could save the HashMap with the User-Data not in each > servlet but on this cache-server. Im not sure but I think this costs some > time because it is going over network. And when I loose the performance gain > becaus of the network-delay I could also direct access the database, there > might not be a great difference. > > Has anybody tested memchached in a servlet? I know WikiPedia uses it, but > these are PHP Scripts. > > Greetings > TO > > > Am Thursday 13 April 2006 14:33 schrieb Florin Vancea: > > Unfortunately the problem lies at a higher level. > > > > If there is no state associated with the user (request), all is fine. > > If there _is_ state associated with a particular user (i.e. you do some > > sort of "login" or you "remember" the user's path through the application, > > or something like that) then you have to store this state between user's > > requests and to reload the proper state upon receival of a new request from > > the same user. Then you have a session established with the user. > > This is done usually with session cookies but there are some other > > techniques. > > > > When you have a single machine, the session data is stored in the memory > > (for speed) and there's no problem to retrieve it on subsequent requests. > > When you have several machines the following scenario may apply: > > - user makes initial request and establishes session with machine A. > > Machine A creates and stores (somewhere) the session (state) info. > > - user comes back with the second request and the load balancer decides to > > handle the request to machine B. Now machine B must get somehow the session > > data created by machine A, in order to respond stateful to this request. > > > > And here it gets complicated. > > - Machine B may obtain the session data from machine A (by some > > broadcast-and-intercom mechanism) > > - Machine B may obtain the session data from a central repository > > (eventually a database) where it was stored by machine A in the first place > > - there may be other options that I am not aware of, or variations of the > > above > > > > Unless the load balancer does the balancing session-wise, there is a > > non-trivial problem. > > > > And the cache issue still remains, in any case, independently of the > > session issue. Think about Dominik's example, which is really good. > > > > Sorry for restating the obvious and for OT. > > > > Florin > > > > --------------------------------------------------------------------- > 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]
