On Wed, Sep 08, 2010 at 05:27:24PM -0500, Kevin Grittner wrote:
- David Kerr <dmk@mr-paradox.net> wrote:
-
- > My assertian/hope is that the saturation point
- > on this machine should be higher than most.
-
- Here's another way to think about it -- how long do you expect your
- average database request to run? (Our top 20 transaction functions
- average about 3ms per execution.) What does that work out to in
- transactions per second? That's the TPS you can achieve *on each
- connection* if your pooler is efficient. If you've determined a
- connection pool size based on hardware resources, divide your
- anticipated requests per second by that pool size. If the result is
- less than the TPS each connection can handle, you're in good shape.
- If it's higher, you may need more hardware to satisfy the load.
-
- Of course, the only way to really know some of these numbers is to
- test your actual application on the real hardware under realistic
- load; but sometimes you can get a reasonable approximation from
- early tests or "gut feel" based on experience with similar
- applications. I strongly recommend trying incremental changes to
- various configuration parameters once you have real load, and
- monitor the impact. The optimal settings are often not what you
- expect.
-
- And if the pooling isn't producing the results you expect, you
- should look at its configuration, or (if you can) try other pooler
- products.
-
- -Kevin
-
Thanks for the insight. we're currently in performance testing of the
app. Currently, the JVM is the bottleneck, once we get past that
i'm sure it will be the database at which point I'll have the kind
of data you're talking about.
Dave
