As you may have read, I’ve been refactoring a legacy application. I knew from the beginning there would be some performance loss using some of the heavy tools to make the application more robust, usable, scalable and future proofed. But I didn’t think it would be this bad*. Even with using the ‘composer dump-autoload -o’ function being run, there was a 35% performance decrease (cpu idle from 85% to 75%). So in real life, we still have a lot of head room, the response times are the same and a user wont notice even under our heaviest historical load. Still I don’t like that, so this part one of a multiple part series about making a performant application. You will be seeing the ups and downs of what I learn, things that worked for me plus how hard it was to do implement.
Part One – Pass one:
So after some determining, there was an issue on the ob_start and ob_get_contents (with out flushing) so the image was doubling which invalidated the cache every time so nginx wouldn’t cache. After changing this and removing the templating engine from the call the server has leveled out at more like 80-82% idle. With considering the much greater complexity of the application running now, that is more than understandable and even underwhelming considering what it is now doing. I’m pleased with this result and now performance tuning can occur outside of the application logic itself.
Part Two – Opcache:
(Write later, need to doing actual performance testing)