velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florin Vancea" <fvan...@maxiq.ro>
Subject OT: Re: Switching from PHP to Java/Velocity, Performance?
Date Thu, 13 Apr 2006 11:40:01 GMT
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

----- Original Message ----- 
From: "Dominik Bruhn" <dominik@dbruhn.de>
To: <velocity-user@jakarta.apache.org>
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 know
the
> differences between writing a PHP-Script and writing a Java-Programm: Java
> 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 fast
and
> don't need much knowledge to start.
>
> My plans were to Use a VelocityViewServlet and Velocity-Templates. In
between
> 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 useless
for
> me. The whole Servlet runs on a Tomcat-Container.
>
> When talking about the ability to cluster the Servlet in future I thought
> about the following solution: I two or more Tomcat's on different servers.
> Then I put a Webserver with Proxy-Support in front which distributes the
> Requests over the Tomcats. This seems a quite simple and fast solution.
What
> are the point I have to think of when realising such a system? Where are
the
> facts where the people tell that PHP ist better when using clustering? I
cant
> understand this!
>
>
> Thanks
> Dominik
>
> ---------------------------------------------------------------------
> 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