velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Bruhn <>
Subject Re: Switching from PHP to Java/Velocity, Performance?
Date Thu, 13 Apr 2006 12:44:26 GMT
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.


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:
For additional commands, e-mail:

View raw message