PASOE Performance

Posted by Blake Stanford on 03-Oct-2018 09:56

At Progress Next this year there was a presentation I went to on why migrate to PASOE.  In that session there were some caveats mentioned, one was that inefficient coding practices would be magnified under load, I've heard this from others at Progress as well. We are getting ready to migrate to PASOE, it would be nice to get any inefficient coding addressed before it becomes a problem in production.  Does anyone have examples of inefficient coding practices that have caused performance issues when migrating to PASOE?  

User Conferences - Forum

All Replies

Posted by Peter Judge on 03-Oct-2018 12:24

There are 2 that spring to mind
 
  1. On Windows specifically, running out of file handles since they’re per-process, and if a session does a lot of read/write to files on disk (for caching before- and after-request data, say) , then there’s a danger of running onto those limits

 

  1. Memory usage: because the classic AppServer has one ABL session per process, that session has to be a real hog before the process memory gets excessively large. With 100+ ABL sessions per process in PASOE, the behaviour can be less bad per session, but with the multiplier easily grow very large.
 
 
 

Posted by Blake Stanford on 03-Oct-2018 12:50

Thanks, Most of our customers are running the appservers on a UNIX machine.  We will be state-free with the agent being self service, at least until the remote connection performance is better.  We try to have as much r-code stay in memory as possible, large -mmax and -D parameters.  We also use a local .pl for the code to minimize writing to the r-code swap file.  Would those same parameters apply with PASOE?

Posted by Peter Judge on 03-Oct-2018 15:24

Yes, you can.
 
There’s a quick start guide at community.progress.com/.../3455 which has a bunch of good info in it.
 

This thread is closed