0

I've created the following 2 openshift gear :

I've configured a quite complex caching mechanism based on FOSHttpCacheBundle that uses cache tags, ban, user context, ...

The website was running fine since yesterday, but this afternoon varnish was displaying a 503 guru meditation for all uncached requests.

The message in the log was : "no backend connection".

I logged on the varnish gear and indeed the backend gear (php 5.4) was not responding to curl's requests whereas it does from the internet (my local machine for example).

I restarted the 2 gears and the problem was solved ... but I suspect that the problem is not completly solved.

Is there any number of requests limitation from the same IP on openshift online to prevent DDOS attacks ? Because ALL requests to the backend gear are made from the same IP : varnish's gear IP, and my problem looks like a IP Ban ...

Note that my website does not have a high traffic as it as just been launched.

Romain
  • 101
  • 1

1 Answers1

0

There's not a builtin limit in OpenShift (of which I'm aware, anyway). I'd suspect your Symfony gear; you don't mention what the underlying webserver is (Apache? nginx? Other?), but all the major options implement a per-client throttling option, though I'm not aware that any of them turn it on by default. The best thing would be to replicate the problem, and then start debugging interactively—determine what the FPM processes (or Apache children) are doing, whether the TCP SYN is even reaching your webserver gear, etc. The problem should make itself apparent pretty quickly.

BMDan
  • 7,249
  • 2
  • 23
  • 34
  • The problem has not occured again. It seems that Symfony (on apache backend) has responded too much 500 erros. Since I fixed some errors the problem has'nt occured. I think that varnish had blacklisted my backend because of these errors. – Romain Feb 23 '15 at 07:54
  • Sure, okay, that could happen if you have a cached copy eligible to be served to your loopback connection, whereas your browser was unable to hit the backend. That would require you to have configured backend health checking in your Varnish VCL, though; by default, Varnish doesn't monitor backend health. If you can get it to happen again, `varnishlog` output would tell you exact how and why Varnish is routing (or not) the request. You can also check the "Age" header you are receiving, or add a cachebreaker (e.g. `?abc123`) to the URL, to make sure you aren't getting a cached response. – BMDan Feb 26 '15 at 19:41