[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HTTPAPI calls slower in our production environment
+1 on adding timestamps. Running in all three environments and checking the differences will help to narrow down the issue. The archives have a simple change to one procedure that will be a good spot to start:
http://www.scottklement.com/archives/ftpapi/201310/msg00080.html
The network should not be a problem no matter what, but just to make sure the basics are covered, trace route in each environment to make sure the routing to the production box is not messed up. TRACEROUTE RMTSYS(WINDOWSERVER.COMPANY.COM)
Another thought, in production, is work management "normal" or do you have special setup? The program making the httpapi call set up with defined activation group or *caller or *new? Any changes between that and development?
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Tuesday, January 07, 2014 7:45 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: HTTPAPI calls slower in our production environment
Do you have debug on in production by chance?
That's the only HTTPAPI related slowdown I can think of.
Other than that, I'd look to make sure it's not the Windows side. Can you
call the windows service with SoapUI or maybe call the DEV/TEST from your
production i?
Assuming you can confirm it is the i, one thing to check would be the
configuration of IP6 on production. Users on the midrange list have
reported poor network performance (granted mostly Java apps) when IP6 is
incompletely configured.
Can you add some dsply op-codes to display time stamps (or use the debug
message in HTTPAPI) to see if the slowdown is in the network code or your
RPG code? If you have performance tools, you could use those also.
You might consider making sure the times on the machines are reasonably in
sync (hopefully both are using the same NTP service) and then run a comm
trace on both sides. That would let you see if the network itself is the
issue.
Lastly, look at the environment where the HTTPAPI using app is running,
QINTER or QBATCH? Do you have enough activity levels? You may want to try
moving it to it's own dedicated subsystem with dedicated memory at least
temporarily to ensure that you have total control of it's environment.
HTH,
CHarles
On Tue, Jan 7, 2014 at 4:51 AM, <Venter.Derick@xxxxxxxxxxxxxx> wrote:
> Hello everyone.
> We are in the process of re-writing all our web service calls using RPG
> functions and HTTPAPI. The new web service calls are much faster than
> the previous technology used but have a major performance problem in
> our production environment.
> Our development an test environments (RPG web service calls) are faster
> than our production environment. Doesn't make sense because the
> production server is bigger, better and faster.
> Dev environment
> RPGLE function on AS400_DEV server calling a web service on WINDOWS_DEV
> server.
> Test environmenrt
> RPGLE function on AS400_TEST server calling a web service on
> WINDOWS_TEST server.
> Production environment
> RPGLE function on AS400_PRODUCTION server calling a web service on
> WINDOWS_PRODUCTION server.
> I am using the same test function in all environments.
> Any idea where to look..start...
> Regards
> Derick Venter
> Applications Developer IV
>
> [cid:_4_09AE216409AE1D64003623EB42257C59]
>
> Systems Integration
> Tel: +27 (13) 247 2816 Fax: +27 (0) 86 573 2274
> Cell: +27 (0) 83 458 6599
> Email: [1]derick.venter@xxxxxxxxxx
> [2]www.gijima.com
> __________________________________________________________________
>
> This e-mail is subject to the Columbus Stainless [Pty] Ltd Email Legal
> Notices available at:
> [3]http://www.columbus.co.za/EmailLegalNotice.htm.
> __________________________________________________________________
>
> This e-mail message has been scanned for Viruses and Content and
> cleared by MailMarshal
> __________________________________________________________________
>
> References
>
> 1. mailto:derick.venter@xxxxxxxxxx
> 2. http://www.gijima.com/
> 3. http://www.columbus.co.za/EmailLegalNotice.htm
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------