-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rendra,
On 4/8/2010 8:28 PM, cinl...@gmail.com wrote: > I stored the result bean in the http request object, NOT IN THE > SESSION OBJECT, hoping that once the result is delivered, the beans > will die with the request object since request object. They will, but if you are selecting "millions of rows" and storing them in the request, you're probably grabbing /way/ too many rows for a single page to display reasonably: you're wasting memory, network bandwidth, and CPU time to manage all that. It's no wonder your webapp doesn't scale. > Fyi, I must process and send millions of data since my customers > usually run analysis processes from 15 different tables with hundred > of thousands of data from each table. It is an analysis of 6 or more > months of manufacturing data combined with marketing, purchasing, > inventory mutations, pricing, production monitoring etc. How many rows are actually being sent back to the client? Millions, or less than that? > As what I meant by exhaustive, I went to the extent of building my > own cache scheme and it worked, the process still long, but at least > it does not kill the other user, but if two or more user doing the > same huge process at the same time it will still consume the server. That doesn't sound like a caching scheme that "works". Back to the original question: Tomcat is scaling just fine: it's allowing users to connect very quickly, while your web application is choking itself and probably the db server. There is no setting in Tomcat to make your webapp run better. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku+g7AACgkQ9CaO5/Lv0PCerwCfXELH2klREvz8jseSI72Z+cS4 a5cAoK8xqknjL8LvAyyaVHyvF6lyDyOu =0ehh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
