SMP 3.0 sizing for SAP Work Mgr. 6.2

[former_member220966]

All,

We are in the process of revalidating our SMP 3.0 sizing based on more accurate numbers regarding our data volume(number of work orders synced per day-  during peak time, average number of operations per work order, number of equipments/functional location per operation etc.).

I have read the latest SAP Work Mgr. sizing guide as well as KBA 1918717 and have the following questions:

1) The SAP Work Mgr. sizing guide gives an idea of the number of SAPS our server will need based on our data volume, But it only takes into account the throughput based on transactional data (work orders). As part of the initial sync, we have a LOT of master data that is being downloaded to the client - equipments, functional locations, characteristics etc. Does this not have an impact on SMP 3.0 server sizing? I did not see this as part of the calculations in the sizing guide.How do we include these numbers as part of the SMP server sizing calculations?

2) Also, we are including the functionality to integrate with GIS, this of course means that more geometry relevant data is being fetched as part of the initial sync. How do we include these as part of our iterative sizing calculations?

Any help or insights would be very much appreciated!

Cheers,

Abhinav

[bill_froelich · Accepted solution]

I'll take a shot at answering, but the key thing to remember is that the sizing guide is just that, guidelines.  For best answers, especially if your environment is already up and running, measure your actual volumes and monitor the system on an on-going basis adjusting where and when needed.  As you indicated, your data volumes will change over time so a day one time sizing may not fit after you have been in production for while.

1) I believe (my opinion here) the sizing calculations are targeting ongoing usage.  your initial sync volumes, while large , typically only occur once and also typically won't be done all at the same time.  This can also be mitigated by deploying pre-built clients to avoid some of the initial sync download and time.  I would instead focus on your concurrent "normal" usage patterns and volume when sizing your server(s).

2) The GIS data doesn't really add any overhead to the SMP3 server since the processing for that is handled by SAP and the ArcGIS server.  You simply get the geometry string returned with your objects which is a very small increase in the data size overall.

Hope this helps.

--Bill

[former_member220966 · Accepted solution]

Bill,

Thanks for the response. I completed the sizing exercise about 3 weeks back, I referred to the "Sizing guide for SMP 2.3" for Agentry applications, most of the concepts were identical:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/60c1a072-1cba-3010-d995-a186f208a...

We have to calculate the following:

1) BASE SAPS - Determine the peak number of users that interact with the server during any one hour period

2) Download SAPS - The download data SAPS is determined by the number of rows transmitted through the Agentry Server to devices

3) Upload SAPS - The amount of uploaded data is dependent on the number of transactions (insert, update, delete) performed on the device

The only question I had was the sizing guide talks about a BASE SAPS multiplier, table 16 on page 24 - number of instances in each device database. I have no idea what that it, for my calculation I just "assumed" that my BASE SAPS multiplier was 26.

We are now waiting for vendor to come back and confirm if our servers are indeed these many SAPS.

Cheers,

Abhinav