From: strepxe on
Hi,

We have an application that uses ODBC to connect our client
application to an Oracle database. Currently we run at approximately
10-100 concurrent users with no major problem. A request has come in
asking if the application would be able to support approximately 1000
concurrent users. My feeling on this is that the number of concurrent
users could adversely affect performance and some pooling technology/
architectural change would be needed. What I lack is any guidelines on
the limitations of ODBC in this regard. Can anyone point me in the
right direction?

Ger
From: gym dot scuba dot kennedy at gmail on

<strepxe(a)yahoo.co.uk> wrote in message
news:c107326d-54d2-4bf7-abe2-e8d49b0fbbae(a)k37g2000hsf.googlegroups.com...
> Hi,
>
> We have an application that uses ODBC to connect our client
> application to an Oracle database. Currently we run at approximately
> 10-100 concurrent users with no major problem. A request has come in
> asking if the application would be able to support approximately 1000
> concurrent users. My feeling on this is that the number of concurrent
> users could adversely affect performance and some pooling technology/
> architectural change would be needed. What I lack is any guidelines on
> the limitations of ODBC in this regard. Can anyone point me in the
> right direction?
>
> Ger
The answer is really more complex. We don't know how well written your
application is or is not. Using ODBC doesn't mean it is well written or
not. (it could be either) If you do not use bind variables then there is
little chance your appliaction will scale. In short insufficient
information. Basically, with 1,000 users you will bottleneck somewhere, how
large is that bottleneck and what is it. If you don't use bind variables
buying more CPU (pr faster CPU) or memory won't do bupkis to solve the
problem. If you are IO bound then adding more CPU won't help. (It may
actually hurt; each query will get in line for the disk faster.)
Jim