velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florin Vancea" <fvan...@maxiq.ro>
Subject Re: Switching from PHP to Java/Velocity, Performance?
Date Thu, 13 Apr 2006 13:36:12 GMT
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" <dominik@dbruhn.de>
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: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Mime
View raw message