You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "aelgamal ," <ae...@asset.com.eg> on 2008/11/14 17:07:29 UTC
RE: failure notice
Dears,
. A Servlet deployed on tomcat 5
. The Servlet connects to a database (Oracle 10 g) to perform a DML statement
. A lookup to a Data source was performed once
. I used the data source to open a connection to the database for each new request and close the connection by the end of the request.
The above scenario resulted in very poor scalability during the stress
testing. When the average response time for 1 thread was x msec, the average
response time for 2 threads was 2x and 3 threads was 3x and so on.
When I created a pool of connections (15 connections) in the Servlet and
kept the connections of this pool alive the scalability improved. The
average response time for a 150 concurrent threads was slightly higher than
the average response time for 1 thread.
Please advice why the poor performance when I used tomcat data source.
Best regards
RE: failure notice
Posted by Martin Gainty <mg...@hotmail.com>.
I dont know if anyone can provide an intelligent answer unless we know
which DBCP (the pool acts as a factory to create n number of connections) you are using / how it is configured and
which Driver classes you are using..I assume classes.zip ?
One more item is to never publish connect strings
Maybe if Filip can suggest an alternative?
Viel Gluck
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> From: aelgamal@asset.com.eg
> To: users@tomcat.apache.org
> Subject: RE: failure notice
> Date: Mon, 24 Nov 2008 18:01:13 +0200
>
> Dear,
>
> I didn't create a connection pool of one connection. The configuration of the datasource in the first case was as follows:
> <Context path="/FamilyHandlerOpt">
> <Resource name="jdbc/VAS_FAF" auth="Container" type="oracle.jdbc.pool.OracleDataSource" driverClassName="oracle.jdbc.OracleDriver" factory="oracle.jdbc.pool.OracleDataSourceFactory" url="jdbc:oracle:thin:@172.21.201.60:1521:FMLYPRD1" username="family2" password="family2" maxActive="100" maxIdle="10" maxWait="-1" />
> </Context>
>
> In the second case, I opened the connections using the same configuration of the datasource above, kept the connections alive and pooled the threads on these connections.
> The response time of the second case was improved dramatically and the system scalability was achieved.
>
> Best regards,
> Ahmed Abbas
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, November 14, 2008 6:40 PM
> To: Tomcat Users List
> Subject: Re: failure notice
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> To whom it may concern,
>
> aelgamal , wrote:
> > The above scenario resulted in very poor scalability during the stress
> > testing. When the average response time for 1 thread was x msec, the average
> > response time for 2 threads was 2x and 3 threads was 3x and so on.
>
> How did you configure your data source?
>
> > When I created a pool of connections (15 connections) in the Servlet and
> > kept the connections of this pool alive the scalability improved. The
> > average response time for a 150 concurrent threads was slightly higher than
> > the average response time for 1 thread.
>
> How did you configure your data source, here?
>
> > Please advice why the poor performance when I used tomcat data source.
>
> Tomcat can be configured to use a data source with a connection pool
> size of 1. It's silly, but possible. If this is what you did, then you
> simply weren't pooling connections and you should expect that pooling
> would certainly improve performance.
>
> If you're interested in playing with connection pools, help out Filip by
> using his new Tomcat connection pool he's testing. I'm sure he'd love
> the feedback.
>
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkdqfwACgkQ9CaO5/Lv0PBXdACgjq/4JJZKJ+DgNn64szioNSZl
> mvgAoMN8Qb9oPjizMzzeXyGJQn6IPQmO
> =7ATP
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
_________________________________________________________________
Access your email online and on the go with Windows Live Hotmail.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access_112008
RE: failure notice
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Youssef Mohammed [mailto:youssef.mohammed@gmail.com]
> Subject: Re: failure notice
>
> Not sure what you mean by platform Independence here
It means that you can't simply drop a .war file and DB config into any arbitrary environment - you have to either provide extensive installation instructions for every type of platform (Windows x86, Windows AMD64, Windows IA64, Linux x86, Linux AMD64, HP-UX PA-RISC, Solaris x86, Solaris AMD64, Solaris Sparc, etc.), or do a lot of packaging work. Not pretty or fun.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: failure notice
Posted by Youssef Mohammed <yo...@gmail.com>.
Not sure what you mean by platform Independence here but OCI driver is just
a type two? JDBC driver that provide superior performance. You will have
to install an oracle client into your system but this shouldn't be a big
deal is it ?
We have developed some financial app two years ago and we settled on using
that native driver after couple of performance tests ... as far as I can
remember, it was also necessary if you have oracle stored procedure and
packages that might need recompilations while the web app is running ... if
you use the pure java connection pooling, the pooled connections are no
longer valid and you will have to restart the server or figure out away to
get rid of all connections in the pool.
Regards, Youssef
On Mon, Nov 24, 2008 at 6:30 PM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:
> > From: Youssef Mohammed [mailto:youssef.mohammed@gmail.com]
> > Subject: Re: failure notice
> >
> > It is highly advisable to use the native OCI drivers
>
> I think you'll find tons of disagreement with that. Sticking with the pure
> Java drivers is much less trouble and preserves platform independence.
>
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: failure notice
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Youssef Mohammed [mailto:youssef.mohammed@gmail.com]
> Subject: Re: failure notice
>
> It is highly advisable to use the native OCI drivers
I think you'll find tons of disagreement with that. Sticking with the pure Java drivers is much less trouble and preserves platform independence.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: failure notice
Posted by Youssef Mohammed <yo...@gmail.com>.
It is highly advisable to use the native OCI drivers .. that simply provide
a native connection pooling ... and can work perfectly with RAC setting ..
and because it native, you have superior performance.
http://www.rakeshv.org/docs/oracle/jdbc3.0/oracle/jdbc/pool/OracleOCIConnectionPool.html
Regards, Youssef
On Mon, Nov 24, 2008 at 6:01 PM, Ahmed Abbas <ae...@asset.com.eg> wrote:
> Dear,
>
> I didn't create a connection pool of one connection. The configuration of
> the datasource in the first case was as follows:
> <Context path="/FamilyHandlerOpt">
> <Resource name="jdbc/VAS_FAF" auth="Container"
> type="oracle.jdbc.pool.OracleDataSource"
> driverClassName="oracle.jdbc.OracleDriver"
> factory="oracle.jdbc.pool.OracleDataSourceFactory"
> url="jdbc:oracle:thin:@172.21.201.60:1521:FMLYPRD1" username="family2"
> password="family2" maxActive="100" maxIdle="10" maxWait="-1" />
> </Context>
>
> In the second case, I opened the connections using the same configuration
> of the datasource above, kept the connections alive and pooled the threads
> on these connections.
> The response time of the second case was improved dramatically and the
> system scalability was achieved.
>
> Best regards,
> Ahmed Abbas
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, November 14, 2008 6:40 PM
> To: Tomcat Users List
> Subject: Re: failure notice
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> To whom it may concern,
>
> aelgamal , wrote:
> > The above scenario resulted in very poor scalability during the stress
> > testing. When the average response time for 1 thread was x msec, the
> average
> > response time for 2 threads was 2x and 3 threads was 3x and so on.
>
> How did you configure your data source?
>
> > When I created a pool of connections (15 connections) in the Servlet and
> > kept the connections of this pool alive the scalability improved. The
> > average response time for a 150 concurrent threads was slightly higher
> than
> > the average response time for 1 thread.
>
> How did you configure your data source, here?
>
> > Please advice why the poor performance when I used tomcat data source.
>
> Tomcat can be configured to use a data source with a connection pool
> size of 1. It's silly, but possible. If this is what you did, then you
> simply weren't pooling connections and you should expect that pooling
> would certainly improve performance.
>
> If you're interested in playing with connection pools, help out Filip by
> using his new Tomcat connection pool he's testing. I'm sure he'd love
> the feedback.
>
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkdqfwACgkQ9CaO5/Lv0PBXdACgjq/4JJZKJ+DgNn64szioNSZl
> mvgAoMN8Qb9oPjizMzzeXyGJQn6IPQmO
> =7ATP
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: failure notice
Posted by Ahmed Abbas <ae...@asset.com.eg>.
Dear,
I didn't create a connection pool of one connection. The configuration of the datasource in the first case was as follows:
<Context path="/FamilyHandlerOpt">
<Resource name="jdbc/VAS_FAF" auth="Container" type="oracle.jdbc.pool.OracleDataSource" driverClassName="oracle.jdbc.OracleDriver" factory="oracle.jdbc.pool.OracleDataSourceFactory" url="jdbc:oracle:thin:@172.21.201.60:1521:FMLYPRD1" username="family2" password="family2" maxActive="100" maxIdle="10" maxWait="-1" />
</Context>
In the second case, I opened the connections using the same configuration of the datasource above, kept the connections alive and pooled the threads on these connections.
The response time of the second case was improved dramatically and the system scalability was achieved.
Best regards,
Ahmed Abbas
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Friday, November 14, 2008 6:40 PM
To: Tomcat Users List
Subject: Re: failure notice
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
To whom it may concern,
aelgamal , wrote:
> The above scenario resulted in very poor scalability during the stress
> testing. When the average response time for 1 thread was x msec, the average
> response time for 2 threads was 2x and 3 threads was 3x and so on.
How did you configure your data source?
> When I created a pool of connections (15 connections) in the Servlet and
> kept the connections of this pool alive the scalability improved. The
> average response time for a 150 concurrent threads was slightly higher than
> the average response time for 1 thread.
How did you configure your data source, here?
> Please advice why the poor performance when I used tomcat data source.
Tomcat can be configured to use a data source with a connection pool
size of 1. It's silly, but possible. If this is what you did, then you
simply weren't pooling connections and you should expect that pooling
would certainly improve performance.
If you're interested in playing with connection pools, help out Filip by
using his new Tomcat connection pool he's testing. I'm sure he'd love
the feedback.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkdqfwACgkQ9CaO5/Lv0PBXdACgjq/4JJZKJ+DgNn64szioNSZl
mvgAoMN8Qb9oPjizMzzeXyGJQn6IPQmO
=7ATP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: failure notice
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
To whom it may concern,
aelgamal , wrote:
> The above scenario resulted in very poor scalability during the stress
> testing. When the average response time for 1 thread was x msec, the average
> response time for 2 threads was 2x and 3 threads was 3x and so on.
How did you configure your data source?
> When I created a pool of connections (15 connections) in the Servlet and
> kept the connections of this pool alive the scalability improved. The
> average response time for a 150 concurrent threads was slightly higher than
> the average response time for 1 thread.
How did you configure your data source, here?
> Please advice why the poor performance when I used tomcat data source.
Tomcat can be configured to use a data source with a connection pool
size of 1. It's silly, but possible. If this is what you did, then you
simply weren't pooling connections and you should expect that pooling
would certainly improve performance.
If you're interested in playing with connection pools, help out Filip by
using his new Tomcat connection pool he's testing. I'm sure he'd love
the feedback.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkdqfwACgkQ9CaO5/Lv0PBXdACgjq/4JJZKJ+DgNn64szioNSZl
mvgAoMN8Qb9oPjizMzzeXyGJQn6IPQmO
=7ATP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Scalability
Posted by "aelgamal ," <ae...@asset.com.eg>.
Dears,
. A Servlet deployed on tomcat 5
. The Servlet connects to a database (Oracle 10 g) to perform a DML statement
. A lookup to a Data source was performed once
. I used the data source to open a connection to the database for each new request and close the connection by the end of the request.
The above scenario resulted in very poor scalability during the stress
testing. When the average response time for 1 thread was x msec, the average
response time for 2 threads was 2x and 3 threads was 3x and so on.
When I created a pool of connections (15 connections) in the Servlet and
kept the connections of this pool alive the scalability improved. The
average response time for a 150 concurrent threads was slightly higher than
the average response time for 1 thread.
Please advice why the poor performance when I used tomcat data source.
Best regards