Hi All,
When ever my client submits the first xml request to one of the service in the webMethods using http is taking more time (approximately 10 min) to send the response back and from next request onwards it is taking only 5 to 6 seconds. Can any body give some suggestion to improve the performance?
Hello Chandra,
This happens basically because the first request creates a new Session on the Server and the subsequent requests use the same session ID to transmit the subsequent request. However 10 mins for the first request is quite extraordinary, looks to me like an application error or is there a external accelerator (in your case decelerator) card for SSL decryption that you use, this could be one potential reason.
-Rajesh Rao
What version/patch level are you running?
Just to make sure I understand - the document is coming in via an HTTP POST.
Is the POST coming through a proxy, load balancer or firewall that could be adding this overhead? You can get an idea of the true time in IS by turning on HTTP logging (at some level at or below 8) to see when the actually HTTP packet is received and returned (it is hard to map the trace back to the call payload if ANYTHING else is going on on that IS).
Is Port security turned on? Meaning are there filters on which IP addresses or domains can access that HTTP port? If so, IS must do a reverse DNS lookup on the client IP address to get the domain. Sometimes this lookup can take a long time. Our IT staff can do some magic to make that go away, although I don’t know specifically what they do.
HTH,
Fred
One more question, are you using LDAP for users/groups? If so, are you filtering the users to only those needed by the Integration Server?
In addition to the previous questions… if you happen to be running IS 6.01 and have not applied Fix 73, you may wish to. This fix addresses an issue where IS did a reverse DNS lookup of the client attaching to the server. This could match the symptoms you are seeing.
The first request takes a long time as you may have no DNS server configured [or it is unreachable] and the timeout may take a while, after that the negative DNS response is cached so following requests are quick].
James…
Hi Tim,
Yes i am using LDAP, Here are my LDAP setting. Can you guide me by looking the below setting.
Provider: LDAP
Server URL: ldap://10.10.10.10:1234
Directory Root: o=Buhr
Connection principal: uid=WMUser,ou=Special Users,o=Buhr
Connection credentials: WMUser
User Root: ou=People
User Filter: (uid=)
Group Root : ou=BuhrMessagingHub,ou=WebmethodsIntegrationServer,ou=groups
Group Filter: (cn=)
User ID attribute: uid
Password attribute: userpassword
Member attribute: uniquemember
Addt’l info (string): unspecified
Addt’l info (binary): unspecified
Timeout (ms): 259200000
I would take a look at the fixes mentioned above first before looking at your LDAP. This has nothing to do with the slow startup, but your ldap cache is set way too high for any scenario I’ve seen, it’s set to 3 days. Normally the requirement is to pick up changes to the directory in 5-10 minutes to an hour or so.
Bonda,
you have to first invoke a dsp page along with folderName:serviceName in your html template which is not done.use the below line in the begining
%invoke sample.dsp:Vw%
you can have to create this sample.dsp and store this template in IS/packages/pub/createfolder(Exercise)
For more information how to invoke,looping in dsp pages look into the
WmSamples package/dsp folder.There are sample services provided for Orders.
HTH,
RMG
Hi Tim,
I actually set the LDAP Timeout (ms) = 600000. However, every time the cache was expired, my IS admin user id (myadmin) was removed from the IS administrator (myadmins) group which was assigned to Administrators ACL.
FYI, myadmin user and myadmins group were defined in LDAP server only. myadmins group was not being removed from the Administrators ACL after the LDAP cache expired or even after IS Administrator rebooted.
I’ve never seen the behaviour you describe before, definitely not the way it is supposed to work.
Is ‘myadmin/myadmins’ defined in the local users.cnf file? They should not be if you are getting them from LDAP.
Hi Tim,
I managed to figure out the problem. It was due to the LDAP user wasn’t assign into the LDAP group.