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 ----- Original Message ----- From: "Graham Renney" <[EMAIL PROTECTED]> To: "Velocity Users List" <velocity-user@jakarta.apache.org> Sent: Thursday, April 13, 2006 2:48 PM Subject: RE: Re: Switching from PHP to Java/Velocity, Performance? Hi 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 [mailto:[EMAIL PROTECTED] 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 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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
