Perfmon on B1 SDK - CPU, Memory, Disk

[dcrovetto]

Hello, all,

I need to track the CPU, Memory and Disk impact of running different SDK tools for SAP Business One. I have decided to use Windows' Performance Monitor (perfmon) for this analysis. For such, the metrics/counters I'm currently opting for % processor time, private bytes, and IO/s data bytes for each process involved in the tools' operation cycle or stress test.

I'm planning to monitor DI API, UI API and Service Layer related tools.

Which processes should I keep an eye out for each application? My guess is the SAP B1 executable as well as the add-on/application executable(s) should be a given. But which other processes might be impacted by one or many SDK tools that I might need to keep an eye out for as well during monitoring?

Thank you in advance.

[AlexGourdet]

Thank you for visiting SAP Community to get answers to your questions.

As you're looking to get most out of your community membership, please consider include a profile picture to increase user engagement & additional resources to your reference that can really benefit you:

• Profile https://developers.sap.com/tutorials/community-profile.html
• Tips for Questions: https://community.sap.com/resources/questions-and-answers
• Consider to take our Q&A tutorial at: https://developers.sap.com/tutorials/community-qa.html.

I hope you find this advice useful, and we're happy to have you as part of SAP Community!

All the best,

Alex

[Johan_H · Accepted solution]

Hi Domenico,

The first thing that comes to mind, is that B1 is database driven. Meaning that the heavy lifting is done by the database.

I don't know why you need to monitor the performance of B1, but if it is because you are trying to solve performance problems, you should look at the server the B1 database is running on.

If you are experiencing performance problems in the drawing of certain B1 client forms, they are 99% of the time due to datagrids. This is because a lot of the datagrids in B1 are set to refresh at every change in represented data. That means that when a formatted search or an addon updates data in a datagrid, each time data in any cell is updated, the whole datagrid is redrawn. This is a reason to avoid the 'Refresh regularly' setting in formatted searches. In version 10 a lot of these issues have already been addressed, so if you are running an older version, then upgrading will also help you.

The next cullprit is likely your network and/or some process (report or addon) using large data sets. So you may want to monitor your network, and/or make sure that addons use stored procedures in favor of local processing.

Regards,

Johan

[dcrovetto · Accepted solution]

Hello, Johan,

It's not as much an inquiry about B1's performance itself, but more about what aspects or processes might see themselves impacted by different types of SDK applications. More akin to a benchmark of the applications themselves. So my idea was to also take B1's own processes into consideration as well.

Thank you for the pointers. Database and network impact will be a useful angle to consider too.

With all this in consideration, there wouldn't be other B1-related windows processes I should monitor that may see themselves impacted by running a DI API, UI API or SL addon or application, correct?

[Johan_H · Accepted solution]

Hi Domenico,

That is correct. The DI API is the data interface, but that really only means that it mainly runs stored procedures, and such on the database, and only a little bit of logic. Thus its local impact is neglibile. The UI API is an interface to manipulate the B1 client GUI, so only affects the B1 client. If it has any impact at all, it will only be on the B1 client process.

Now an addon, or application is a different story, because it could theoretically access any resource locally and on the network. Obviously it is also entirely possible that it was built to process large datasets locally. It all depends on what the addon or application is supposed to do.

Although you said that it is not about performance persé, I do want to mention two less obvious factors in performance, that may also impact benchmarking:

1. A common mistake in database setup is to not limit the amount of RAM the database server is allowed to use. This means that during peaks, the database can hog all RAM resources, and thus throttle the operating system, which in turn will then throttle the database right back, and also any other applications running on the server. Meaning that this may warp your readings.
2. An application can unwittingly put a lock on a database table, and thus block itself or another application. This again can warp your readings, as an application appears to be impacted, even though it is not actually using any resources.

Regards,

Johan