The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I have seen a huge site with a cold varnish cache and cold Drupal / memcache cache overloaded by these Drupal based pings - not being able to bootstrap quickly enough to reply to these pings, coming from several varnish caches / load balancers every N seconds.
It would be nice to have some kind of a "semaphore", for example execute the /ping code (causing Drupal to bootstrap) only if there is a "green light" - e.g. if a file (configurable path) on the filesystem exists or/and a drupal variable exists. If not, return a non-200 code.
That would enable to warm up the Drupal cache, before exposing the application to the varnish / load balancer check.
I'm afraid this logic cannot be implemented in this module, as it's likely hooked to the menu hook and therefore this logic cannot happen before the Drupal bootstrap.
To overcome that, I can see two technical solutions:
1) configure the varnish / load balancers to check a file first (say, site/default/files/ping.txt, i.e. no Drupal bootstrap) and only if it exists / the webserver returns HTTP 200 to that request, do the second check on the Drupal /ping URL (causing Drupal bootstrap).
2) Instead of calling two different healtchecks (static file, then the /ping), call one non-drupal php script, which checks the file and only if it exists, it will send back a 307 Temporary Redirect to the /ping url, otherwise a 404.
Please let me know whether I'm right the semaphore cannot be implemented inside the module code (while avoiding a bootstrap) and if yes, what your opinion is about the proposed solutions.
Marji
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | ping-add-micro-caching-2240177-3.patch | 2.38 KB | paulhudson |
Comments
Comment #1
skwashd commentedThe whole idea of this module is that it performs a full bootstrap. You would need to implement something outside of the normal Drupal APIs to achieve what you're after here.
Comment #2
paulhudson commentedI've also been concerned about this issue of flooding on a cold cache. In fact, apparently this was an issue for our app at some point. I found our health checks had been set to poll flat files as a work around.
The attached patch doesn't solve an initial cache stampede problem. However, to my mind so long as the requests aren't cache you have a persistent vulnerability to flooding.
I understand why it seems odd to want to cache these health checks but here's why it's a good option for my use case.
Validates:
- functionality of web server and vhost
- ability to parse PHP/Drupal
- Memcached is functional
- file system healthy
Downsides:
- Site configuration/data issues possibly return a false positive (server correct cached data till expiration, then blows up)
Mitigating facts:
- I'm implementing micro caching so lag in error reporting is a configurable and by default short 30 sec's
Something like the Varnish grace period would be cool so the first request warms the cache and other get stale content. That may kind of been achieved here since I'm returning the page output and then forcing cache regeneration on hook_exit(). Multiple requests in the same second probably end up in a race though.
Let me know your thoughts and ideas. Would be good to get something along these lines implemented.
Best,
Paul H
Comment #3
paulhudson commentedSome improvements with fresh eyes:
- correct typecasting from variable_get
- validate cache ttl before setting page to cache
- punctuation in code block
Comment #4
skwashd commentedAs discussed offline this goes against the idea of the module.