PASOE Configuration

S

Steve Simpson

New Member
We have an application we are about to move over to OE12.8 from 11.7 and I'm starting to look at PASOE. The developer of the application we use has been a little cloudy on performance tuning with PASOE, despite the config page having a specific section on performance tuning! I've looked at the defaults and the definitions in the Progress documentation. Having compared that to the default settings recommended by our provider I feel like there is something more efficient to be had out of the config.

I was wondering if anyone knew of anywhere to look to get a more detailed explanation on PASOE performance tuning? Perhaps something with guidance on what to look for in your application to determine the best settings? Our provider is also looking at making the application run lean. That is fine, but in our setup we are running OE on a VM in the public cloud and I'm happy to make the VM work as hard as I can to extract the maximum value out of the cost.

Thanks in advance.
 
There is no "if you are using PASOE, change parameters X, Y, and Z like so" guidance.

From a database perspective PASOE is just another client. You would make tuning changes to the db based on the planned client configuration and your expected workload - whatever that might be. If the PASOE clients are going to do more work, or change the demands on the db in some way then you would tune for that. But to do that you have to know what *your* workload is going to look like.

How do you know what *your* PASOE workload is going to be?

Good question!

If it is a "lift and shift" from "classic appserver" then it might be reasonable to go with "not much change expected".

If it is a re-thinking of the old appservers then I would start by getting a handle on what the vendor has to say about the objectives of that rethinking were.

A wrinkle would be if the workload hasn't changed much but the nature of the deployment has -- maybe classic was shared memory and PASOE is "dockerized" remote clients. If something like that is going on then you need to deal with the impacts of remote clients and so on and so forth. But that's not because of anything unique to PASOE driving a tuning change. You _could_ have done similar things with classic appserver.

Another wrinkle would be that someone has changed servers, storage subsystems, or something about networking at the same time as the migration. Of course those changes will all be completely innocent and utterly transparent to users :rolleyes:

I would also want plentiful before & after data. If you're collecting data about the current 11.7 database and appservers and you can compare that to the migrated system that will go a long ways. First use it in testing to ensure that your testing reflects reality. Then use it in production to support the need for any changes.

Regardless - I would want to be doing a lot of testing to see if anything has changed and to quantify the nature of any changes. Then I would tune.
 
TomBascom said:
There is no "if you are using PASOE, change parameters X, Y, and Z like so" guidance.

From a database perspective PASOE is just another client. You would make tuning changes to the db based on the planned client configuration and your expected workload - whatever that might be. If the PASOE clients are going to do more work, or change the demands on the db in some way then you would tune for that. But to do that you have to know what *your* workload is going to look like.

How do you know what *your* PASOE workload is going to be?

Good question!

If it is a "lift and shift" from "classic appserver" then it might be reasonable to go with "not much change expected".

If it is a re-thinking of the old appservers then I would start by getting a handle on what the vendor has to say about the objectives of that rethinking were.

A wrinkle would be if the workload hasn't changed much but the nature of the deployment has -- maybe classic was shared memory and PASOE is "dockerized" remote clients. If something like that is going on then you need to deal with the impacts of remote clients and so on and so forth. But that's not because of anything unique to PASOE driving a tuning change. You _could_ have done similar things with classic appserver.

Another wrinkle would be that someone has changed servers, storage subsystems, or something about networking at the same time as the migration. Of course those changes will all be completely innocent and utterly transparent to users :rolleyes:

I would also want plentiful before & after data. If you're collecting data about the current 11.7 database and appservers and you can compare that to the migrated system that will go a long ways. First use it in testing to ensure that your testing reflects reality. Then use it in production to support the need for any changes.

Regardless - I would want to be doing a lot of testing to see if anything has changed and to quantify the nature of any changes. Then I would tune.
Click to expand...
Thanks for these insights Tom. I'll certainly be doing lots of testing! I'll head back to the vendor, but I feel like they have made the change out of necessity when moving to OE12. That's at least the feedback I've had. The object code behind the PASOE I am told is the same as for classic appserver save that it has been compiled in OE12. Hopefully just a lift and shift, but we will see.

Thanks again for taking the time.
 
The documentation has helped a lot. Our vendor has said that their PASOE is only such because of the need in OE12. Looking at the Progress documentation I came across the paspropconv utility and have used that to extract some detail about our current classic appserver and gathered up some potential new config. I've shipped that off to our vendor to see what they think. @peterjudge @TomBascom @Osborne
 
You must log in or register to reply here.
Back
Top