Network help

 

We've started using some QSDK software to allow the HP3000 to become a
Webserver basicly. We've been using is pretty successfully I might add
but the volume is starting to increase and noticing some bottle necks
that look to be network related. Does anyone have a few minutes to maybe
look at our issue. I'm not sure what to change if anything to change in
the size of any of the buffer pools for the network. We had our OUTBOUND
Buf Pool on Loop max out yesterday and cause the Webservices to hang. We
increased that size to 512 about 2 weeks ago and that helped but didn't
want to keep changing without knowing what it affects.

 

[5]RESOURCE>>>dis

THU, JAN 29, 2009,  7:40:58 AM

 Item  Subsystem   Name   G/N  Description      Used   High    Max

____________________________________________________________________

 

  1    NS XPORT  CP_POOL_ (G)  Control Buf Pool    0      1    300 :)

  2    NS XPORT  1536___D (G)  Inbound Buf Pool   42     60    512 :)

  3    NS XPORT  NET1____ (N)  Outbnd  Buf Pool    0     50    768 :)

  4    NS XPORT  LOOP____ (N)  Outbnd  Buf Pool    0     75    512 :)

  5    NS XPORT  UDP      (G)  GProt  Msg  Pool    0    N/A    512 :)

  6    NS XPORT  PXP      (G)  GProt  Msg  Pool    0    N/A    660 :)

  7    NS XPORT  PROBE    (G)  CM Prot Msg Pool    0    N/A    678 :)

  8    NS XPORT  IP_NI    (G)  IP-NI  Msg  Pool    0    N/A   2048 :)

  9    NS XPORT  IP_NI    (G)  IP-NI  Msg  Pool    0    N/A   2048 :)

 10    NS XPORT           (G)  Node  Name Cache    0      1    360 :)

 11    NS XPORT           (G)  TCP Control pool    0     73   2048 :)

 12    TELNET    PTOD     (G)  Write   Buf Pool    0      1   2048 :)

 13    TELNET    PTID     (G)  Outbnd  Buf Pool    0      1   2048 :)

 14    TELNET    PTID     (G)  Inbound Buf Pool    1      2   2048 :)

 15    TELNET    PTOD     (G)  Negot   Buf Pool    0      1   2048 :)

 

 

 

Randy Stanfield 

Unisource - Dallas 

972-982-3621

 

From: Fatula, Steve (Norcross, DAV) 



 

So, we have a program WBGETPR that primarily calculates cost and price
on HP3000. It is called via network calls as a XML web service. So,
client pc or machine of some sort calls the HP3000, sends XML string in
a POST, and, gets reply back on the same socket. We have a LOT of these
types of services on the HP, and all of them seem to work well. Except,
this one has some odd behavior we'd like to understand better. The
program is different than the other HP services we have in that it seems
to return a far larger amount of data. This service not only prices one
item, it prices a list of items in a single call. There is a lot of data
returned for each item. So, when we get a list of say 300 items to price
and cost, the reply data could be around 400K. This has been
horrendously slow.

 

So, we put some timers in the code. Where the process bogs down is in
the network WRITES from the HP to the client. The client can be an
HP3000, a PC running proprietary software, or, a PC running the OPENSTA
open source test tool, it made no difference. The data sent to the
client is divided up into chunks of at most 30,000 bytes. The HP call
used is IPCSEND. The timers around calls to IPCSEND showed elapsed run
times in the hundredth of a second or smaller for the first two IPCSEND
calls in a reply, then would spike, to 4, 8, or even 15 seconds for a
single IPCSEND call. Drastic change! This would cause the process to be
very slow needles to say. We never saw the first two chunks of 30,000
bytes slow, they were always almost instant. Always, the third one (and
some of the later ones) was slow, and the time varied widely. This is on
a very fast development machine. We monitored some of the network
tables, and didn't find any that maxed out. So, not sure where to look
to find out why this might occur.

 

As an experiment, we changed our maximum size to 10,000 bytes in the
IPCSEND calls. This resulted in no times exceeding .even 1 second, I
believe the largest we saw as .6 and that was with a bunch of them
running at the same time. But it was way faster than using 30,000 byte
IPCSEND calls.

 

The question is, why! What can be causing this behavior, and is there
maybe a more optimal number we can use other than 10,000. We'd like to
understand what the issue may be, it would seem 30,000 would be more
efficient since there are less calls, but that is not what we see.

 

Randy, you can add any details about the hardware, and, let me know if
you think I am missing anything here.

 

 

 

Steve Fatula

5 Diamond IT Consulting

214-592-4230 Voice Ext 151

206-984-9737 Fax

 


* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *