Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Page load times
  • Hi,

    I have a site in FuelPHP 1.8 on which I typically get load times of around .2 of a second.
    I just set up a new site on FuelPHP 1.8.1.6 and the load times are considerably higher, around 1.4 seconds. Same machine, database, and models & controllers. Is there a reason for this increase and can it be mitigated?

    Quick Profiler samples:
    1.8
    SPEED    Fuel\Core\Profiler::init Start 26.289 ms
    SPEED    Fuel\Core\Fuel::init End 104.983 ms
    SPEED    Fuel\Core\Uri::__construct Start 106.121 ms
    SPEED    Fuel\Core\Uri::__construct End 106.375 ms
    SPEED    Fuel\Core\Request::execute: Start of admin/information 117.420 ms
    SPEED    Fuel\Core\Request::execute: End of admin/information 158.253 ms
    SPEED    End of Fuel Execution 202.697 ms

    1.8.1.6
    SPEED    Fuel\Core\Profiler::init Start 52.452 ms
    SPEED    Fuel\Core\Fuel::init End 573.767 ms
    SPEED    Fuel\Core\Uri::__construct Start 576.013 ms
    SPEED    Fuel\Core\Uri::__construct End 576.097 ms
    SPEED    Fuel\Core\Request::__construct Start route lookup 576.334 ms
    SPEED    Fuel\Core\Request::__construct End route lookup 594.574 ms
    SPEED    Fuel\Core\Request::execute: Start of admin/information 594.651 ms
    SPEED    Fuel\Core\Request::execute: End of admin/information 1.319 s
    SPEED    End of Fuel Execution 1.376 s
    Many thanks
  • Is this an average, or a one-time measurement?

    Because if I check the standard 1.9/dev welcome controller, on a 50 request test, I get values between 1.9s en 25ms, caused by environmental factors.

    The difference betwen 1.8 and 1.8.1.6 are just a few bugfixes, nothing that can cause an extra 400ms on Fuel::init (which hasn't changed in ages). I can't comment on what your admin controller does.
  • That was just one measurement of execution time, but I am seeing the pattern consistently. I just ran a couple of tests in Artillery to see what they return:

    1.8
    Summary report @ 10:55:03(+0000) 2018-12-14
      Scenarios launched:  50
      Scenarios completed: 50
      Requests completed:  50
      RPS sent: 4.84
      Request latency:
        min: 173.6
        max: 300.1
        median: 203
        p95: 246.5
        p99: 300.1
      Scenario counts:
        0: 50 (100%)
      Codes:
        200: 50

    1.8.1.6
    Summary report @ 10:54:29(+0000) 2018-12-14
      Scenarios launched:  50
      Scenarios completed: 50
      Requests completed:  50
      RPS sent: 2.47
      Request latency:
        min: 2047.8
        max: 12552
        median: 10716.3
        p95: 12281
        p99: 12552
      Scenario counts:
        0: 50 (100%)
      Codes:
        200: 50

     The controllers are the same, just a couple of db requests and then forge a view, set some css and js assets.

    I will keep reviewing my setup to see whether there are any substantive differences (e.g. changing dsn from localhost to 127.0.0.1 makes a difference of about .3 of a second.

    Thanks again. Fuel is great, have used it for many sites in the last 7 years.
  • That is a very unhealthy difference.

    We run all our apps, and the apps of most of our clients, on 1.9-dev, and haven't noticed anything significant. 

    I've ran an xdebug cachegrind on a dashboard page request of the app I'm currently working on, but I can't explain your figures.

    Between Profile-Start end Init-End (over 500ms in your profile output) nothing much happens, it takes 3% ( = 42ms ) of the request time in my app, the most of it in always_load(), waiting for I/O.

    The total request takes 1.842s, most of that time is spend inside ORM models (i.e. database I/O).

    Which PHP version are you on? Do you use the Crypt class a lot by any chance?
  • I'm on PHP 5.6.25 (yes, I should probably switch to 7).  The Session class is always loaded, I would say that's the only time Crypt is used.
  • Harro VertonHarro Verton
    Accepted Answer
    Ok.

    Crypt uses sodium now, and if libsodium isn't avalable, it will be emulated in PHP which is slow. But only one call shouldn't really matter.

    If you have xdebug active, can you make a trace file, and email that to me at wanwizard<at>fuelphp.com so I can analyse it?


    It's a big file, so please compress it as much as possible. ;-)
  • Thanks Harro, I'll try that.
  • After investigation, we found that it was due to libsodium not being present, causing Crypt to revert to PHP emulation, which was much slower on my setup (Windows, Wampserver). Installing libsodium (as per these instructions: https://stackoverflow.com/a/35609358/1720855 ) solved the issue.
    For comparison here is the same Artillery test as before on the 1.8.1.6 installation once libsodium is enabled:
    Summary report @ 14:56:31(+0000) 2018-12-17
      Scenarios launched:  50
      Scenarios completed: 50
      Requests completed:  50
      RPS sent: 4.86
      Request latency:
        min: 154.3
        max: 568.4
        median: 198.8
        p95: 324.3
        p99: 568.4
      Scenario counts:
        0: 50 (100%)
      Codes:
        200: 50

    Thanks again, Harro, for your help.
  • Thanks for the feedback. 

    I'll add this to the troubleshooting section of the docs.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion