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"
