You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Amitabh Prasad <am...@us.ibm.com> on 2004/11/01 16:50:48 UTC

Issue with Velocity

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 

Re: Issue with Velocity

Posted by Michael Dykman <mi...@dykman.org>.
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
 - michael@dykman.org


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org