I am emulating classic statefree appserver in PAS with a remote .Net openclient using the APSV transport.
If I do some profiling with procmon, there appears to be 5ms overhead on the front end (when a request for a database record arrives) and also 5ms on the back when the ABL results are returned. The 5ms + 5ms overhead apears to be the local chat/cpu interaction between the tomcat (java.exe) process and it's OE agent (_mproapsv.exe).
There is a remaining amount of time that consists of the work in the agent client/server code (ABL) that retrieves the record from a remote database. This work can take about 5ms since it uses a client/server protocol on the network.
These are the very fastest possible round-trips I've seen so far out of the APSV transport (usually 15-20 ms as observed by remote openclient). In contrast, we had been getting fast 5-8 ms round-trips with classic statefree appserver clients. These small delays may not seem much, but if a complex U/I makes 10 or 100 round-trips to redraw a screen then it becomes a delay that can be certainly noticed by a user who is banging away on updating their data.
Does this (~10 ms) overhead on the APSV sound right? Is there a faster transport that we might start looking into now that we are using PAS? Thanks in advance.
David,
We regularly run tests on various clients including Windows system with a .NET OpenClient, looking for client response times. The testing’s goals are to identify internal locations that slow the client response times. For example: this test’s OpenClient makes a APSV call and returns back a JSON as a longchar. The server creates a copy of each record of a customer table to a temp-table and at the end we write that the datasets to a longchar. Attached the dotnet client and ABL program. For this test the default PASOE configuration was changed to run: 1 multi-Session Agent; execute up to 200 concurrent ABL requests. The conf/openedge.properties settings used in this test appear after the chart.
When running the test on one of our internal 2CPU Windows boxes, the results are as below. (NOTE: the results will vary based on the kind of system you are running or kind of ABL code you are running).
The %DIFF in RED means that PASOE has a slower client response time than a Classic AppServer; in GREEN show faster; in BLUE shows almost equal response time than a classic AppServer.
| Windows test - 2 CPU machine(Average Execution time in millisec) |
|||
| PASOE | Clients | %DIFF | |
| 1Client | 91 | 86.6 | 5.08% |
| 5Clients | 427 | 443 | -3.61% |
| 10Clients | 904 | 1021 | -11.46% |
| 15Clients | 1413 | 1411 | 0.14% |
This test’s response is pretty typical and shows running PASOE with one client does not represent the optimizations gained by its multi-threaded and multi-Session architectures.
maxABLSessionsPerAgent=200
maxAgents=1
minAgents=1
maxConnectionsPerAgent=200
numInitialAgents=1
maxSessionsPerAgent=200
David,
We regularly run tests on various clients including Windows system with a .NET OpenClient, looking for client response times. The testing’s goals are to identify internal locations that slow the client response times. For example: this test’s OpenClient makes a APSV call and returns back a JSON as a longchar. The server creates a copy of each record of a customer table to a temp-table and at the end we write that the datasets to a longchar. Attached the dotnet client and ABL program. For this test the default PASOE configuration was changed to run: 1 multi-Session Agent; execute up to 200 concurrent ABL requests. The conf/openedge.properties settings used in this test appear after the chart.
When running the test on one of our internal 2CPU Windows boxes, the results are as below. (NOTE: the results will vary based on the kind of system you are running or kind of ABL code you are running).
The %DIFF in RED means that PASOE has a slower client response time than a Classic AppServer; in GREEN show faster; in BLUE shows almost equal response time than a classic AppServer.
| Windows test - 2 CPU machine(Average Execution time in millisec) |
|||
| PASOE | Clients | %DIFF | |
| 1Client | 91 | 86.6 | 5.08% |
| 5Clients | 427 | 443 | -3.61% |
| 10Clients | 904 | 1021 | -11.46% |
| 15Clients | 1413 | 1411 | 0.14% |
This test’s response is pretty typical and shows running PASOE with one client does not represent the optimizations gained by its multi-threaded and multi-Session architectures.
maxABLSessionsPerAgent=200
maxAgents=1
minAgents=1
maxConnectionsPerAgent=200
numInitialAgents=1
maxSessionsPerAgent=200
Thanks Irfan. I have been quite happy with the tomcat/mproapsv performance for the most part. I think PAS is faster in the places that matter.
The only thing I noticed is the same as what you showed in the table - there is a fixed cost overhead for single-threaded clients which, while it is small, it is a little more than what we had in classic appserver . If the fixed cost is 10 ms and the work being done takes only 3 ms, then the overhead is relatively large as a percentage. I have a number of examples where PAS is slower because a lot of small, single-threaded requests are being done in tight loop.
The good news is that a well-designed front-end can either be re-worked to incorporate more business logic into a single round-trip to appserver, or it can leverage parallel or async coding techniques to make multiple requests at the same time (which is where PAS really shines).
Another thing that came to mind insofar as my APSV clients are concerned is that, even though they are "state-free", I think they are still using persistent procedures (for the sake of the proxygen-built proxies). This means there are additional round-trips to create the persistent procedure up-front and then to delete it at the end. Those round-trips are probably more expensive than they were in classic appserver, and they may be where the higher fixed overhead in PAS comes from. I've been meaning to test out the "SINGLE-RUN" feature for making a single request on a state-free agent. I suspect that might substantially diminish the 10 ms overhead. Unfortunately I don't think proxygen for .Net will help to facilitate that type of round-trip by default. (You have to program against the dynamic "OpenAPI" functionality as outlined here: documentation.progress.com/.../index.html. Note that this would still use the APSV transport, but perhaps a faster form of it.