Hi all

What is the impact of not having enough threads per connection. 

NETTYPE ipcstr,12,200,CPU
VPCLASS cpu,num=12,noage,autotune=1,max=14.

How do I know if I am getting up towards that limit.

Regards
Jason

------------------------------
Jason Ball
------------------------------

#Informix

Keeping in mind that the number of connections is auto-expanding, and also my other notes from your previous post/question, if you approach or surpass the efficiency zone (500-700 active connections per listener), responsiveness to user requests will seem to be slow although once a request is picked up the response should be quick as usual.

The keyword here is "active" connections. If you have 9000 users connected but only 300 of them are actively submitting requests (new queries or even just "next block of data" requests) then you will still be OK.

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
------------------------------

Thanks Art. My apologies for double posting, The first one was submitted Friday, but I didn't see it on lists on Monday, so thought I must have made an error. I will be more patient next time.

Just to be very clear, even though the config is about specifying connections per thread, performance is more affected by _active_ connections per _listener_? What do we need to consider in the "number of connections per thread" then?

------------------------------
Jason Ball
------------------------------

Original Message:
Sent: Mon January 11, 2021 10:55 AM
From: Art Kagel
Subject: NETTYPE connections per thread

Keeping in mind that the number of connections is auto-expanding, and also my other notes from your previous post/question, if you approach or surpass the efficiency zone (500-700 active connections per listener), responsiveness to user requests will seem to be slow although once a request is picked up the response should be quick as usual.

The keyword here is "active" connections. If you have 9000 users connected but only 300 of them are actively submitting requests (new queries or even just "next block of data" requests) then you will still be OK.

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
------------------------------

Hmm, I think I'm getting threads and listeners tangled up. The config is about connections per listener, performance is not affected below 500-700 connections per listener. Per your reply on my other post, the engine will increase the number of connections as required (except for shared memory types).

So 5000 user threads will be adequately covered by this configuration, especially when considering the active user threads are a fraction of this.

------------------------------
Jason Ball
------------------------------

Original Message:
Sent: Mon January 11, 2021 06:11 PM
From: Jason Ball
Subject: NETTYPE connections per thread

Thanks Art. My apologies for double posting, The first one was submitted Friday, but I didn't see it on lists on Monday, so thought I must have made an error. I will be more patient next time.

Just to be very clear, even though the config is about specifying connections per thread, performance is more affected by _active_ connections per _listener_? What do we need to consider in the "number of connections per thread" then?

------------------------------
Jason Ball
------------------------------


Original Message:
Sent: Mon January 11, 2021 10:55 AM
From: Art Kagel
Subject: NETTYPE connections per thread

Keeping in mind that the number of connections is auto-expanding, and also my other notes from your previous post/question, if you approach or surpass the efficiency zone (500-700 active connections per listener), responsiveness to user requests will seem to be slow although once a request is picked up the response should be quick as usual.

The keyword here is "active" connections. If you have 9000 users connected but only 300 of them are actively submitting requests (new queries or even just "next block of data" requests) then you will still be OK.

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com