RE: NETTYPE "CPU" vs "NET"
Sorry, I think perhaps I wasn't clear.
My testing showed that using CPU VP's to be considerably faster than using NET
VP's, even when using a Socket connection.
Doesn't that contradict the recommendations?
Regards,
Tristan
From: Art Kagel [mailto:art.kagel@gmail.com]
Sent: Monday, 28 February 2011 12:53 AM
To: ids@iiug.org
Cc: Tristan Ball
Subject: Re: NETTYPE "CPU" vs "NET" [22939]
My recommendation is always that sockets and tli network connections should
use NET VPs for the poll threads and shared memory connections, if actively
used and not reserved only for maintenance, should reside in every CPU VP.
Your testing validates this recommendation, as far as the network connections
are concerned. FYI, since 10.00 the Performance Guide has agreed with these
recommendations, it sounds like whoever gave you different advice remembers
the older Performance Guide discussion.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com<http://www.advancedatatools.com>)
IIUG Board of Directors (art@iiug.org<mailto:art@iiug.org>)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Sun, Feb 27, 2011 at 6:25 AM, Tristan Ball
<tristanb@pronto.com.au<mailto:tristanb@pronto.com.au>> wrote:
Hi Everyone,
I was told recently that setting the NETTYPE parameter to be CPU rather than
NET could be faster under certain circumstances. In some simple benchmarking,
it does seem that using CPU VP's for the poll threads allowed the system to
sustain a considerably higher rate of simple requests.
Can anyone help me understand what the trade-offs or disadvantages of this
might be? My test was simplistic, a single thread sending as many simple
select queries as possible - however the differences between the two rateswere substantial (about 40%), and our application does spend a lot of it's
time sending simple repeat requests, so it would seem that this is a sensible
change to make.
The application runs on the same server as Informix, connecting via TCP on the
localhost interface, with up to about 300 instances of the application running
at any given moment - although generally only a very small number of those are
doing anything at any instance (<10 generally). It's primarily an OLTP
environment, if that makes a difference.
Regards,
Tristan
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Questions:
- How many processor cores?
- How many CPU VPs are configured?
- What are the two versions of the NETTYPE settings?
- What version and platform?
I suspect that since only ~10 out of the 300 connected application sessions
are active concurrently, that you are not stressing the CPU VPs to a level
that would manifest the slower responsiveness that I have seen.
My testing showed the behavior I described testing while I was at Bloomberg
where we had 40-80 connections from middleware instances handling requests
for 200,000 users with up to about 125,000 users concurrently connected.
So, we had four to eight times the active concurrency you are experiencing.
If that's not the explanation, I don't know.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Sun, Feb 27, 2011 at 4:46 PM, Tristan Ball <tristanb@pronto.com.au>wrote:
> Sorry, I think perhaps I wasn't clear.
>
> My testing showed that using CPU VP's to be considerably faster than using
> NET
> VP's, even when using a Socket connection.
>
> Doesn't that contradict the recommendations?
>
> Regards,
>
> Tristan
>
> From: Art Kagel [mailto:art.kagel@gmail.com]
> Sent: Monday, 28 February 2011 12:53 AM
> To: ids@iiug.org
> Cc: Tristan Ball
> Subject: Re: NETTYPE "CPU" vs "NET" [22939]
>
> My recommendation is always that sockets and tli network connections should
> use NET VPs for the poll threads and shared memory connections, if actively
> used and not reserved only for maintenance, should reside in every CPU VP.
> Your testing validates this recommendation, as far as the network
> connections
> are concerned. FYI, since 10.00 the Performance Guide has agreed with these
> recommendations, it sounds like whoever gave you different advice remembers
> the older Performance Guide discussion.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com<
> http://www.advancedatatools.com>)
> IIUG Board of Directors (art@iiug.org<mailto:art@iiug.org>)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or
> by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Sun, Feb 27, 2011 at 6:25 AM, Tristan Ball
> <tristanb@pronto.com.au<mailto:tristanb@pronto.com.au>> wrote:
> Hi Everyone,
>
> I was told recently that setting the NETTYPE parameter to be CPU rather
> than
> NET could be faster under certain circumstances. In some simple
> benchmarking,
> it does seem that using CPU VP's for the poll threads allowed the system to
> sustain a considerably higher rate of simple requests.
>
> Can anyone help me understand what the trade-offs or disadvantages of this
> might be? My test was simplistic, a single thread sending as many simple
> select queries as possible - however the differences between the two rates> were substantial (about 40%), and our application does spend a lot of it's
> time sending simple repeat requests, so it would seem that this is a
> sensible
> change to make.
>
> The application runs on the same server as Informix, connecting via TCP on
> the
> localhost interface, with up to about 300 instances of the application
> running
> at any given moment - although generally only a very small number of those
> are
> doing anything at any instance (<10 generally). It's primarily an OLTP
> environment, if that makes a difference.
>
> Regards,
>
> Tristan
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--0015175113e61670ac049d4f7a0b
Pollthreads on NET VPs can "idle" themselves. In CPU VPs they cannot. In
theory it may happen that the "net code" steals precious CPU time from the
CPUVPs.
This may be specially noticeable if you use FASTPOLL set to 1.
This may not apply to all situations... in your case you have a lot of
processes competing for the real CPU cycles... (application and database in
the same server).
Also... On your test your application's sessions don't "idle" (I suppose),
which is probably not a real situation. This makes them much more
"responsive" that a real scenario. In this case, avoid further process
context switch may compensate the issue above....
But this is hard to measure... Art's questions are relevant. It would also
be interesting to find if you can get your CPU usage to the maximum in any
of those scenarios?
Regards.
On Sun, Feb 27, 2011 at 9:46 PM, Tristan Ball <tristanb@pronto.com.au>wrote:
> Sorry, I think perhaps I wasn't clear.
>
> My testing showed that using CPU VP's to be considerably faster than using
> NET
> VP's, even when using a Socket connection.
>
> Doesn't that contradict the recommendations?
>
> Regards,
>
> Tristan
>
> From: Art Kagel [mailto:art.kagel@gmail.com]
> Sent: Monday, 28 February 2011 12:53 AM
> To: ids@iiug.org
> Cc: Tristan Ball
> Subject: Re: NETTYPE "CPU" vs "NET" [22939]
>
> My recommendation is always that sockets and tli network connections should
> use NET VPs for the poll threads and shared memory connections, if actively
> used and not reserved only for maintenance, should reside in every CPU VP.
> Your testing validates this recommendation, as far as the network
> connections
> are concerned. FYI, since 10.00 the Performance Guide has agreed with these
> recommendations, it sounds like whoever gave you different advice remembers
> the older Performance Guide discussion.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com<
> http://www.advancedatatools.com>)
> IIUG Board of Directors (art@iiug.org<mailto:art@iiug.org>)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or
> by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Sun, Feb 27, 2011 at 6:25 AM, Tristan Ball
> <tristanb@pronto.com.au<mailto:tristanb@pronto.com.au>> wrote:
> Hi Everyone,
>
> I was told recently that setting the NETTYPE parameter to be CPU rather
> than
> NET could be faster under certain circumstances. In some simple
> benchmarking,
> it does seem that using CPU VP's for the poll threads allowed the system to
> sustain a considerably higher rate of simple requests.
>
> Can anyone help me understand what the trade-offs or disadvantages of this
> might be? My test was simplistic, a single thread sending as many simple
> select queries as possible - however the differences between the two rates> were substantial (about 40%), and our application does spend a lot of it's
> time sending simple repeat requests, so it would seem that this is a
> sensible
> change to make.
>
> The application runs on the same server as Informix, connecting via TCP on
> the
> localhost interface, with up to about 300 instances of the application
> running
> at any given moment - although generally only a very small number of those
> are
> doing anything at any instance (<10 generally). It's primarily an OLTP
> environment, if that makes a difference.
>
> Regards,
>
> Tristan
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--0015174c13ac559d81049d5bab45
Hi Art. Well, you prompted me to do some more testing... :-) 5CPU/5GB VM VMWare ESXi 4.1, VM is Redhat 6 64bit, Informix is 11.50.FC8GE. CPU is an Phenom II X6, with no other VM's running on this host. Host has 8GB of ram total. This time round I had two bits of code to test with: Code1.pl - Makes a single connection, sends as many simple requests per/sec as possible, times result. Code2.pl - Makes 5 connections, sending a few requests from each connection, then choosing another and repeating. There is a 0.002 second delay between each query. Test method was: 1) Start IDS 2) Run Code1.pl on it's own to ensure functionality, and to get baseline singlethread result. 3) Run 20 copies of code2.pl. So in total 100 database connections, with 20 of them "moderately" active at any given moment. 4) Re-Run Code1.pl, to get "result under load" As of step 3, the system would be running with between 40 and 25% CPU idle time, depending on the test run. In general, "CPU" run's resulted in more idle time (about 12%), although the gap closed as I increased the number of threads. I did most tests only twice, as the results seemed pretty consistent and stable. Results from "step 1" were fairly consistent. "CPU" tests resulted in about 2000 requests/sec, while "NET" tests peaked at about 1700. This isn't quite as big a change as my original test, but I'm testing on a slightly different setup. Results from "Step 4", with various combinations of settings: VPCLASS cpu,num=4,noage soctcp,2,10,CPU 500/sec soctcp,2,10,NET 640/sec VPCLASS cpu,num=4,noage soctcp,4,10,CPU 780/sec soctcp,4,10,NET 641/sec VPCLASS cpu,num=10,noage soctcp,4,10,CPU 787/sec soctcp,4,10,NET 606/sec VPCLASS cpu,num=10,noage soctcp,10,10,CPU 1230/sec soctcp,10,10,NET 630/sec VPCLASS cpu,num=10,noage soctcp,20,10,NET 640/sec soctcp,20,10,CPU 630/sec During this, I also spot checked the output from my "code2.pl", and each process was getting approximately 390-300 reqs/sec, regardless of which test I was doing. That's pretty much as I'd expect, as the delay my code deliberately caps it. The interesting one is the 1230 result, with 10VCP's, and 10 connections per thread - it's markedly faster than the others, and seems reproducible. I did a couple of tests either side, and "soctcp,8,10,CPU" was nearly as fast, while "soctcp,13,10,CPU" markedly slower again, back down in the low 800's Obviously I've actually got more connections in total than configured in the NETTYPE soctcp lines. I'm actually a little surprised that worked. :-) Or course - all my queries are still very simple - return one random record based on a uniquely indexed key, so I guess it's possible results would differ markedly if the load consisted of longer running queries... I don't think I'm really looking for explanations to the above anymore either, as I suspect we'd need the Informix source code and a profiler to fully understand it - but I thought I'd share my results anyway, just for interests sake. Regards, Tristan -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Monday, 28 February 2011 2:43 PM To: ids@iiug.org Subject: Re: NETTYPE "CPU" vs "NET" [22942] Questions: - How many processor cores? - How many CPU VPs are configured? - What are the two versions of the NETTYPE settings? - What version and platform? I suspect that since only ~10 out of the 300 connected application sessions are active concurrently, that you are not stressing the CPU VPs to a level that would manifest the slower responsiveness that I have seen. My testing showed the behavior I described testing while I was at Bloomberg where we had 40-80 connections from middleware instances handling requests for 200,000 users with up to about 125,000 users concurrently connected. So, we had four to eight times the active concurrency you are experiencing. If that's not the explanation, I don't know. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Sun, Feb 27, 2011 at 4:46 PM, Tristan Ball <tristanb@pronto.com.au>wrote: > Sorry, I think perhaps I wasn't clear. > > My testing showed that using CPU VP's to be considerably faster than > using NET VP's, even when using a Socket connection. > > Doesn't that contradict the recommendations? > > Regards, > > Tristan > > From: Art Kagel [mailto:art.kagel@gmail.com] > Sent: Monday, 28 February 2011 12:53 AM > To: ids@iiug.org > Cc: Tristan Ball > Subject: Re: NETTYPE "CPU" vs "NET" [22939] > > My recommendation is always that sockets and tli network connections > should use NET VPs for the poll threads and shared memory connections, > if actively used and not reserved only for maintenance, should reside in every CPU VP. > Your testing validates this recommendation, as far as the network > connections are concerned. FYI, since 10.00 the Performance Guide has > agreed with these recommendations, it sounds like whoever gave you > different advice remembers the older Performance Guide discussion. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com< > http://www.advancedatatools.com>) > IIUG Board of Directors (art@iiug.org<mailto:art@iiug.org>) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own > opinions and do not reflect on my employer, Advanced DataTools, the > IIUG, nor any other organization with which I am associated either > explicitly, implicitly, or by inference. Neither do those opinions > reflect those of other individuals affiliated with any entity with > which I am affiliated nor those of the entities themselves. > > On Sun, Feb 27, 2011 at 6:25 AM, Tristan Ball > <tristanb@pronto.com.au<mailto:tristanb@pronto.com.au>> wrote: > Hi Everyone, > > I was told recently that setting the NETTYPE parameter to be CPU > rather than NET could be faster under certain circumstances. In some > simple benchmarking, it does seem that using CPU VP's for the poll > threads allowed the system to sustain a considerably higher rate of > simple requests. > > Can anyone help me understand what the trade-offs or disadvantages of > this might be? My test was simplistic, a single thread sending as many > simple select queries as possible - however the differences between > the two rates were substantial (about 40%), and our application does > spend a lot of it's time sending s
Just a quick answer for only one aspect: On Tue, Mar 1, 2011 at 1:24 PM, Tristan Ball <tristanb@pronto.com.au> wrote: > Results from "Step 4", with various combinations of settings: > > VPCLASS cpu,num=4,noage > soctcp,2,10,CPU 500/sec > soctcp,2,10,NET 640/sec > > VPCLASS cpu,num=4,noage > soctcp,4,10,CPU 780/sec > soctcp,4,10,NET 641/sec > > VPCLASS cpu,num=10,noage > soctcp,4,10,CPU 787/sec > soctcp,4,10,NET 606/sec > > VPCLASS cpu,num=10,noage > soctcp,10,10,CPU 1230/sec > soctcp,10,10,NET 630/sec > > VPCLASS cpu,num=10,noage > soctcp,20,10,NET 640/sec > soctcp,20,10,CPU 630/sec > > Obviously I've actually got more connections in total than configured in > the > NETTYPE soctcp lines. I'm actually a little surprised that worked. :-) > Don't be surprised. The NETTYPE value will not limit TCP connections. It's used only for some memory calculations for what it's called network buffers. AFAIK only in Solaris/TLI you can get limmited and this can be considered a side effect which happens only in very stress conditions (number of connections per second). Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --00504502c6bfd74f05049d6d2feb