1

I have a hosted webapp which requests data from a REST webservice in our office. Each page calls one (or several) webservices, which go from our host, via our firewall (a Watchguard Firebox) to a server in our office.

All of a sudden, the app has dramatically slowed. We have determined that the webservice is timing out at random when called externally (it's fine when called within the office network).

I'm pretty certain it's our connection which is dropping the webservice call, so I've written a quick php/curl script which calls the webservice over many iterations and shows the various timings.

Below is an example output, showing both a failed and a successful call (with a 5 second timeout):

    http_code           namelookup_time     connect_time        pretransfer_time    starttransfer_time  total_time          
1   0                   0.000096            0.0342              0.0000              0.0000              0.0342              
2   200                 0.000052            0.0332              0.1327              0.1751              0.1752              

As per iteration #1 above, failed requests seem to be failing between connect and pretransfer. I'm not sure if this shows that the connection is successfully past the firewall, or could the firewall still cause an issue?

Our firewall is showing a series of nondata event log messages for the relevant access rule. Our IT team tells me these are routine, although I can find no mention of these in Google. I'm not sure if this fits in between connect and pretransfer.

Having elinated the webservice server (by testing internally) and the live webapp (by testing different code on different external servers, I am left suspecting the connection to the office. Could the firebox nondata events be causing a problem between connect and pretransfer?

adam
  • 243
  • 2
  • 6
  • Sounds like a good fit for a packet capture. Preferably a correlated capture, with one from the client and one on the server at the same time. If it is quick and easy it is to reproduce, this should not be very large. – Greg Askew Oct 20 '12 at 13:38

0 Answers0