Practical Limits

Thread View: borland.public.cppbuilder.database.multi-tier

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Tom Barfoot Tue, 01 Feb 2000 00:00

#1304

Author: Tom Barfoot
Date: Tue, 01 Feb 2000 00:00

17 lines
1171 bytes

Are there any limitations as to the number of database objects that should
be placed in one server ?  I'm wondering how many
client connections a particular server can handle, especially if the server
app. is large and contains many components.  Is it better
policy to split the server side into several smaller apps, and if so, can
those apps "use" each other to get information, and do joins etc.

The configuration I'm using is as follows:

  Dell Server (HW)  2 processor, 500meg ram, raid array.
  BCB 3.0
  Multi-tier implementation. ( 1 Server so far, 25 objects ), standard
client stuff, many controls.


--
Tom Barfoot

Re: Practical Limits

#1306

Author: Mark Cashman (TeamB)
Date: Tue, 01 Feb 2000 00:00

20 lines
1331 bytes

Hi, Tom!

Practicality can't be assessed in the abstract. Generally, if you know
the task switching overhead, the typical and spike request processing
time, you can simulate when saturation of the processor will cause
queuing, and how long the delays will be.

Ideally you need to model all this based on some estimation of the size
of each request and the inter request arrival times and so forth. A
variety of queuing theory models could be applicable.

Alternatively, hammer the server with automated tools generating
requests and watch when it actually saturates.

------
Mark Cashman, TeamB C++ Builder
http://www.temporaldoorway.com/programming/index.htm
C++ Builder, JBuilder programming information
Home of The C++ Builder Programmer's Webring - Join us!
------

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads