Re: Memory for client connections

In article fsf_at_cerberus.atlassoft.com, tyson_at_cerberus.atlassoft.com (Tyson Chihaya) writes:
>
> Hi,
>
> We're trying to design a large-scale client-server system, and we're
> anticipating a large number of concurrent connections from our oracle
> client to our oracle server. The number of connections that we can
> make from a Sun Ultra with 192 MB of ram to our oracle server seems
> to be about 70.

 [snip]
> Also, has anyone else dealt with needing to service thousands of users
> with one oracle database? I think the final solution lies in having
> many users on each database connection...
>
> thanks,
> tyson

Yes, sharing connections is a common way to deal with large numbers of users. You can also handle this by running the clients on multiple machines. But eventually, either the client or the server will run out of resource in large client-server systems, so you have to add middleware (or keep buying better hardware).

I'd think about breaking the app into several peices.

Transaction Monitors like Tuxedo, Encina, CICS, TopEnd, etc do alot of this for you. Or you can use ORB's and CORBA, but then you'll have to write the load-balancing, queuing, messaging, etc infrastructure yourself, or buy it from another vendor.

So what you can do is have your client (webserver?) machine have lots of non-database clients, which in turn make requests to "services" through the TP monitor. The TP monitor then looks for machines that aren't busy, and sends the requests to them. The same service can live on multiple machines, or the TP monitor can span extra instances of the services as needed. Those services (db-clients) then send requests to the database, or to other services. In really large systems, the services might use SEVERAL databases. The TP systems actually let you do transactions across several database servers.

This lets you scale up- you can add more machines, more databases, whatever, and you really don't have a limit. Lottery systems use this technology.

If you go the ORB or RPC route, and write it yourself, DON'T make requests to a particular machine. This may allow you to move code off of your original machine, but then your second machine has to worry about the load. Use some code to figure out what machines aren't busy, or use queues and have the services look for work to do from the queues. This is how TP monitors scale without getting a performance hit.

Also take advantage of asynchronous processing- your original client can send requests to the services, and can then go about other work. If something fails, the TP monitor can send messages back to the client.

Look at the homepages of BEA Systems, IBM, and Transarc.

good luck,
Mark McNulty
JYACC Consultant
mmcnul_at_jyacc.com

Note- these views are mine and not those of JP Morgan or JYACC. Received on Tue Apr 15 1997 - 00:00:00 CDT