[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HTTPAPI calls slower in our production environment
Hi Mike / Charles
We found the problem.
We can see that the AS400_TEST server is configured to first look up a
host name in the local host table. AS400_PRODUCTION is set up to use
the DNS server first for a name look up.
When we ping the WINDOWS_TEST server from AS400_TEST server we get a
quick response with the server name and no domain name at the end of
the server name.
When we ping the WINDOWS_PRODUCTION server from AS400_PRODUCTION server
we get a slow response with the server name and the domain name added
at the end of the server name.
We re-configured the AS400_PRODUCTION server and it is now as fast as
we expect it to be.
Thanks for then help.
Regards
Derick Venter
Applications Developer IV
[cid:_4_07E90E0007E90A000032667442257C5A]
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
From: Mike Krebs <mkrebs@xxxxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Date: 2014/01/07 07:32 PM
Subject: RE: HTTPAPI calls slower in our production environment
Sent by: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
__________________________________________________________________
+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:
[3]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
[[4]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
>
> [[5]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][6]www.gijima.com
>
__________________________________________________________________
>
> This e-mail is subject to the Columbus Stainless [Pty] Ltd Email
Legal
> Notices available at:
> [3][7]http://www.columbus.co.za/EmailLegalNotice.htm.
>
__________________________________________________________________
>
> This e-mail message has been scanned for Viruses and Content and
> cleared by MailMarshal
>
__________________________________________________________________
>
> References
>
> 1. [8]mailto:derick.venter@xxxxxxxxxx
> 2. [9]http://www.gijima.com/
> 3. [10]http://www.columbus.co.za/EmailLegalNotice.htm
>
>
-----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> [11]http://www.scottklement.com/mailman/listinfo/ftpapi
>
-----------------------------------------------------------------------
>
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
[12]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
__________________________________________________________________
This e-mail is subject to the Columbus Stainless [Pty] Ltd Email Legal
Notices available at:
[13]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.scottklement.com/archives/ftpapi/201310/msg00080.html
4. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
5. cid:_4_09AE216409AE1D64003623EB42257C59
6. file://localhost/tmp/www.gijima.com
7. http://www.columbus.co.za/EmailLegalNotice.htm
8. mailto:derick.venter@xxxxxxxxxx
9. http://www.gijima.com/
10. http://www.columbus.co.za/EmailLegalNotice.htm
11. http://www.scottklement.com/mailman/listinfo/ftpapi
12. http://www.scottklement.com/mailman/listinfo/ftpapi
13. 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
-----------------------------------------------------------------------