Short, Medium and Long Range Plans for speeding up One World response times?

What are your short, medium and long range plans for speeding up One World's response times?
We are asking because we experience slowdowns during critical parts of the day. CP&S uses JDE One World on a platform of Win2000 and SQL2000. Our enterprise server is has 4 processors and the memory usage never gets maxed out. However we often see the processors (all 4) hitting the wall. This is not a speed demon and my users let me know that frequently! The things we associate with these humps in the day are the number of users and queries from JDE to the SQL database. This does not seem to be a network problem because at any time we have excellent responses from pinging the enterprise server. It is time to do short, medium and long range planning. We expect to add users and transactions. Our short-range plans include exchanging the current processors for processors of higher speed. We're thinking about setting up a clustered server over a big disk array. We are currently on B7332 SP 11 and we are testing ERP 8 (that's our medium range solution). A longer-range solution may be to migrate to a different platform.

We are interested in other One World users opinions and experience. If you can share them, what are your short, medium and long range plans?

Very truly yours,

dave

Our plans are currently to just maintain - we process roughly 300,000+ ube's per month. My suggestion to you would be

Short - see how much time is being spent in your DB. It may be as simple as doing some tuning in the DB. Also if you have a bunch of users running adhoc queries using Access or other tools you may want to look at limiting their access to the DB during these peak times.
Medium - continue on your path of looking at faster procs (and maybe more memory to give your DB more breathing room)
Long - look at running the DB on a seperate server. Thus you can tune each box (JDE server versus DB server) as needed and probably get better performance. Generally speaking JDE isn't taking up to much time it is some of the less than stellar SQL that JDE creates that spends a lot of time spinning the DB.

Hi,

I agree with Mark. Separating the Database on another machine will help.

Are you using the W-environment for citrix where business function is mapped to the enteprise server. If so, you can try using the PD7333 to off load the enterprise server.

You mention that you are considering vertical scaling- adding more oomph to your existing box. I would recommend the opposite- scale horizontally by adding another server so as to split dB and OW. Then add UBE servers as necessary. Removing the dB from your Enterprise Server (or vice versa) is one of the best things you can do to improve performance.


BTW, how many UBE queues/threads do you have set?

Long term - consider migrating to Oracle

Why on earth would he want to do that?

http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

Thanks for the suggestions. When you say to split off the DB do you include all the libraries or just proddta? If we do that will the enterprise server handle security and the JDE kernal and the improvement comes when the SQL server is getting slammed, the interactive requests get processed without the SQL hogging the processors? Is that the reason?
To answer the queue question, I’ve got 10 queues. It is very infrequent to have more than 3 UBE’s running at the same time.
We are looking into building a clustered server – 2 cpu’s sitting on a big disk array.

Here's the plan:

To accomplish both tasks that you wish to, you will create a dual Active/Passive cluster with the Database active on node 1 and OneWorld active on node 2.

This effectively 'splits' the dB from the OneWorld services, giving you a performance gain by eliminating contention for hardware resources.

You will also accomplish your goal of providing high-availability (such as it is with MS clustering) for your end users. Please make note that a new and relatively unknown feature of OneWorld is Cluster Retry. Details about this function can be found on the KG and are associated with SAR 5122082.

If you need more help on creating a dual Active/Passive cluster let me know via email.