velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dykman <>
Subject Re: Issue with Velocity
Date Mon, 01 Nov 2004 22:36:12 GMT
On Mon, 2004-11-01 at 10:50, Amitabh Prasad wrote:
> Hi, 
> We are using Velocity in combination with Struts for generating view layer 
> in our application. 
> The basic flow of the application is some-what like this.... 
> 1)User action is handled by Struts Action Handler, and based on the 
> request we get data from different application layer which contain 
> business logic, once the data is fetched , the entire data is encapsulated 
> in the request object and passed to appropriate jsp page. 
> At that point we call Velocity macro for generating appropriate page. 
> We are getting some very serious scalability issues, after some no of 
> users the velocity macro which normally takes 200 odd milliseconds to 
> generate view starts takeing any where between 10-35 and even 40 seconds 
> for the same process, 
> I am not sure the reason behind that. 
> I also like to ensure that, there is no call to DataBase or File system 
> from Velocity, once it is called all the required data is in memory. 
> Also all the locale specific data is read from the properties files and 
> stored in Hashtable,  for any given call to generate view we refer thie 
> Hashtable abot 1000 times , do you think this can be the reason of delay 
> after say X no of users ? 
> A berief description about application and machine configuration where we 
> are running the tests... 
> This is very data intensive application, and a given page > 300KB 
> 182 no of user 
> 4 -way IBM P-Series machine which have 16 GB RAM but dedicated WebSphere 
> is 1 GB. 
> Any suggestion in this regard will be highly appreciated. 
> Thanks & Regards 
> Amitabh 

My first thought is that this might not be a Velocity problem.. 
 Depending on what value of X as in X users might be, having many copies
of a hashtable with large(?) items might be pushing you into swap space,
having run out of available RAM.  Or one synchronized hashtable being
accessed simultaneously by multiple threads could land you in an access
contention space.

I would want to watch your memory and swap/space usage during these peak
times and look at the hashtable (and size of other objects being passed
to Velocity) before I decided any particular component is at fault.
 - michael dykman

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

View raw message