Hi,
We just migrated to fuel, from a basic infrastructure (no framework).
While I really like the fuel framework, I see a performance hit on the server side.
I was expecting things to go slower using a framework, but would like to see if there is anything I can do to reduce the impact.
Currently on a crappy server, counting only the server time (excluding latency, etc.., purely measured from fuel profiler), it takes about 170ms for a given request, compared to 20ms before (roughly the same code logic, same server, same database).
I've used the fuel profiler to try to identify where the 170ms are coming from, but I actually can't pinpoint where the 170ms are taken. For some strange reasons I can't explain, I see a jump or 2 of about 80s between Profiler log entries (I used a lot Profiler::mark()) at random places in the code (it varies for each request to the same url). That doesn't make sense to me unless there is some asynchronous activity going on in the background slowing down the server randomly, but I am not a php expert...Also the database queries are not the cause of those 170ms apparently.
On production server, the response time with fuel is much better (not used the profiler, but i think it's about 100ms), so it's not too bad.
That said, when we do a redirect from fuel, it makes a total of 200ms on the server side for a request which isn't great.
So are there any tricks to improve performance a little bit?
for example I noticed that the cookie are pretty long, and might be encrypted (not sure if that's true), maybe i can disable that..
Or maybe I can load less php code somehow?
Laurent
That's very interesting, as FuelPHP is one of the fastest frameworks around.
If you refer to session cookies, yes, they are encrypted, and can get quite long. We use pbkdf2() encryption, which can be processor intensive on poor hardware. You should not use cookie based sessions if you can avoid it.
There are a lot of options to increase the speed of an application, but how greatly depends on the application, so I can't give you direct advice. Measure, and if the profiler is inconclusive, run an xdebug trace, to see exactly where the performance goes to.
Usually the slowest part of any app is database I/O. If you say that isn't the case, you must have some code issue somewhere.
I am using the file driver for session cookie, so I see no value in encrypting them (since I assume only a session id is stored, no user data). If i am right, is there any simple way to disable the encryption of the session id? I'd rather save cpu and bandwidth, even if it's a little only.
For debugging performance, I am going to first try on a different server first, maybe that specific server has an issue; i am just very surprised that the performance hit is random in the code, but the total is consistently >150ms; could very well be a server issue (I am on a virtual machine, so I wouldn't be surprised).
There is a bunch of fuel code/packages we don't use (email, etc...), so if there is any option to load those those, I'd be interested in testing that..
It is encrypted to protect the cookie against hijacking and tampering. In an unencrypted cookie you can modify the session id (by a stolen one) and hijack someone else's session.
Fuel doesn't load anything that isn't needed. So classes or packages you don't use will not be loaded, and don't cost performance or memory.
Check if your server is swapping, or hitting the apache limits so it waits with starting a process. Other processes on the server that use performance?
I run fairly large applications with a large user population in a 512Mb ESX VM without any performance issues, so if it's the framework I would really want to know what it is.
All Framework classes are manually added to the autoloader cache, so no file I/O is needed to find and load them. This happens in the bootstrap file of the core and all packages.
By default app and module classes are loaded dynamically, but you can define them in the (app) bootstrap too.
In general, optimisation and speed is always in the front of our minds when making changes to the framework. We've recently made improvements to Config and Lang by using intelligent caching and greatly reducing Arr calls which are expensive.
We run regular xdebug traces on the core code to identify potential candidates for optimization. I've already suggested to do the same on the app in question, to see exactly where the issue is.
But given the fact that the issues are at random places in the code according to the TS, my first suspect is the server itself. If it's a shared system (and a VPS is) and/or it's poorly spec'd, then the amount of resources you get can vary greatly from request to request.
Donate
