Howto improve Flow performance

Hi all

Comparing our Flow demo application with those of Laravel and Symfony2, Flows response times are twice as high as in an optimized server setup.

I’ve already set the Flow context to production. Is there anything else that can cut down response times which doesn’t require installing things like Redis, etc.?

Thanks

Toco

Can’t really help you with this but if you figure things out it might be great to put it together with the input from the other topic I’ve created (Hoster Best Practice “Cookbook” or page) and write things down for other users in the documentation.

Using php-fpm instead of mod_php helps to speed things up a lot.
You can also try HHVM instead of it, I’ve heared it’s almost working.

We started running a setup on hhvm with Flow 3.0, which is mostly hhvm compatible and the performance increase over plain php (even with php-fpm and php7-rc1) was tremendously (talking one order of magnitude).
Other than that, you should put some of the flow caches to some shared memory storage like memcached or APCu (see http://www.michielroos.com/articles/use-memcached-as-your-neos-cache-backend.html).

Well, the possiblities are rather limited without cutting on framework features…:

  • try “composer update -o” to create an optimized ClassMap for class loading
  • create a special RequestHandler that does a reduced bootstrap and doesn’t initialize parts of the Framework that you don’t need (see Bootstrap::buildRuntimeSequence): Start removing components from the end of the bootstrap sequence (sessions, resources, persistence, reflection, … in that order)

One of the biggest resource wasters is the reflection service, even with all the caching that is already applied, but unfortunately it is a dependency of persistence.

Is there a tutorial or something like this on how to set up flow on hhvm or is it straightforward and if hhvm is running everything should work?

The latter, the worst that can happen is that some specific part of application code breaks, which you need to tackle. One thing we had was that Fluid templates caused a fatal error when non-CDATA’d Javascript was used.