SGEN (SAP Load Generator) is used to generate the ABAP (Advanced Business Application Programming) loads of a number of programs, function groups, ABAP classes, BSP applications etc. This is also one of the other longest running activities performed during a system copy process. For those who don’t already know, ABAP is a proprietary language for writing extensions in SAP. If you want to customize your SAP environment, you will use ABAP for various custom functionality like reports, creating user interfaces or automation with your own internal systems. SGEN is the SAP functionality that creates loads for executing your customizations.
To ensure that your enterprise SAP environment runs at peak performance, an SGEN process can be accelerated on Pure Storage® FlashArray by a big factor. In order to accelerate this process increase the number of parallel dialog work processes temporarily as SGEN uses dialog work processes to compile ABAP programs. This is done by changing the instance profile in the transaction RZ10.
In order to make sure that SGEN transaction is using the maximum number of free dialog work processes do the following.
Go to the transaction RZ12 use the RFC group parallel_generators which will ensure to use the maximum number of dialog processes to parallelize the sgen process.
In the below SGEN load testing we have tested with 92 dialog work processes to generate 373630 objects as shown below.
The whole SGEN generation process on Pure Storage FlashArray//m with 92 dialog work processes and the whole process took around less than 5 minutes to generate 373630 objects. Below is the view from Pure Storage FlashArray GUI which shows the whole execution on SGEN.
As seen below some of the highlights are the latency throughout was always sub-millisecond with a peak IOPS of ~26000 SAPS (13000 IOPS) and peak bandwidth was around 200 MB/sec.
SGEN load generation process is accelerated on Pure Storage FlashArray by a factor of 2-3 times when the number of dialog work processes are increased and utilization is set to high via server group parallel_generators. As seen in SGEN load testing, changing parallelization to the maximum is enough to accelerate the whole process by a factor of 2-3 times in SAP Netweaver systems due to our guaranteed sub-millisecond latency performance and high bandwidth on Pure Storage FlashArray.
Standard vs. Downtime-Optimized Execution in SAP
During deployment, you have the option of standard or downtime-optimized execution. The standard conversion takes servers out of commission while migrating tasks. This is an optimal option if your SAP environment does not need to be available during any deployments. Make sure any dependencies on your SAP database are also configured to run smoothly when the SAP database is down. You might need to bring these services offline as well.
Downtime-optimized execution is for enterprise applications that need 100% uptime. With this option, SAP will cache user activity and run it after your deployment. It’s important to note that you still need to go into a maintenance phase internally, meaning that you should warn users that there might be disruptions and back up data in case disaster recovery is necessary. For example, an enterprise might have synchronization between internal servers and SAP, so users might see a delay in updates to their information. Downtime-optimized options will delay updates, so users should be aware of the delay to cut down on customer service calls.
Scale Modern Database Workloads
Supercharge your databases with a simple, resilient and efficient storage platform.
