velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florin Vancea" <>
Subject Re: Re: Switching from PHP to Java/Velocity, Performance?
Date Thu, 13 Apr 2006 12:33:36 GMT
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

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

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.


----- Original Message ----- 
From: "Graham Renney" <>
To: "Velocity Users List" <>
Sent: Thursday, April 13, 2006 2:48 PM
Subject: RE: Re: Switching from PHP to Java/Velocity, Performance?


Just a though. If you are using a load balancer (e.g. Linux Virtual
Server) then you don't really have a cluster environment. So you don't
have to worry about the concerns listed below. There wouldn't be any
cross cluster comms in this scenario.

Graham Renney

-----Original Message-----
From: Florin Vancea []
Sent: Thursday 13 April 2006 13:40
To: Velocity Users List
Subject: OT: Re: Switching from PHP to Java/Velocity, Performance?

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

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


----- Original Message -----
From: "Dominik Bruhn" <>
To: <>
Sent: Thursday, April 13, 2006 12:43 PM
Subject: Re: Switching from PHP to Java/Velocity, Performance?

> Hy,
> thanks for all responses. As I have written PHP-Scripts for years I
> differences between writing a PHP-Script and writing a Java-Programm:
> forces you to write "better" code when PHP lefts the possibility to
> write "ugly" code. I also know the advandage of PHP: You can develop
> don't need much knowledge to start.
> My plans were to Use a VelocityViewServlet and Velocity-Templates. In
> a small layer for abstraction and Page-Handling and Permissions. As
> Database-Layer I use JDBC. I tired Hibernate but I haven't seen any
> advandages in it. I don't want to use Struts because I think its
> me. The whole Servlet runs on a Tomcat-Container.
> When talking about the ability to cluster the Servlet in future I
> about the following solution: I two or more Tomcat's on different
> Then I put a Webserver with Proxy-Support in front which distributes
> Requests over the Tomcats. This seems a quite simple and fast
> are the point I have to think of when realising such a system? Where
> facts where the people tell that PHP ist better when using clustering?
> understand this!
> Thanks
> Dominik
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

This message and any attachments are confidential and intended solely for
the addressee. If you have received this message in error, please notify
Discovery immediately, telephone number +27 11 529 2888. Any unauthorised
use; alteration or dissemination of the contents of this email is strictly
prohibited. In no event will Discovery or the sender be liable in any manner
whatsoever to any person for any loss or any direct, indirect, special or
consequential damages arising from use of this email or any linked website,
including, without limitation, from any lost profits, business interruption,
loss of programmes or other data that may be stored on any information
handling system or otherwise from any assurance that this email is virus
free even if Discovery is expressly advised of the possibility of such
damages. Discovery is an Authorised Financial Services Provider.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message