G
Gareth Vincent
Guest
I'm assuming that it is the same hardware configuration for PASOE and classic. The hardware is exactly the same and with no other configuration changes Can you isolate the processes that are consuming the most cpu? The _mproapsv process is consuming the bulk of the CPU load on the Linux server which is hosting both the DB and Appserver . "If I understand correctly, for both classic and PASOE you are running the appserver on the same host as the database, with a shared memory connections. The remote clients are using the APSV transport in both cases, and are connected very distantly (over the WAN from another continent)." Correct, geographically the server is hosted in our Data Center here in South Africa and all the connections are local via a WAN connection. If that is correct then I think you are dealing with at least two different issues. I would suggest breaking the issues apart and working on them separately. Your application crashes, first of all, seem to be happening while interacting with the OE database in shared memory on a single host (both in the case of "classic" and PASOE): Yes I do believe we are dealing with two different issues here. One is the disconnect and the other is performance related. We are not experiencing the same issue with "classic". The classic appserver seems to handle these "disconnected sessions" more gracefully. It is worth noting that we have moved several customers over to PASOE over the past year and a half with good success. The only difference is that these customers are what we call "in-house" customers whereby they host their own servers onsite so most of these clients have been connecting over a LAN. From a user count these have also been relatively small so the comparison is not quite the same. I think I've gone through all the PASOE performance documents that has been published (including the links that Roy Ellis provided). I've applied various configurations, none of which gets me even close to classic appserver model baring one configuration change. If I increase the amount of agents and limit the agents to 2 sessions each i start seeing a noticeable improvement on the CPU load. This forces requests to be serviced by multiple agents rather than just one. The way I see it i'm essentially mimicking the classic appserver model which kind of defeats the point. The expectation is that the multi threading agents should provide much better performance and provide better scalability. I'm not seeing either. With roughly another 200 Databases to migrate over to PASOE, I'm reluctant to move any of them until I can address the performance/load issues we are currently experiencing.
Continue reading...
Continue reading...