7 Replies Latest reply: Apr 6, 2010 1:51 PM by ThatMWMDude RSS

    HW Sizing

    762431
      What are the guidelines for determining the proper hardware sizing for an organization?
        • 1. Re: HW Sizing
          ThatMWMDude
          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.
          • 2. Re: HW Sizing
            Blemaster-Oracle
            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).

            Regards,
            Brian
            • 3. Re: HW Sizing
              762431
              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)
              • 4. Re: HW Sizing
                ThatMWMDude
                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.
                • 5. Re: HW Sizing
                  ThatMWMDude
                  Here is some input from our ORS folks:


                  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.
                  • 6. Re: HW Sizing
                    762431
                    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?

                    Thanks again
                    • 7. Re: HW Sizing
                      ThatMWMDude
                      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
                      later.