Plex 2E

We've been having very slow response times from a Plex generated WCF web service (about 13 seconds on first call and 10 seconds on all subsequent calls even for the simplest of methods - e.g. 'Hello').

I suspect it has to do with the configuration because our internal Plex generated web services have good response times (< 1 second per call).

The web services where we are having the problem are configured as follows: The IIS server is outside our firewall but the Plex config file on the IIS server points to a server ('LOON') which resides inside the firewall. LOON is running the Plex .Net listeners.

At first the web service method calls failed completely but then we realized that the IIS server would not be able to resolve the DNS lookup for 'LOON' so I changed the Plex config file on the IIS server to point to the IP address of LOON instead of using the name. This then allowed the web service methods calls to work, albeit very slowly (see above response times).

Today we added a mapping in the HOST file on the IIS server to map the LOON IP address and the web service method call times improved dramatically, the call times dropped in half to a best case of 4.75 seconds. So this was encouraging.

However, we are still about 4 seconds slower than other web services we use (3 rd parties) so we are scratching our heads wondering what else it could be and if perhaps there would be some other server it is trying to resolve. There are no other server entries in the Plex config flie.

Appreciate any other ideas on where to look, what to try.

Alan

Have you guys considered generating your WCF service as Windows Service rather than a web service and hosting it on IIS?

We have some internal (host and client inside the firewall) Plex generated web services that are hosted by a Windows service (instead of IIS), using net.TCP and that does provide very good performance. Unfortunately, in this case the web service needs to be called from 3rd parties so it's an external (outside the firewall) web service hosted on IIS. I don't think our firewall guys would go for a Windows service hosted outside the firewall...

Alan

Is your service running on port 80? We had sluggish performance when we had several services running on the same port. Perhaps you can try changing the port the service is running on?

--
Rob

It is using port 443 because it's https but your question does make me wonder if there is some issue related to an attempt to use port 80 for which there is no response...

Hello Nash

Did you ever get the performance resolved?

Did you have to change your solution?

Regards
George

Yes, I worked with the CA Plex team for quite a while to find it. The problem turned out to be that the Plex .Net listener tries to do a reverse DNS lookup as one of the first things it does after receiving an incoming call. However in our case the IIS server making the call sits in the DMZ (so it can host calls from 3rd parties outside our firewall) and the IIS server is not listed in our internal DNS table (for security reasons). As a result the Plex .Net listener was waiting 5 seconds per web service call trying to get the reverse DNS lookup on the calling server (get server name from IP address). The work-around was a table entry on the network side to facilitate the reverse DNS lookup, then the performance issue completely went away. This was a hard one to track down.

Alan

Hi Nash,

Many thanks fot the encouraging response.

I was hoping you may have an idea on an approach I am mulling over....

Currently Java UI (native) calls Plex generated RPG back end using Jit400. Java UI tier complain about the java lump on the first call etc and that jit400 has no wsdl etc.

Was looking at exposing the Plex RPG functions to the Java UI layers via WCF hopefully equalling or bettering the jit performance but also being able to offer wsdl soap calls.

Are those assumptions correct. Would there be instantiation on each WCF call, I mean would the RPG functions remain in memory or would we have a .net lump each call as opposed to the one off jit lump...

Regards
George

Hi George,

I do have some input that may help, but first the caveat: I have quite a bit of experience with developing and using Plex web services (SOAP WCF) but no experience with JAVA. Hopefully some of my insights transfer, I think they should for the most part.

Here are some random thoughts, please feel free to press me for more detail on any of these:
1)
The Plex generated SOAP (WCF web service) calls are a great way to expose an API from a Plex system to a non-Plex system and not have to worry about proprietary/compatibility differences (e.g. Oracle vs DB2 etc).
2)
However there is certainly some overhead associated with the SOAP calls. For external calls (internet) we use HTTP bindings but for internal (intranet) we use net.TCP binding for better performance.
3)
The performance hit is greatest on the first call because some pieces don’t get loaded and built until the first call. There is a dramatic performance improvement after the first call.
4)
Despite what I say in #3, the calls are by definition stateless. Generally there is no session and each call needs to not rely on prior calls (e.g. BlockFetch positioning must be set on each call).
5)
No matter what there will be a performance hit using WCF calls vs regular Plex DB2 calls (SingleFetch, BlockFetch etc). So my preference is to expose the higher level functional request using a ‘consolidator’ RPG function which in turn makes two or three (or more) actual Plex calls to fulfill the user request. I do this for two reasons: a) to minimize the performance hit and b) since many of our users are not familiar with Plex or the AS400, I am able to shield the API user from much of the ‘strange’ complexity (e.g. BlockFetch).
6)
In cases where we are uploading data to the AS400 using Plex WCF web service calls, I have found that making use of the ‘Occurs N times’ triple is important on the input so that you can upload an array of values in a single call. Otherwise at one record per call it can be quite slow if you have hundreds of records to upload.

I hope that helps a bit.

Alan Armstrong (Nash)

Hi there George & Nash,

Nash - many thanks for sharing your real-world experience of using WCF Services in Plex. Can you confirm how you have your WCF Services configured:

(1) WCF Hosting Type.
(2) Type of HTTP binding protocol? (probably either basicHttpBinding.or wsDualHttpBinding).
(3) Client type (ASP.NET or something non-MS?).

