8

Let me preface this by saying I am not a systems administrator, I'm a programmer.

Recently, our systems administrators installed F5 load balancers. Since then, I've noticed that any time a request times out and ends up throwing a 500, the load balancer sends the same request to our other server. IIS sends the timeout response even though the script is actually still running. Even POST requests are duplicated if a script runs for more than 5 minutes. This seems like a potential issue to me, especially with e-commerce sites where customer billing is involved.

This is only a problem with a few of our longer running scripts (but it's a serious problem). I've been told that this is expected behavior, and we'll have to change our code to conform. So my questions are:

  • Is this expected behavior?
  • What is the advantage of the load balancer replicating the request after a timeout other than the user not having to refresh?
  • With this architecture, if a script that either bogs down the server or hogs resources is run, it will end up running on both servers. Is that really optimal?
Jim D
  • 133
  • 1
  • 5
  • When you say 'sends the same request' to the other server, are you referring to the configured health checks or user requests? My sense is no, but it's worth clarifying. The answer to this will change the answer and / or any suggestions. – mcauth Aug 25 '13 at 00:45
  • @mcauth it re-sends the user request. Basically if a user makes any action that prompts a 500 error, the load balancer sends the same exact request to the other server, thus creating two responses from a single HTTP request. – Jim D Aug 26 '13 at 15:16
  • 1
    I've been in the orbit of Big-IP for quite a long time, and I've never known it to replay a request unless specifically told to do so, say, via an iRule doing an HTTP::collect to buffer request payload. Very odd. Without seeing the running config it's very hard to say. – mcauth Sep 02 '13 at 12:16
  • Just bumping this thread a bit to let you know that I am hitting this exact same issue. Did you get any further on resolving it? – BitMask777 Jan 02 '14 at 16:51
  • @BitMask777 - Unfortunately we never really got any further with this. This is still the load balancer's behavior and we've been "dealing with it". – Jim D Jan 02 '14 at 18:30

2 Answers2

3

Have a look at this entry on passive application monitoring in Big-IP

My answers to your questions, as disappointing as they may be, are

  • Maybe (depends on passive monitoring config)

  • User doesn't see an error

  • Maybe (Do I want to serve my users errors or try the request somewhere else?)

"Action on Service Down" is a configurable setting.

quadruplebucky
  • 5,041
  • 18
  • 23
  • Thanks for your answer. You're right in that it's a bit disappointing, I was hoping for something more concrete. I guess it's concrete in explaining that there just is no definitive answer. – Jim D Aug 29 '13 at 13:18
0

If a 500 error occurs, this indicates a problem on the web server. The F5 will then simply forward this error along to the connecting client. It will not "re-send" the request of it's own accord. The only way this could happen is if the client re-tries the request. At that point, this request could possibly be load balanced to another pool member, though there is no guarantee and it would be based on either persistence or the load balancing method used (round robin, least connections, etc).

In short, unless you have some really crazy iRule on your F5, this is a behavior caused by the script itself.

(Note: I was a Nework Support Engineer for F5 for a year and a half working with the LTM)

James Shewey
  • 182
  • 14