This content has been marked as final. Show 7 replies
As of this date we don't have any hard and fast hardware guidelines that can cover every customer's needs at a glance.
I can post some general guidelines later that, I think, would help you greatly.
If you'd like that just let me know and I'll post it for you.
I'll see if I can find some hardware sizing documents somewhere. As Ron stated, there are few "hard" guidelines. That being said, there are some "soft" ones...
Basically, for MWM and the Scheduler, you want to consider the following:
1. Maximum Orders worked per day (in thousands)
2. Maximum Crews logged into the system at any point in time.
3. Number of days into the future you want to Appointment Book and see Crew Availability (also called "Scheduling Horizon").
4. Number of months of future work you're going to keep in the system (3 months into the future, 6 months, 1 year?).
5. Batch download of orders to crews or "drip feed" (sending orders down to crews throughout the day).
Here are some additional details. I'm looking to size the HW based on a future growth path and those are the numbers I will provide below. I had to do some extrapolation due to not know exactly which departments would be highering.
If we consider that there are 3 different groups being considered (Grp1, Grp2, Grp3), here are the details:
Number of techs:
- Grp1 = 225, Grp2 = 38, Grp3 = 37
Number of jobs per technician per day (at peak periods):
- Grp1 = 100, Grp2 = 15, Grp3 = 20
Avg number of jobs in the schedule for each group "today" (Day1)
- Grp1 = 3,800, Grp2 = 120, Grp3 = 120 (before growth)
- Grp1 = 14,250, Grp2 = 450, Grp3 = 450 (after growth - using # of techs above)
Shape of jobs (how do the number of jobs taper off as we look at Day2, Day3, etc.) - using avg job volume. After Day3 the numbers remain about the same for the next several days:
Grp1_Day1 = 13,125
Grp1_Day2 = 6,375
Grp1_Day3 = 3,750
Grp2_Day1 = 225
Grp2_Day2 = 225
Grp2_Day3 = 225
Grp3_Day1 = 450 (all jobs come in during the first 30min of the day, Day2 is pushed on Day2 morning)
Grp3_Day2 = 0
Grp3_Day3 = 0
Horizon - how far in the future orders are pushed into the schedule
Grp1 = 3-days active scheduling - may get pushed
Grp2 = 3-days active scheduling
Grp3 = 30-days active schedule (some jobs are in the schedule for 2 years)
Here's our take on the ORS part of the hardware requirement once we reviewed your data:
Grp1 will have 285,000 tasks per month. AE only has 380,000 customers. Grp1 must be meter reading.
ORS does not do meter reading routes for lots of reasons.
The other groups are 1 - 2 scheduling regions (processor cores) each.
Note: The statement: "ORS does not do meter reading ..." on line #2 was made because if you "do the math" and actually
figure out how many orders per man per day this turns out to be then the time to work each order in the day is just
so small (a few minutes at best) that ORS would simply have to work too hard to figure these routes out and then
change them dynamically when crews start to fall behind.
Our typical ORS machine is a nice fast intell quad processor machine with fast disk access and at least 8 gigs of RAM.
It sounds like you may need at least two of these for the ORS part of the job...but I'd strongly suggest that you contact
Oracle MWM professional services or the ORS group directly (if possible) to get a better handle on this problem.
As far as the MWM part goes we normally suggest:
A fast quad processor intel machine running windows server 2003 with at least 8 gigs of RAM
and lots of hard disk space (at least 80 - 100 gig).
The hardware required for you database server (which should be separate) is probably
your DBA's problem but we suggest a similar setup as the one mentioned above.
I will try to get the ORS group to watch this thread. Perhaps they can be a little more help on the way to approach the
hardware problem for ORS.
Here is some input from our ORS folks:1 person found this helpful
The numbers in there are all inconsistent.
At one point the statement is that Grp1 has 14250 Activities/per day then a couple of lines below it is 13125.
Grp 3 has 450 Activities per day all posted the day before working but has a 30 day active schedule.
Anyway assuming we are not scheduling Grp 1 as it is meter reading work then 1 region could handle the other two groups.
A couple of simple rules of thumb:
1) 16,000 Shift limit per region = Number of Crews x Horizon
2) 20,000 Activity limit per region. This is total in system at any point in time.
Each Region as described above would run on a Quad-core as described. If you want failover and another.
If you want appointment booking, at fairly low volumes (max 100 per minute) then you need the two servers and you get failover thrown in for free.
Thanks for the info.
For the record, Grp1 is not meter reading. This group does connects/disconnects.
Don't know happened with my number inconsistency, but using either number poses a problem from a maximum stop count.
Looking at the quad-CPU recommendation, is that a two physical CPU chip, each with dual-core or 4 individual CPU chips?
For the RAM, it is recommended to have 8GB RAM using Win2003 64-bit edition to be able to take advantage of the > 3GB RAM?
It's been suggested that each core be assigned 4GB RAM (so a quad would actually require 16GB RAM) and that I assign different groups to each core. Based on the previous post, it sounds like I could actually assign Grp2 & Grp3 to a single core. Could I then, split Grp1 into multiple groups and assign each sub-group to a different core?
Actually that would be two dual-core processors.
I don't think MWM is certified on a true 64 bit system but you still can
access more than 3 Gigs of memory using a flavor of server 2003.
There are lots of flavors that don't use a 64 bit OS but still can
access more than 3 Gigs of RAM. I belive EE edition does but
their are still others that do also.
About your groups. Yes that would be possible.
Just remember, though, if you have so many orders per crew that they
only have minutes to complete each one it may not be wise to have
ORS looking at them in real time. There would be so many potential
reschedule transactions flying around that you could bring the system
to its knees. It is important to break down the problem into regions
where you can work all of your mandatory work within the perscribed
event horizon. It looks like this is what your are trying to do.
You are on the right track.
If you are worried about your configuration and want Oracle to give it a good once
over you might consider contacting professional services for a quick consultation