| Subject | RE: [firebird-support] Running out of database! |
|---|---|
| Author | Rick Debay |
| Post date | 2007-04-11T21:52:37Z |
Seven servers times thirty connections in the pool equals two hundred
ten processes running on the server.
Process context switching is expensive, and if each process has a large
cache you're running out of memory.
Even with a "commercial" database, you can only load a database so much.
Normally you start pushing back by having connection limits in Tomcat,
and then higher limits in Apache, so that your 200 database connections
can handle one thousand concurrent Tomcat users and then five thousand
concurrent Apache users.
-----Original Message-----
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of hay77772000
Sent: Tuesday, April 10, 2007 12:21 PM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Running out of database!
Hi,
We have a series of severs that are each running Tomcat, and load
balanced through Apache. They all share the same firebird database on a
dedicated machine on the backend - v1.5. We initially started with
SuperServer, but had stability and other problems with that, so we
switched to Classic. Each server uses a db connection pool with approx
30 connections.
When we scale up, we seem to hit a wall at around 7 servers, where the
database machine cannot keep up.
Can anyone suggest ways that we can get around this issue? Does anyone
have experience with some of the other "commercial" dbs - Oracle/Sql
Server etc.? Would switching to one of these likely help us?
many thanks,
David
Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.
ten processes running on the server.
Process context switching is expensive, and if each process has a large
cache you're running out of memory.
Even with a "commercial" database, you can only load a database so much.
Normally you start pushing back by having connection limits in Tomcat,
and then higher limits in Apache, so that your 200 database connections
can handle one thousand concurrent Tomcat users and then five thousand
concurrent Apache users.
-----Original Message-----
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of hay77772000
Sent: Tuesday, April 10, 2007 12:21 PM
To: firebird-support@yahoogroups.com
Subject: [firebird-support] Running out of database!
Hi,
We have a series of severs that are each running Tomcat, and load
balanced through Apache. They all share the same firebird database on a
dedicated machine on the backend - v1.5. We initially started with
SuperServer, but had stability and other problems with that, so we
switched to Classic. Each server uses a db connection pool with approx
30 connections.
When we scale up, we seem to hit a wall at around 7 servers, where the
database machine cannot keep up.
Can anyone suggest ways that we can get around this issue? Does anyone
have experience with some of the other "commercial" dbs - Oracle/Sql
Server etc.? Would switching to one of these likely help us?
many thanks,
David
Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.