How many app servers and db servers would I need? 1000+ user

Before someone can even guess at the answer, one needs to know a lot more about your user base and application. 1000 users who do one transaction an hour is a very different load than 1000 heads down order entry people.

Is your application written for AppServer now? Which state model?

Our application is currenlty MFG/PRO running character clients using remote telnet connections across N.A. I am going to have 24+ db's and over 1000+ users by 2008. We run batch jobs during the day that can do some heavy I/O since they are transaction based, and I'd say about 60% of our users query the db versus physically updating it. We are planning on moving toward a .NET interface as well, so we will be using both. (ie: 2 sets of source code is what i'm expecting). As for the number of transactions daily, a rough number is 200,000 per database.

So, if you are running ChUI, the current application isn't written for AppServer at all or you would have to upgrade to a new version (I don't know specifics on Mfg/Pro).

Then, what do you mean by "app server"? in your original post? What software is going to be running on them?

There is nothing about ChUI that means an application can't use app servers.

I'll grant that it's likely that a ChUI application pre-dates widespread app server adoption (actually I'd argue that it's debateable that wide spread app server adoption has occured at all) but that doesn't mean that QAD has necessarily ignored them for the 10 or so years since they've been available.

Of course it is possible, just not likely. And, in this case, the original post tells us that they are using telnet, so the version they are running is almost certainly not using AppServer. No point in arguing, though, since either their version does or doesn't and they are either in a position to upgrade or not and either QAD offers such a thing or not. I'm guessing that what is meant by "app server" here is something generic, not the PSC product.

Telnet does not preclude app servers either.

He mentions .NET as well. Which suggests, to me, that he either already has, or is planning to implement some of QAD's GUI code either in addition to, or as an upgrade from, the telnet sessions. So progress app servers should be very much a part of this mix.

None the less, you may be right. It may very well be that the r-code is sitting on a distinct server (mis-named an "app server") and accessing the database via -S connections even though they are using telnet. That's a very popular configuration in some circles.

Bottom line, we need to hear from Rico Baggetta what is there and what will be there before anyone can make any useful suggestions.

Thank you for the great response thus far..I am picking up things are you gentlemen are debating this (Great stuff). Its too bad I cannot attach an architure layout of MFG/PRO and what they suggest on was is the optimal configuration of 100+ users. I need 1000+...10x what they suggest. Let see if this can shed some light.

App server to me is the general name given to a server to host specific applications, not really PROGRESS related. So, in my case, the AppServer holds the following: Web Server, WebSpeed Remote Messanger, Tomcat Server, Embedded Telnet and a Connection Manager.

The DB Server normally has: MFG/PRO DB, WebSpeed Agents, mfg/pro application source code (_progres), Name Server. Embedded telnet connetions to the Connection Manager on App Server, WebSpeed Brokers.

In this kind of configuration, QAD recommends a Teir-2 approach which gives it more balance of resources between AppServer and DatabaseServer.

Tom, I have your email addy, so let me send you the deployment considerations, maybe this will also clear up Thomas' questions that you can explain in your own words (you guys seem to the experts at this, I'm just trying to pick your brains and work experience to come up with some knowledge on what happens behind the scenes of these particular Progress applications)...thanks for listening.

Does this mean that you are changing versions of MFG/Pro? And moving from the current ChUI to at least partly web clients?

Tom, I have your email addy, so let me send you the deployment considerations,

Good idea ... Tom's one of the right people to go to for performance issues ... of course, he probably thinks you should stay all ChUI, but you might talk him out of that!

Good idea ... Tom's one of the right people to go to

for performance issues ... of course, he probably

thinks you should stay all ChUI, but you might talk

him out of that!

Why would one want to do that?

Oh, I have a sneaking suspicion that there might be a business case for browser client...

Sizing a system like this is very complex. There are no cookie cutter answers.

There also appear to be two distinct issues. One is sizing the expansion needs for the current configuration, the other is estimating the needs for a major architectural shift.

In the first case your best friend is good baseline metrics about your current load and performance. You need good solid data about operating system metrics, Progress database metrics, MFG/PRO application activity and the business activities that drive them all. This data needs to cover a sufficiently wide swath of the business cycle so that you get all of the ups and downs; that usually means at least a month although sometimes the key cycle is weekly and sometimes it is much longer (annually).

(Of course if your system is not already well instrumented you may also discover that it isn't very well tuned to start with and you may benefit substantially from several iterations of tuning and measuring prior to settling on a baseline configuration to your base plans on...)

Using that data in combination with the business projections that are driving the expansion you should be able to map out a reliable path forward for the current systems.

If you aren't comfortable doing all of this yourself (it is a lot of work to "roll your own" tools) then Progress' Fathom product line (known as OpenEdge Management in OE10) could be helpful in gathering this baseline data and projecting forward or you could engage a consultant (hint, hint) to help you out. Or both.

The second issue, a planned major upgrade from old fashioned telnet based MFG/PRO to .Net is much more difficult because you lack a reliable baseline. You can, perhaps, create one in a test lab or you could borrow one from QAD's tests but you're on much less certain territory. I'd probably do both and also try to obtain references from similar sized customers in my industry (if you can find them and they're willing to talk).

In any event and for both cases -- committing to hardware at this stage is premature. Unfortunately it is also the number one mistake that clients make.

Tom thanks for tips. You advice and expertise on the subject is appreciated, same ditto to Thomas. From my gatherings here it sounds like we are going to make one of those "client" mistakes and purchase hardware without real exposure to .NET and its architecture, but I am confident that the hardware we are buying is actually top notch, and if configured correctly, these db's will be efficient, and incredibly faster than our current system.

Just make sure that the people signing the checks know that the initial configuration isn't necessarily the final configuration. Rather than throwing every available hardware dollar into the original purchase, hold something back so that you can add what you need, when you figure out what that is.

Which said, it is very easy these days to achieve incredibly faster!