The rules:
1. When using the BDE always increase the number of buffers available (use
the BDE Administrator). You will have to tweak the values until you find
one that suits your application.
2. Always use connection pooling when you write a web server application
(or use an application framework that supports this). Basically connection
pooling means you open up all available connections and put them into a
pool. Every thread that needs a database connection requests one from the
pool. When the thread is done with the connection, return it to thee pool.
Ideally, the thread should only hold on to the connection for as short a
time as possible. If there are no more connections in the pool, block the
thread. Always put a timeout on the block so that users get a sensible
error message from your web application if the server runs out of resources,
rather than waiting for the browser to time the connection out.
3. For really busy sites, it is better to use an application server.
Regards,
Dennis.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 20 June 2001 15:58
> To: Multiple recipients of list delphi
> Subject: re: [DUG]: maximum sessions per process?
>
>
> Well, I'm finding the problem even with say 50 concurrent hits (seems to
> occur after about 34).
>
> The problem is, one of the client sites has about 300 employees, who will
> likely hit the website all around the same time to enter timesheets and
> other information. So the 'potential' is there. But even with 50
> concurrent I'm getting these problems. At first I thought it was the
> maxdbprocesses in the bde but changing that makes no difference.
>
> I just made a wee test app, which created a session and tdatabase and
> connected up to see the upper limit.... it was bombing at the 45th
> concurrent database connection.
>
> Surely someones hit this problem before?
>
> --On Tuesday, June 19, 2001 8:11 PM -0700 Ben Taylor <[EMAIL PROTECTED]>
> wrote:
>
> > yes, but: (if you are consistantly getting 200+ hits this isnt for
> > you). if you are occasionally (say, <30% of the time) peaking over this
> > limit then you can queue excess requests, wait (1second?) until there
> > are connections free again, then continue..
> >
> > if you are able to pool active sessions, then you may have a faster
> > turnaround for handling a request, and less likely to hit the 200 limit
> > in the first place.
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> > http://personal.mail.yahoo.com/
> >
> -------------------------------------------------------------------------
> > -- New Zealand Delphi Users group - Delphi List -
> [EMAIL PROTECTED]
> > Website: http://www.delphi.org.nz
> > To UnSub, send email to: [EMAIL PROTECTED]
> > with body of "unsubscribe delphi"
> >
>
>
>
>
> ------------------------------------------------------------------
> ---------
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
