Does anyone has experience in the benefits of running a number of oengines at diff ports to service 'n' connections? vs having say 20 - 30 clients connecting to just the one oengine?

If so, is there a sensible number at which to split the servers? ie. one oengine per 6 connections? and what throughput improvements can one expect through this approach?

Thank you

Martin,

The main gain you've got is that you can handle more concurrent requests.

20-30 clients to one engine means that they will get queued one behind the other. That may not be a problem if each request takes a really small amount of time to process, but on time-intensive requests that do a lot of DB I/O it may become significant.

Again, the ratio of users to engines under a multiple-engine scenario is load-dependent. In this past when we've adopted this sort of structure we've found that 10 users per engine was more than comfortable - your mileage may vary - you'd need to do some benchmarking to determine this for your own system.

Currently what we do is have a central point for requests running as a Windows Service that hosts a specified minimum number of engines. Requests are routed to free engines via this service, or queued until an engine becomes free. It also has the capability to create new engines if there is spare capacity and terminate hung ones.

The other advantage of having multiple engines is one of resilience. If an engine gets terminated or hung for whatever reason you still have others to route to. It takes time to create a new engine, especially on a heavy loaded system.

The Sprezzatura Group

World leaders in all things RevSoft

Well - this sounds exactly like what I need to grow into.

Can you please drop me a line at martin.drenovac@powerforcesoftware.com, I'd like to discuss options.

Cheers

View this thread on the Works forum...