EDIT: With the invent of "Telemetry" in v.23, p.4 - 9 are now deprecated. Just use Telemetry to provide the information!
Each performance related ticket might have different requirements. This topic will try to summarize some of the more common requirements and must-reads. This is a kind of check-list when opening new ticket:
1. Problem, Steps To Reproduce And Target
If we have to solve a problem, we have to know what it is. Right? Well, you cannot imagine how often this is forgotten. Nevertheless, I cannot stress enough how important is this.
For example:
Bad: The system felt sluggish yesterday.
Good: Releasing document X took 20 seconds.
Ok, you say, but what to report when the system actually feels sluggish for everything? Well, just report that, but also choose any operation you deem important for you:
"The system feels sluggish today. For example, releasing document X took 20 seconds".
NOTE Please measure the actual time of the slow operation and include this in the ticket. This way it is documented what the situation was and we can measure if there is an improvement.
Bad: Releasing document X is slow.
Good: Releasing document X took 20 seconds, which is slower than expected.
Best: Releasing document X took 20 seconds, but I expect it to take maximum 8 seconds in order to be able to serve my customers adequately.
2. Performance Degradation?
Observe (and include in the ticket) whether the behavior is performance degradation or not. E.g., is it something that has been working "normally" before, but now is slower. Or maybe this is something that you run for the first time and it just seems (a bit 😉) sluggish.
Bad: Releasing document X took 20 seconds.
Good: Releasing document X is now 20 seconds, but up until yesterday it was always around 5 seconds.
Ok, "Releasing document X took 20 seconds" was good, now it's bad? Well, we have to introduce to you the intrinsics of good performance tickets little by little 😉.
3. Does It Vary?
It is VERY important to observe whether the slowness is the same each time you execute the behavior.
a) If the speed varies in wide ranges, this is more probably dependent on general pressure on the servers.
b) If the speed does not vary, then it is more complicated and depends also on the answer to p.2 above.
Bad: I released document X and it took 20 seconds
Good: When I release sales documents today, they take anywhere between 5 and 50 seconds. Document X for example took 15 seconds.
4. Everything You Know
Please, PLEASE, include everything you think may be related to the performance problem. People usually think that the support engineers will somehow know everything, but, unfortunately, that's not the case. We do have many performance counters and yet, simple explanation might save countless hours.
For example:
Bad: I have a performance problem with releasing document X.
Good: My colleague started the cost recalculations and now I have a performance problem with releasing document X.
5. The Balloon
When the performance problem is related to:
- changing the state of a document
- running printout
- any other server-measured operation
do the following:
- If you are using the Desktop Client, go to File/Settings
- Turn On "Performance Benchmarking Mode"
- Execute the operation again
- Wait for the notification balloon at the end, which contains the detailed performance data
- Copy the text and paste it in the ticket.
6. The Call Log
When there are many small calls from the client to the server, the Call Log will be required in the support ticket. To find if there are many small calls (and not 1 giant call), you can use the Exec Stats info (p.8) or just follow the procedure here. If there is a single call to the server, the call log is not so useful.
Usually, if the ticket is for slow loading of a Navigator, the Call Log is not important. But, when dealing with slow screen forms, Call Log is usually required.
To include the Remoting (or Data Transfer) Log:
- File/Settings
- Show Remoting Log
- Execute ONLY the troubled operation
- Focus again on the "Data Transfer Log" page
- Click Refresh
- Click Print and save as PDF
- Attach the PDF in the ticket
7. The Network
Using the Call Log data from the previous recommendation, you can quickly check the latency of your network connection. Observe whether the "small" packages go in and out of the server "quickly". Ok, but what's "small" and "quick"?
Generally, the Desktop Client makes a lot of calls whose size (Request,B + Response,B) is between 1000 and 2000 bytes. Ideally, these should have "Network, ms" in the range 4-8 ms.
Also, it is important to notice whether most such requests have similar "Network, ms" times. If the times vary a lot, like going to more than 100, there might be a network problem.
8. The Exec Stats
Exec Stats might reveal the performance of various internal operations inside the server. Therefore, it can contain important data about performance problems. In the Windows Desktop Client do the following:
- Go to Main Menu / Setup / Tools / Exec Stats
- Click "Refresh"
- Execute the slow operation
- Refresh Exec Stats again and try to spot the differences
- Copy the data about stats you think might be related to the problem
- Paste in the ticket
9. The Memory Usage Option
If you are using the Desktop Client, this might affect the performance of the whole client:
- Go to File / Settings / Memory Usage
- Ensure that "Maximum memory usage for max speed" is selected.
10. The Information Messages
It is very common that the system KNOWS there is a performance problem and it has been trying to tell you this, but you just wouldn't listen! 😎
Ok, seriously, just go to Information Messages and check. Your solution might be right there. In the Desktop Client:
- File / Settings / Tools
- Start Information Messages
- Filter for today and Refresh
- Look for messages around the time of your problem.
This article is so good, that we hope that while you were trying to collect all the required information, you already found the culprit and solved it yourself 😎.
0 Comments