velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Bruhn <domi...@dbruhn.de>
Subject Re: OT: Re: Switching from PHP to Java/Velocity, Performance?
Date Thu, 13 Apr 2006 11:56:19 GMT
Hy,
im not sure when I'll need the second Webserver but the site grows and grows 
and there will be one point when the current setup wont be enough. The 
question is: when.

From your thought I think I can imagine why they tell you can cluster PHP 
better: As every request is running on its own there is no problem in keeping 
the data between the servers in sync because they all got the same and only 
data-backend.

For example I planed to cache all the boards and their permissions in the 
right order in a hashmap in the servlet. So I load it once which takes some 
time and then access it direct from a variable without a single Data-Query. 
At some time I have to change the data in the cash (last thread created, 
count of posts). When there is only one instance on one server this is not a 
problem, i simply change the values. But, if there are many servers I have to 
send a message to all servers: "Hey, something change, change the Counter to 
xxx". I don't know how to do this and It might cost some performance. 

Of course I load this HashMap uppon every request, but then all the saving 
from caching would have been gone.

Thanks
TO


Am Thursday 13 April 2006 13:40 schrieb Florin Vancea:
> Hi Dominik,
>
> Just some thoughts:
>
> - as said many times before here (on the list) properly used Velocity is
> fast enough to be the least of your worries. The main advantage comes from
> the clean separation between the logic and the presentation.
>
> - to us, using Hibernate amounted (in the long run) to clearer code and
> tighter logic due to the higher abstractisation of the entities
> manipulated. Of course JDBC would work, but as soon as the complexity
> grows, you may want a layer that shields you from it. It's the same
> "better"/"ugly" issue.
>
> - clustering will bring you issues with session portability and will impact
> usable caching policies. If you need transactions then it can get really
> ugly. See below.
>
> - session portability: I recall seeing somewhere a solution that claimed to
> achieve good performance by serializing the common objects (like session
> objects) in a single MySQL database and retrieving them each time when
> needed by a PHP processor (where there may be several PHP processors to
> carry the load). Tomcat is capable of working in clusters (and I believe
> that it also serializes session objects to do that) but passing them around
> between cluster members may not be via a database (which should be a good
> thing).
>
> - caching: Caching ability (and good cache tuning) can be a great help on
> performance when using Hibernate. And very easy to setup, too. However,
> when clustered, proper caching is more difficult and any implementation may
> drastically reduce the efficiency of caching, so you're back to square one.
>
> - transactions: Handling transactions (even explicit ones) are easy or
> rather easy on a single-noded-Hibernate. If going clustered _everything_
> gets more complicated.
>
> In short: are you really sure you'll need clustering? Wouldn't just a good
> tune-up and a good machine do the trick?
>
> Please note that I never got to set up a real clustered system - our apps
> are luckily not that heavy loaded - so take my opinions with a grain of
> salt.
>
> Florin

---------------------------------------------------------------------
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