While creating a Mobile Model in the Backend or in the Middleware usually the performance is an aspect that is ignored during the design phase. The focus almost for all the applications initially is to get the functionality working. The performance impact only comes into the picture after the solution has been rolled out and the data continues to grow. This causes issues, especially when supporting large enterprise applications.
Following are the key points to keep in mind from a performance perspective when designing a Mobile application solution.
1. Choosing the right data
2. Cardinality
3. Scalability of the system
4. Load Testing
5. Archiving old data
1.Choosing the right data:
Often in the Mobile world designers are guilty of sending too much data on the device. Always remember that Mobile devices are usually required to replicate only a subset of the Backend operations and not the entire functionality. Be clear with the scope and try to restrict your data model to incorporate only the objects that are needed on the device. For e.g.: if you are replicating a pricing functionality then the complex pricing logic can be actually be on the Backend and the device just makes an online call to retrieve the information. That way device doesn't need to store all the pricing related data.
2. Cardinality:
This is a very important and often ignored aspect towards performance considerations. Cardinality is basically number of records between two nodes. Usually, it is between parent node( root node/ header table) and the child node. Try to design your application in a way that the most frequently needed data is at the parent node. This will avoid traversing one level lower for records if they were at child node level. The amount of data and filtering on child node can impact the performance of the application and/ or the Middleware. Consider the following scenario: Device application needs all the products of a company to be sold to generate the invoice based on the products selected. Let's assume the company has 50,000 products. Now imagine that the application also stores the local warehouse related information for each of the product. The local information will be stored in the child node. But if the company has 500 warehouses countrywide, it will mean the number of records in the child node will be 50,000 * 500 = 25 Million. This will take up significant memory as well as time to be passed between the systems. Also, if the application has to search through any local information about a single product it has to search through these 25 million records thus, impacting the application performance.
3. Scalability of the system
Once you understand the cardinality of the objects and their relationship to other objects, then the next logical step is to do the calculation for all the objects and determine the number of records for each object. This helps in determining the peak load on the system which is important for scaling the system. For SMP SAP already has a quicksizer tool that determines how many SAPS the system should be scaled for. The quicksizer covers only certain scenarios like online apps etc. For more information on quicksizer for SMP 3.0, you can read the following blog: https://blogs.sap.com/2014/06/25/smp3-sizing-with-sap-quicksizer.
In general, you can look at the performance and sizing guides provided by SAP and can work with your BASIS expert for scaling the system.
4. Load Testing
Once you determine the peak load and scale the system, it's also important to load test the system in order to avoid any surprises later.This can be done via custom scripts or using various load test tools like HP Load Runner etc. Ideally, try loading the data in QA environment first and then move it to production. It will serve as a good benchmark and will help you determining the right strategy for Production move. You can check the following link to read more about load testing on SMP: https://archive.sap.com/documents/docs/DOC-40850
5. Archiving old data
It is important to keep a check on the data volume in production environment, as it can cause performance issues later. Since data usually accumulates over a period of time the performance degradation may not be immediately noticeable. To avoid accumulation of data and keep the system clean, it is important to monitor the data volume. Special focus should be on objects that have lots of data or are expected to grow quickly. Archival process is typically determined by the compliance and need to retain data from business or troubleshooting perspective. Archiving can be done either via custom code or via SAP provided tools.
Overall, remember that the data you choose and the amount of data that goes to a mobile device can significantly affect the speed of initial downloads, delta calculations and performance of the application itself.
Following are the key points to keep in mind from a performance perspective when designing a Mobile application solution.
1. Choosing the right data
2. Cardinality
3. Scalability of the system
4. Load Testing
5. Archiving old data
1.Choosing the right data:
Often in the Mobile world designers are guilty of sending too much data on the device. Always remember that Mobile devices are usually required to replicate only a subset of the Backend operations and not the entire functionality. Be clear with the scope and try to restrict your data model to incorporate only the objects that are needed on the device. For e.g.: if you are replicating a pricing functionality then the complex pricing logic can be actually be on the Backend and the device just makes an online call to retrieve the information. That way device doesn't need to store all the pricing related data.
2. Cardinality:
This is a very important and often ignored aspect towards performance considerations. Cardinality is basically number of records between two nodes. Usually, it is between parent node( root node/ header table) and the child node. Try to design your application in a way that the most frequently needed data is at the parent node. This will avoid traversing one level lower for records if they were at child node level. The amount of data and filtering on child node can impact the performance of the application and/ or the Middleware. Consider the following scenario: Device application needs all the products of a company to be sold to generate the invoice based on the products selected. Let's assume the company has 50,000 products. Now imagine that the application also stores the local warehouse related information for each of the product. The local information will be stored in the child node. But if the company has 500 warehouses countrywide, it will mean the number of records in the child node will be 50,000 * 500 = 25 Million. This will take up significant memory as well as time to be passed between the systems. Also, if the application has to search through any local information about a single product it has to search through these 25 million records thus, impacting the application performance.
3. Scalability of the system
Once you understand the cardinality of the objects and their relationship to other objects, then the next logical step is to do the calculation for all the objects and determine the number of records for each object. This helps in determining the peak load on the system which is important for scaling the system. For SMP SAP already has a quicksizer tool that determines how many SAPS the system should be scaled for. The quicksizer covers only certain scenarios like online apps etc. For more information on quicksizer for SMP 3.0, you can read the following blog: https://blogs.sap.com/2014/06/25/smp3-sizing-with-sap-quicksizer.
In general, you can look at the performance and sizing guides provided by SAP and can work with your BASIS expert for scaling the system.
4. Load Testing
Once you determine the peak load and scale the system, it's also important to load test the system in order to avoid any surprises later.This can be done via custom scripts or using various load test tools like HP Load Runner etc. Ideally, try loading the data in QA environment first and then move it to production. It will serve as a good benchmark and will help you determining the right strategy for Production move. You can check the following link to read more about load testing on SMP: https://archive.sap.com/documents/docs/DOC-40850
5. Archiving old data
It is important to keep a check on the data volume in production environment, as it can cause performance issues later. Since data usually accumulates over a period of time the performance degradation may not be immediately noticeable. To avoid accumulation of data and keep the system clean, it is important to monitor the data volume. Special focus should be on objects that have lots of data or are expected to grow quickly. Archival process is typically determined by the compliance and need to retain data from business or troubleshooting perspective. Archiving can be done either via custom code or via SAP provided tools.
Overall, remember that the data you choose and the amount of data that goes to a mobile device can significantly affect the speed of initial downloads, delta calculations and performance of the application itself.
- SAP Managed Tags:
