Hi Ralf, On 7 July 2014 10:44, Ralf Eggert <[email protected]> wrote:
> Hi Marco, > > thanks for your ideas. > > > Did you consider caching at HTTP level first? > > Yep. I have set the following: > > Cache-Control: cache, store > Expires: Thu, 01 Dec 1983 20:00:00 GMT > Etag: 2e922b7d992758b1ee143aa70cf2ab05 > Pragma: cache > > But with no effect. > Is there a varnish instance in front of it? Are you stripping cookies? > ZeffMu plays quite aggressively with that: > https://github.com/BinaryKitten/ZeffMu Nice one. Will have a closer look at it, when the view manager > replacement does not have much effect. That's just to give you some ideas, it isn't the actual solution. > > I never really bothered going lower than that. Caching is the way if > it's > > just simple responses without no interference (Remember to set up cache > > purging correctly) > > A proper cache purging might be quite complicated in this case. The data > returned is geographical nested set data. Purge the cache properly when > one node changes is not just done by clearing the cache for all children > and parent and siblings. I will try to work on a concept when all the > other stuff is leading nowhere. > A listener would do fine in this case, and would basically do the equivalent of `curl -X PURGE ...` against the http cache proxy. Another thing to try is using a dedicated `EventManager` instance that has no `SharedEventManager` for instances that are not requiring that kind of flexibility. This *may* break things, so be careful. Additionally, move your modules' autoloading to `composer.json` and use a classmap via `./composer.phar dump-auoload --optimize`. HHVM is also a neat suggestion, but don't expect miracles from it: it just makes repeated operations faster. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
