pasoe: transactions 736% faster than with classic appserver

The secret is in understanding the test conditions that produced that number.

The test program was OpenEdge's Automated Teller Machine (ATM), which has been in use to measure database performance from an ABL client ( in transactions ) for many years.   The test is database intensive where a large number of clients execute a few remote requests that result in large amounts of database interaction.   The test's focus is database performance from an ABL session and not application server response times.

The test was executed two different ways: bound clients (equivalent to state-aware), and unbound clients ( equivalent to stateless/state-free).   The results above show the faster of the two: bound clients where the application server requests did not have to pass client context on each request, thus lowering the network traffic overhead.

The test environment was a fast multi-cpu (24) Linux server with 16GB of memory, driven by ABL clients running on a Windows 7 OS over a fast LAN segment.

The test compared equivalent configurations where ABL clients connected to the classic AppServer and PAS for OE using tunneled HTTP connections.

   client --> AIA(Tomcat) --> AppServer

   client --> PAS for OE (using APSV transport)

The same number of ABL sessions were used in both configurations.  The classic AppServer using its one ABL session per OS process with a private shared memory connection.  The PAS for OE using one OS process holding many ABL sessions, where all the ABL sessions share a single shared memory connection.  The ABL test code and OpenEdge database are the same for both configurations.

OpenEdge engineering has spent a good amount of time looking for a definitive answer, which has so far eluded us.  Profile and test results are very consistent when using different Linux servers ( adjusted for hardware speeds ), so the increase ABL database access is real.   The best consensus is a combination of faster thread switching using a single shared memory connection in the PAS for OE agent, plus faster client to application server communications than the equivalent AppServer configuration.  

That is how the database performance number was attained.

Thanks Michael for shedding some light on the test method. The first thing which comes into my mind, what if you leave AIA (in the classic setup) out of the equation?

Our testing shows that when you run a classic AppServer with direct TCP/IP network connections versus PAS for OE ( still using the HTTP tunneling ) the test results show equal TPS performance.   Generalization: the improvements in PAS for OE's multi-session agent and ABL database connection are cancelled out by its HTTP tunneling.  

Thanks Michael, while that makes sense however it also beg the question... why did the other connection models got dropped and only http(s) one was kept?

Understand the focus in on pacific/cloud and http makes sense here but still there are plenty of cases where progress client is used with an appsrv, those could benefit from the new improvements while not having to bother with the http tunneling overhead.

Jeff, my understanding was the new PASOE will only work with HTTP connection - the AIA tunneling available in previous APPSRV.

Mike, tomcat it's just an application server and since everything ends up to be simply moving data over sockets the actual protocol used there doesn't necessarily need to be HTTP... the broker might well speak several languages/dialects ;)

Hi Marian,

A very reasonable question.    What we found out by prototyping was that Tomcat's 'connector' technology (i.e. network socket) is very tightly bound to serving HTTP requests, scheduling threads to execute those HTTP requests, and calling web application contexts to execute those HTTP requests.  We looked at a number of ways to leverage the connector interfaces and have it function as generic TCP/IP connection server for direct OpenEdge client connections.   Alas, no joy.   We also looked at bypassing all of Tomcat's connector technology and writing a whole new multi-client socket server module, but ran into issues with consistency in thread pool management, valves, and container security.   Thus the story ended... for now.

Not to say we are content with the first release's HTTP tunneling speed.   The story will continue...

Michael, kudos for honest and detailed answer... using what is already available in tomcat for the first iteration makes indeed a lot of sense and I'm sure you guys will find a way to nail that down and get back 'native' connection modes in PASOE.

Think it's safe to say those not using the AIA (http tunneling) in their appsrv solution would rather keep on using the 'old' appsrv for the moment as there is no real over-all performance improvement by switching to PASOE and do the upgrade when direct connections will be made available in PASOE... wait for the story follow-up ;)

Great job nevertheless, will see how a node.js appsrv will behave but that's another story though :)

I disagree. There may not be any significant performance improvement in a resource rich server, but doesn't the model still consume less resources (memory, cpu etc) and hence allows for better scaleability as a result.

The fact you can have "1 appserver session per client" and lock the two together is the big win, all other things being equal.