|
|
|
|
|
Winshuttle’s server-based products fully support deployment in load-balanced architectures. This ensures enterprise scalability of both the number of users served and the amount of data throughput handled. Capacity planning helps you determine the number and sizing of servers (physical or virtual) required to meet the needs of your Winshuttle deployment.
Capacity planning is only part of the capacity management lifecycle. After initial deployment, managing capacity is an ongoing process because no Winshuttle implementation remains static with regard to usage and data loads. To ensure long term effectiveness, you will need to plan for future growth and changes in usage patterns.
Winshuttle Central and Winshuttle Workflow are both add-on products to the Microsoft SharePoint platform. As such, you can generally rely on Microsoft’s guidelines for capacity management and sizing which are available from this location: http://technet.microsoft.com/en-us/library/cc261700.aspx.
Winshuttle Central and Winshuttle Workflow are often deployed to a shared environment that is already being used for other purposes, including content management, business applications, or other third-party solutions. Capacity management for a shared environment needs to incorporate all uses of SharePoint across the enterprise.
Based on the SharePoint foundation, all configuration settings and user data are stored in SQL Server databases. Apart from the standard SharePoint databases, two additional databases for Winshuttle Central and Winshuttle Workflow are installed respectively. When sizing your storage requirements, you need to consider the following for the respective databases:
Storage = S × f × R, where:
Once safe upper estimates have been determined for the three variables above, the required storage can be calculated. It is important to use the same time unit of measure for the variables f and R. For example:
800 KB × 100 files/month × 24 months = 1.9 GB
Perform this calculation for every use cases and add them up to determine the total storage requirement. The same formula can also be applied to forms-based scenarios, using 100 KB as an upper estimate for the average file size. If attachments are included in the form, then an allowance for these should be added too.
Please also refer to Microsoft’s guidelines (http://technet.microsoft.com/en-us/library/cc298801.aspx) for recommendations on how to estimate SharePoint content database storage.
Data files go through a lifecycle where they are automatically moved to a ‘Completed Data Files’ library on Winshuttle Central after being processed. Using standard SharePoint features, this library can be configured to automatically delete or archive files after a specified retention period.
In non-production deployments with limited usage, it is possible for Winshuttle Server to coexist on a SharePoint server together with Winshuttle Central and Winshuttle Workflow. For production purposes, Winshuttle Server requires a dedicated Windows Server environment.
One Winshuttle Server can handle a throughput of up to 7 requests/second. This capacity can be increased by adding additional servers in a load-balanced configuration.
If the Winshuttle Transaction scripts being run rely on GUI Scripting or Launch GUI, throughput is significantly reduced and will need to be tested on a script by script basis. Ideally, Launch GUI should be enabled on a separate instance of Winshuttle Server so it will not affect the 7 requests/second throughput of the parent instance.
In scenarios that depend on a Launch GUI script, it is highly recommended to consider BAPIs first since this is a more scalable and robust option. Launch GUI scripts are supported as web services only as a last resort in case it is not possible to find a BAPI that will cover the requirements. Refer to the Winshuttle Direct documentation for more details on how to leverage BAPIs.
Scaling the Winshuttle Server environment depends on the types of use cases. In case of Autopost where posting to SAP is handled as a background job, a queuing mechanism is in place to ensure that all loads are handled eventually. In case of manual post from Excel or when using web services, Winshuttle Server may reject requests during peak times. As such, scaling for throughput is more critical in scenarios where users are actively waiting for a response (e.g. calling a web service from a form).
The throughput capacity to SAP is dependent on the following influencing factors:
Experience shows that the primary source of bottlenecks in processing data files comes from:
Large data files (close to 999 lines) which on average take 4 minutes to process on a typical system but which can take less time on a very high performance system.
Lack of dialog processes in SAP or SAP Message Server overload
Slow network performance resulting in slow calls over RFC (Winshuttle Server communicates with SAP using the RFC protocol).
Rarely has it been experienced that the contention is resource max-out on Winshuttle Server. Performance issues are typically caused by delays in the last two points above.
Some ways to improve performance are:
See Also |