It was my understanding that If you are using basicHttpBinding hosted in IIS; then the resulting stateless WCF Services would not have any session information associated with them; and Plex .NET runtime instances (and ergo AS400 connections) would need to be initialized with each call. That's certainly the response I gave to Gavin...

-Rob

Hi Rob,

1)
For internet we use IIS/7 hosting. For intranet we use self-hosted Windows service.
2)
For internet we use basicHttpBinding and for intranet we use net.TCP binding.
3)
Client type: intranet is almost always VS2010/C# (in some cases ASP.net); for internet it varies but in some cases it is native Java.

You raise a good point. If the client is native Java then the Plex host probably needs to stay with basicHttpBinding (and not the other more elaborate WCF bindings) because the more elaborate WCF bindings are Microsoft specific (at least they were when I last checked). The basicHttpBinding may be basic but in my experience it works quite well when you need to interact with third parties (internet) and compatibility is your top concern.

As far as: “If you are using basicHttpBinding hosted in IIS; then the resulting stateless WCF Services would not have any session information associated with them” – that is my understanding as well.

Alan

My last reply was to your original and we posted almost at the same time.

Your settings info is priceless info and am most grateful to you Alan.

I am still left with the issue of performance thou and maybe be being thick but I doubt your requirements are any different than mine and you find the performance acceptable so should I but am having diffculty understanding the architecture.

All my as400 business objects have been written in a stateless fashion so no issues there but I can get my head around if the .net plex runtime are created each call then how can the performance be good... even the winc clients the first call is slow compared to the next time the same call is made.

Hi George,

Well, performance is relative and I’m not sure if you would find the performance acceptable or not. So…here are some numbers for what they are worth…

We have a tester client which we use to exercise our web services as well as the web services of third parties we interface with. We use the tool to help troubleshoot (verify the service is up and we can at least perform basic communication). If there is an error the tool displays the exception call stack. The tester also displays the time to completion for each web service (call) tested. The calls are best case in that it is a very simple ‘Hello Ada’ / ‘Ada Ready’ query/response. In the case where there is an AS400 call involved it is simply getting the Date/Time from the AS400.

I’m sure this is over simplified for your needs but perhaps it is a starting point to put some real numbers on the question. All times are in seconds. All are net.TCP binding unless marked as basicHttp.

Web Service
First Call
Second Call
Notes
Deposit
1.37
*
Includes AS400 call
Video
1.05
0.03

Notify
0.56
0.23
basicHttp
Warrant-Int
0.67
0.23
basicHttp
WarrantDMZ
2.22
0.23
basicHttp
Phone
0.23
0.02

Image
0.42
0.05

Official
1.06
0.09


I do not have a ‘Second Call’ number for Deposit because the tester only calls the AS400 on the first call (to verify it can reach the AS400).

Another variable to be aware of is that if hosted with IIS, then by default if the web service is inactive for 10 minutes, IIS will unload that web service and the next web service call will incur a substantial penalty while the service is reloaded.

Where we have had performance issues, and there have been some, we have used the ‘Occurs’ arrays (as mentioned before) to cut down on the number of web service calls.

Alan Armstrong (Nash)

Ugh, my table formatting got stripped, making this very hard to read! Sorry for that...

Alan

Keep alive looks like something I should consider. Excited about a poc And no doubt some hair pulling but this thread and others will have helped me no end.

Hi Alan,

Well have hit the problem of basicHttpBinding (0.1 to 0.4 seconds) not having session management but being easy to call by java but then poor performance relative to the lightning speed of wsdualhttpbinding (0.01 seconds to 0.03).

Did your java tier ever consider "how to call wsdualhttpbinding" and then discounted it after finding it a headache and therefore I should not bother or did you discount it as basicHttpBinding performance was acceptable?

Wsdualhttpbinding is desirable because session management (only getting one job on the as400), have got wshttpbinding to do the same (only getting one job on the as400) but performance matches basicHttpBinding and not lightning wsdualhttpbinding. I tried wshttpbinding as persumably we don't need the 'callback' that the dual aspect is providing.

My situation is internal java presentation tiers calling rpg.

Interesting work.

Cheers
George

Hello George,

We went with basicHttpbinding as a lowest common denominator that worked with a number of third parties (e.g. java, even COBOL) and provided acceptable performance for fairly low traffic volume external communication.

For our higher volume/performance internal services we are using net.TCP.

I will be interested to hear how your java tests turn out.

Cheers,

Alan

Excellent original reply Nash and points I will follow up on in due course but first...

Rob's response has put my issue as usual more clearly than I did. It is the crux of my thread question and hoping Gavin can add with his real world experience also. This theme of exposing existing logic to non plex tiers using WCF is a very exciting development in my opinion. But so far the actual architecture of implementing and limitations for doing this is not clear.

Basically I know I have business objects on the as400 (not trivial data access single fetch but SOA objects) that I could expose using websydian xml pattern which in its implementation involves a listener that runs continually processing requests and responses, and therefore yes there is a memory lump each time a call is made to a function not previously called. Meaning if a java tier calls a Business object it will run quicker the nextime as well as a completely different calling tier such as a .net tier etc. But what about WCF implementation, I am hoping 'Plex .NET runtime instances (and ergo AS400 connections) would need to be initialized with each call' is not the case.

I am hoping to knock peoples socks of with this and have provisionally looked at how to model the wcf in plex and amazed at the simplicity, if you have created SOA objects before or are now in theory this could prolong the life expentancy of these 'plex' generated functions substantially.