Be aware that Firewalls are known to drop idle TCP conections after a certain amount of time.
We experienced a similar problem with a DB2 JDBC conection pool through a Cisco PIX. What was happening was the conections were closed by the firewall. When they were re-used, there was an added overhead until Java noticed the socket was closed, and the reconected it. We solved it through firewall configuration. Sérgio On 6/20/06, Hyatt, Gordon <[EMAIL PROTECTED]> wrote:
We had an application (with connection pooling and validation query) running on TC5.0.28 (now on TC5.5.17) connecting to MS SQL Server using the Microsoft JDBC drivers. When tomcat and the database were on the same side of the firewall performance was great (averaged < 20ms obtaining connection and 2-3s running SELECT queries). (Yes, I actually put tracing into the code that timed how long it took to acquire the connection, run the query, and transmit the data back to the client.) Once we moved the tomcat server outside the firewall (an the SQL Server stayed inside), the performance degraded horribly (7-10s to obtain connection, 15-20s to run the simple queries (select by primary key), > 30s to run the more 'complex' queries, for example SELECT id, name, description FROM single_table WHERE name LIKE '%a%';). As a test, I changed the database to PostgreSQL v8.0 (at that time it was still in beta), changed the driver, and ported the database (dropped all indices except primary key and foreign keys), the query results were dramatically different: < 500ms on any query I tried. I had 2 instanced of my app on the tomcat server, one using PostgreSQL, the other using MS SQL Server. A member of the Network Team sat with me and opened both ports (1433 and 5432) to the database machine. I even reconfigured PostgreSQL to use the same port as SQL Server, restarted tomcat, ran a set of queries using one DB then the other (shutting the first down, obviously). The timing was still as dramatically different as running on 2 different ports. I know there may have been configuration issues with the firewall that impeded the performance, but, unfortunately, that (the firewall configuration) was beyond my control. Basically, be warned: if you are running your connection to MS SQL Server (and using the Microsoft JDBC drivers) through a firewall, this MAY be one contributing factor of your poor performance. Just my $0.02. Gord -----Original Message----- From: Alex Turner [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 12:42 AM To: Tomcat Users List Subject: Re: Tomcat's scalability On 6/19/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > On 6/19/06, Biernatowski Bartosz J <[EMAIL PROTECTED]> wrote: > > I am about 90% sure the bottleneck is Tomcat or what's running on top of > > Tomcat. Application uses JDBC queries to MS SQL server > > Chips are Intel Xeon. My monitoring data: > > Memory utilization under 30%, CPU under 10%. Using hardcore performance > > tools and systematic approach. > > The bottom line is that Tomcat/my application combo don't seem to handle > > more than a certain number of users. All I want to do is to up the # of > > users by 3. > > Sounds like your db connection pool is the problem. Maybe you should > check whether you have enough connections in the connection pool. Connection pooling, ahh yes. This is also a likely problem if you aren't doing any. > > > So far it sounds that the approach of adding separate instance of Tomcat > and > > using round robin is better than adding a separate JVM. > I think both options are equal. How do you plan to run a separate > tomcat in the same JVM? Both options are equaly stupid. Putting multiple intances of tomcat on a single box is pretty worthless unless you have serious application problems. Tomcat is multi-threaded, and will by nature utilize a multi-CPU setup. If you ask me (and hey, we have thousands of concurrent users and a > lot more requests) you need a monitoring tool for your application > inside your application not just vmstat or top. You need to know which > servlet/action/whatever your presentation layer is takes the time and > trace it down in the persistence. Everything else is just kindergarten > :-) > > > > > > > > BJ Biernatowski > > Application Developer, e-Business > > Leon > > > > > -----Original Message----- > > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > > Sent: Monday, June 19, 2006 10:49 AM > > To: Tomcat Users List > > Subject: Re: Tomcat's scalability > > > > are you sure that tomcat is your bottleneck? > > Your 4 CPU machine (which cpu's btw?) should be able to handle more > > than 1000 users (unless you are speaking about suns cpu) without > > problems. Maybe you should provide more info about your application. > > Do you have any monitoring data? > > > > Leon > > > > On 6/19/06, Biernatowski Bartosz J <[EMAIL PROTECTED]> > wrote: > > > Hello, > > > I was hoping somebody on the list might point me in the right > direction... > > > > > > I am trying to scale up Tomcat based web application currently > supporting > > > ~100 users to 350 users. > > > > > > It seems that I have enough hardware: 2 load balanced servers x 4 CPUs > > each > > > with 4 GB of RAM which is underutilized for most of the time even > though > > > application performance slows dramatically at peak times. > > > > > > I was advised to install multiple JVMs in order to improve Tomcat's > > > performance. Another option I considered was to install 2 instances > > > of Tomcat on each server to see whether it would handle increased > load. > > > > > > Would anybody know what kind of performance improvement would multiple > > > JVM/Tomcat installations provide? Are there any benchmarks available? > > > > > > Thank you for any help! > > > BJ > > > > > > BJ Biernatowski > > > Application Developer > > > > > > This e-mail, including attachments, may include confidential and/or > > proprietary information, and may be used only by the person or entity to > > which it is addressed. If the reader of this e-mail is not the intended > > recipient or his or her authorized agent, the reader is hereby notified > that > > any dissemination, distribution or copying of this e-mail, including its > > contents and attachments, is prohibited. If you have received this > e-mail in > > error, please notify the sender by a "reply to sender only" message and > > delete this e-mail immediately and destroy all electronic and hard > copies of > > the communication, including attachments. > > > > > > > > > --------------------------------------------------------------------- > > > To start a new topic, e-mail: users@tomcat.apache.org > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity to > which it is addressed. If the reader of this e-mail is not the intended > recipient or his or her authorized agent, the reader is hereby notified that > any dissemination, distribution or copying of this e-mail, including its > contents and attachments, is prohibited. If you have received this e-mail in > error, please notify the sender by a "reply to sender only" message and > delete this e-mail immediately and destroy all electronic and hard copies of > the communication, including attachments. > > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
