I'm not sure how many use it like we do, but we make a lot of small round-trips to our state-free appservers.
After we upgraded our network to 10 Gbit we expected performance would be much improved on the network level. Unfortunately we didn't see much of a performance change on the HP-UX side, but our Windows-based appservers became quite a bit faster.
After we started investigating the reason for the difference in performance between the two platforms, it turned out that a substantial amount of our state-free activity had a huge 50-100 ms overhead per *round-trip* on the HP-UX side, but *nothing* like this happened on Windows. (On the Windows side, our appservers were extremely fast - . ~4 ms - but on HP-UX the same activity was averaging ~60 ms on the state-free round-trips).
We reported this initially as an HP-UX-specific bug. But at the end I was extremely surprised to find out that this affects Linux installations of OE appserver too. So I thought I'd put a message out here in case anyone on the Linux platform might benefit from faster appserver calls. IMO you may gain even more by this fix than by other types of optimizations (eg. singleton, single-run, or whatever).
Hope this helps. David
Thanks for sharing that good news. Do you know if the same issue existed for the new PASOE, and if so whether that will be improved in 11.6.3 as well?
Thanks,
Mark
Thanks Brian,
That makes sense, but I thought it wouldn't hurt to ask. :-)
Mark
I'm not sure about PASOE. I've never gotten a chance to try it out yet. One thing I will say is that you should benchmark your performance on your appserver calls and get a good feel for how long they should be. The difference between ~60 ms and ~4 ms may not seem much, but when you multiply by x10 or x20 different round-trips - in order to display a variety of data to the user - it makes all the difference in the world between a snappy U/I and a sluggish one.
I'd also suggest using the "process of elimination" - take the network out of the equation and connect from the same machine, or take PASOE out of the equation and run the same underlying code directly from the Progress editor... You get the idea... Then review your changes and your numbers to see if the performance increases between each of these scenarios seems reasonable.
For me one thing I will *always* include in my troubleshooting is a step where I take the HP-UX platform out of the equation, and try the same OpenEdge repros on Windows. It doesn't pay to be running on a stale/legacy platform, no matter how "mature" or "reliable" people say it is. I think the best possible scenario is to use the *same* platform that the OE product development team is using to get their work done (ie. the platform where they are actually doing the work on the features and performance optimizations like "singleton" and "single-run"). Otherwise there is always a potential for stuff to be lost in translation during a port to another platform - especially in relation to non-trivial things like performance.
If you talk to Mike Jacobs, you will never use classic AppServer again.
Maybe they need to rerun their PASOE performance comparisons - now that the overhead (~50ms-100ms sleeping time) has been removed from classic statefree appserver (in Linux and UNIX). A turtle that is awake moves faster than a jack-rabbit that is asleep.