Looking at the documentation on Server-Side profiling for PASOE, I'm not seeing where it says what versions this is available for. My 11.7.4 install doesn't have oediagstore.df or oediagstore.war. My 12.1 install does have it.
What is the earliest version this works in?
Also, do I understand correctly that you only will get a collection of individual .prof files for each request? Is there a way to combine the files for a consolidated view?
Thanks.
Server-side profiling for PASOE was first available in 12.0. And yes, the .prof data is collected and pushed via a background thread for each request. There is not a way to combine the files for a consolidated view (yet). Interestingly, we were just talking about this very thing yesterday afternoon. Do you think it will be important to be able to do that? I can imagine a use-case, but it's better if I hear yours.
Tim, I do think that having a profile of all requests over a period of time is as useful as individual requests. In my experience, people seem to have problems like this: "Every morning around 8:50, the system slows down and nobody can get anything done."
It's good if you have suspects to look at, but sometimes you just need to see what's running, and how long it's taking. It could be that a given piece of code is used in multiple places, and run very frequently. It may not stand out that much looking at a single object, but could float to the top as a culprit if the profile said it was burning up a lot of processing time overall.
In the past, we've done this by embedding on/off commands in the ABL app itself to allow a system admin to toggle it via WebSpeed, but as you know it gets tricky to have a request hit the right agent, and coordinate them to do it. Would love to have this ability in PAS.
Server-side profiling for PASOE was first available in 12.0. And yes, the .prof data is collected and pushed via a background thread for each request. There is not a way to combine the files for a consolidated view (yet). Interestingly, we were just talking about this very thing yesterday afternoon. Do you think it will be important to be able to do that? I can imagine a use-case, but it's better if I hear yours.
Tim, I do think that having a profile of all requests over a period of time is as useful as individual requests. In my experience, people seem to have problems like this: "Every morning around 8:50, the system slows down and nobody can get anything done."
It's good if you have suspects to look at, but sometimes you just need to see what's running, and how long it's taking. It could be that a given piece of code is used in multiple places, and run very frequently. It may not stand out that much looking at a single object, but could float to the top as a culprit if the profile said it was burning up a lot of processing time overall.
In the past, we've done this by embedding on/off commands in the ABL app itself to allow a system admin to toggle it via WebSpeed, but as you know it gets tricky to have a request hit the right agent, and coordinate them to do it. Would love to have this ability in PAS.
I have had to troubleshoot situations where making the same AppServer request with identical inputs would slow down over time.
Being able to build a working set of .prof files and comparing them in a side-by-side view helps a lot there to see how the profile evolves over time.
In that particular case, combining the profiles for multiple requests into an overall profile wasn't as useful.
Combining multiple .profs *is* more useful when you're not sure yet what you're looking for - the basic use case being to identify potential bottlenecks during stress testing.
A function that gets called from many requests may not apear to be a suspect from a single request's .prof. But if combining a set of .profs shows that's where 15-20% of the total time is spent, you may want to give it a look anyway.
Hi,
We have been looking to facilitate diagnostics with AppServer as well (still on classic AppServer, OE 11.7).
Couple of things we do:
- Propagate client log settings from remote client to AppServer agent: In the Activate procedure on the agent, we apply client log settings of the requesting client (from context) and we set them back in the DeActivate procedure. Advantage is that you can selectively activate appserver client logging iff it comes from your remote client only. Same goes for other diagnostic settings like Profiler settings. Each request goes to a seperate prof.out file, but I can imagine you sometimes want otherwise.
- From the remote client, run code which scans your appserver agent (SESSION:FIRST-BUFFER, FIRST-QUERY, FIRST-OBJECT) and send the data back in a dataset to the client. Run the same code on the local client and provide them in a UI, useful to detect memory leaks on client + appserver agent together (compare snapshots). BIND the appserver agent to your client by running a persistent proc on it. That way you - and only you- will land on that agent. After all, you appserver agent/session is an extension of your client session. You can also scan the TempTables of your appserver agnet and see what's inside.
FYI
Bart
Thanks, that's helpful to know. I could imagine solving this in a couple different ways:
1) Allow specifying that the profiling data be collected across multiple requests but generate a single .prof file -- this data would then be per ABL Session and the agent could be configured to write the data after N requests or when a session is shutdown.
2) Post-process the .prof files and merge them into a single .prof file.
The down-side of the first approach is that you can't control which ABL Session will handle which requests (unless you bind the session to a given client). ABL Sessions are chosen based on a most recently used basis, which directs all requests to the same ABL Session on an unloaded (single driver) system, but as soon as its loaded with multiple clients, the request distribution will be somewhat random -- some .prof files might hold lots of request data while others might hold very little.
If the post-process was fast and accurate, I think that'd be the way I'd approach it.
[mention:22b6240a52bb4d568001986a6aa726a8:e9ed411860ed4f2ba0265705b8793d05] wrote:
> Combining multiple .profs *is* more useful when you're not sure yet what you're looking for - the basic use case being to identify potential bottlenecks during stress testing.
Thanks, that's helpful.