Concurrent requests issue on Pacific server

Posted by Eduardo Aceves Ledezma on 06-Mar-2017 09:47

Hi Guys!

We're having a problem with a Pacific server when multiple clients do a request, I'll explain myself:

We have a query that requires a high demand on the production server because the table we use has millions of records. That query normally takes 3 seconds to complete, but, as soon as you do this query multiple times using different clients, the execution times get multiplied by the number of clients, like 6 seconds when we do it with 2 clients, 9 seconds when we do it with 3, and so on.

The architecture of our application is RESTful, and the query doesn't involves any kind of exclusive locks.

Any suggestion on this case? Is there any other possibility for tunning for PAS or the RDBMS on this kind of scenarios?


All Replies

Posted by Irfan on 06-Mar-2017 10:17

Hi Eduardo,

Increase in response times is proportional to  higher load and concurrent clients. If I had to display this information in my browser application then I instead of getting entire data, I would get data based on pagination. Otherwise, you can also look for alternatives to cache the content instead of hitting the server for data every time.

Posted by gus bjorklund on 06-Mar-2017 23:56

perhaps you could try increasing the number of worker threads or arrange for the clients to use different agent processes.=

Posted by gus bjorklund on 06-Mar-2017 23:56

how many agent processes are you using?

what does your current configuration look like?

Posted by Eduardo Aceves Ledezma on 07-Mar-2017 11:24

Hi Irfan (isyed) ! and thanks for your answer. Is there any other possibility to solve this issue?
The thing is that even that we use different web browsers and computers, we get a lower performance than when we used AppServer classic.

Hi gus bjorklund (wizard) I'm using 10 Agents, increased the number of connections to PAS, the queue, the max concurrent sockets per agent was increased also, and we still get a worse performance than Appserver classic, as I've mentioned to Irfan. I'll attach the three config files that I've changed.



Posted by Irfan on 07-Mar-2017 12:50

Hi Eduardo,

What is the configuration you use to have with Classic Appserver ? The current configuration in PASOE looks fine. I am just curious why would you like to pull the entire data in one request instead of doing it periods ?

Posted by Eduardo Aceves Ledezma on 07-Mar-2017 13:10

Hi [mention:54e5df2f11a046ef89f0b4acd415e0d5:e9ed411860ed4f2ba0265705b8793d05] .

The data is pulled per day and by topic. This means that the query searchs between millons of records to take the ones of the specified day. After that, we filter those that have the topic we're looking for. Normally, the amount is about 300 or 400 registers per day (Sorry for not mentioning this before). Previous to upgrading to PAS, when multiple clients went to this module concurrently didn't have any kinds of performance issues (About 3 seconds on all of them). Right now, it seems that the amount of time gets multiplied by all of those who concurrently go and use this module (For example, that 5 clients get attented in 15 seconds  and, after that time, it responds to all of them at the same time). The idea was to know if, since they're local clients, they're getting attended by the same ABL session or something like that.

Together with this issue, it seems that PAS gets all the connections for the database, since another program we have to check database records keep showing that there aren't enough connections to the database available, and that we must increase the connection number by using the parameter -n in the .pf file. I don't really know if this is somekind related to the PAS perfomance issues, but, as I've mentioned multiple times before, This wasn't happening when we used AppServer classic.

Regards, and thanks a lot for your help!

Posted by Irfan on 07-Mar-2017 13:20


Do you filter your response at the client or in the server ? How many concurrent requests do you expect to run ? Your PASOE server is started with too many users which is causing the database to be out of connections. Configure something with the below formulae and you should be able to save some resources.

maxABLSessionsPerAgent=<max number of concurrent clients> + <some buffer>

maxAgents=<start with 1 and then move up>

maxConnectionsPerAgent=<same as maxABLSessionsPerAgent>


numInitialSessions=<average number of concurrent users>

Posted by Eduardo Aceves Ledezma on 07-Mar-2017 17:17

Hi Irfan,

I'm not filtering the server response on the client side, (I'm using Kendo Datasources by the way). The idea is to get at least 15 people working on this system at the same time.

After the configuration, I got no problems with the database connections number but the performance is baddest than before :/

Is there any other area that you think I should check?

Posted by Irfan on 08-Mar-2017 05:35


If your number of sessions in MS-Agent configuration is same as your client requests(not just clients, you might fire some asnychronous requests) then I do not expect to get bad response. Are you using same machine to run Classic Appserver and PASOE or different machine ?

Posted by gus bjorklund on 08-Mar-2017 09:04

> On Mar 7, 2017, at 2:11 PM, Eduardo Aceves Ledezma wrote:


> 5 clients get attented in 15 seconds and, after that time, it responds to all of them at the same time

is it possible that these 5 clients’ sessions end up connected all (via tcp/ip) to the same database server process which then time-slices the queries amongst the 5 clients ???

Posted by Eduardo Aceves Ledezma on 08-Mar-2017 09:39

Hi [mention:54e5df2f11a046ef89f0b4acd415e0d5:e9ed411860ed4f2ba0265705b8793d05] , yes, it's on the same machine as before :(

Hi [mention:22b0915eb76243a69eb580cf41e9ee92:e9ed411860ed4f2ba0265705b8793d05] , The database server is the same machine as the PAS server, I don't know if that has something  to do with the performance, since the queries are the ones that are responding those highly increased execution times. Regards!

Posted by Irfan on 08-Mar-2017 09:41

I think we have all the information but do not understand what might cause the problem. Please open a case with TechSupport and see if we can get it better.

This thread is closed