Can AppServers be run with a lower process priority?

[Stefan]

OpenEdge 10.1C / 10.2B
Windows / Linux AppServers

I am looking into spreading the workload passed to AppServers based on the function executed. For example all user interface actions should be handled directly, all reports can be handled at a lower priority. The lower priority is required to prevent reports from hogging CPU and not giving the ui AppServers a decent chance to respond.

I can achieve this by using at least two servers with AppServers but it seemed to me that it should be easy to do on one server by simply starting one of the AppServer brokers with a lower (Windows) priority. I have found the 'priority weight' setting in AppServer broker properties but this seems to be for load balance across machines only.

I could attempt to lower the priority from within ABL but that seems just plain dirty and that will probably require the AppServer to be started with admin'ish rights.

We already have the option to schedule reports etc, but users like being able to work with report interactively, we only need to ensure that they do not hog the system.

Any thoughts?

 

[TomBascom]

I'd be very, very hesitant to do it at the OS level. That sort of thing almost always backfires.

If I wanted to throttle reports I think that I would do it by having the report app server connect to the db client/server at a dedicated broker. I would then setup that broker with a limited number of servers and put large numbers of clients on each server. If, for instance, I needed to support 100 report app server sessions I might have them connect to a server with -Mpb 5 -Ma 25 -Mi 1.

I would then make sure that my "UI" app servers connect as self-service sessions.

 

[GregTomkins]

We do this a completely different way ... the AppServer is called just to insert a "please run this report" request into a batch queue, which is nearly instantaneous (as we hope all of our UI operations are). Then a completely separate, appropriately tuned, daemon (non-AppServer) process runs the jobs. We send back a notification when the job is completed (which can be seconds, minutes, or hours later).

There is fair amount of infrastructure behind this and we probably spent a fortune over the years getting it all to work the way we like. But at the end of the day I think it was worth it.

 

[FrancoisL]

We use replication for our reporting. There is one AppServer on the target Machine that register on the name server of the main machine who also has a appserver broker.

All large data query and reports are sent to the replicated App Server. The main UI work and updates are sent to the main machine app Server.

It requires 2 servers and the replication licenses but it gives us a reporting Server and a backup Server in case of a failure of the main server.

 

[Stefan]

Thanks for the ideas!

For now the approach, which allows Tom's and Francois' (heavy) configurations, will be to get the client to connect to an AppServer with the function prepended to its name (if AppServer name defined as asbroker, then additional connections will be made to asbroker-report, asbroker-ui etc). If only one AppServer is wanted, or a clustering of various roles, then the other names simply need to be added to the Application Service names list allowing configuration yet keeping all options open.