Cache skip Laravel load about flatten HOT 12 CLOSED

Did some testing (ab -t 10 -c 10 http://mysite.dev/, APC enabled)
Without Flatten: +/- 16 requests/second
With Flatten: +/- 167 requests/second
Modified index.php to bypass Laravel and load cache file directly: +/- 2000 requests per second

Which essentially just writes a html file based on the hash of the path. I put the following on top of index.php

if(isset($_SERVER['REQUEST_URI']) && $_SERVER['REQUEST_METHOD'] === "GET"){
    $filename = __DIR__ .'/../app/storage/cache/flatten-'.md5($_SERVER['REQUEST_URI'] );
    if(file_exists($filename)){
        exit(file_get_contents($filename));
    }
}

(see the test changes in https://github.com/barryvdh/flatten/commit/f556156cf53a2e223af0ee0bd809c8e866f257c3)

And probably a htaccess approach would be slightly faster (because it doesn't even load php), but loading the file directly was about 22.000 instead of 20.000 requests in 10 sec, so not really big.

Offcourse this is just a simple test and maybe not very easy, but it seems to me that another 10x speed win is pretty big.

When you just let Laravel decide when to cache files, you only have to check if the file exists, right? (and if it is a GET request, and possibly of the login cookie is set). Only lifetime checking would not be possible (unless you run a cron job), but you can still purge on changes.

from flatten.

The problem is it's also a matter of ease of setup – if people need to edit the core files to make Flatten run I'm not sure most will use it. It could be facultative based on a method in Flatten's toolbelt though.

But the above solution would not work as not all people use a file-based cache, there's APC and all to take into account so Flatten has to use the core cache repository.

I'm open to any suggestion to make Flatten faster, so I'll look into this, see what I can dig.

from flatten.

Yes I understand it probably won't be a good default, but it might be possible to have is as an option, or even only when the filecache is used. What about:

if(isset($_SERVER['REQUEST_URI']) && $_SERVER['REQUEST_METHOD'] === "GET"){
    $key = "GET-".$_SERVER['REQUEST_URI'];
    $parts = array_slice(str_split($hash = md5($key), 2), 0, 2);
    $filename = __DIR__ .'/../app/storage/cache/'.join('/', $parts).'/'.$hash;
    if(file_exists($filename)){
        $contents = file_get_contents($filename);
        exit(unserialize(substr($contents, 10)));
    }
}

This uses the filecache, and doesn't require changes to how Flatten stores files.

from flatten.

Yes but the hash isn't just GET-{url}, you need to take into account everything in the saltshaker. But the idea is good, I'll see how I can implement it.

from flatten.

Currently the furthest back you can put Flatten is in bootstrap/autoload.php :

require __DIR__.'/../vendor/autoload.php';

/*
|--------------------------------------------------------------------------
| Launch Flatten
|--------------------------------------------------------------------------
*/

Flatten\Facades\Flatten::start();

As Flatten is already agnostic it doesn't really need any class from Laravel so just loading Composer is enough to make it work. The start method refers to Flatten\Flatten::start which is what's run in the service provider.

But from the tests I've made it doesn't speed up the process dramatically from running in said service provider, granted you put Flatten high enough in your service providers stack (ie. at least above all other packages).

from flatten.

I did apache benchmarks.
Op 24 aug. 2013 01:01 schreef "Maxime Fabre" [email protected] het
volgende:

How did you do your benchmarks ? I'd like to try out some things.
Currently the furthest back you can put Flatten is in
bootstrap/autoload.php :

require DIR.'/../vendor/autoload.php';
/|--------------------------------------------------------------------------| Launch Flatten|--------------------------------------------------------------------------/
Flatten\Facades\Flatten::start();

As Flatten is already agnostic it doesn't really need any class from
Laravel so just loading Composer is enough to make it work. The startmethod refers to
Flatten\Flatten::start which is what's run in the service provider.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-23196364
.

from flatten.

Yeah saw that afterwards. >_<

from flatten.

The real problem here is salts. If an user wants to cache its page differently whether the user is logged in or not, then I need to startup Laravel.

Now, Flatten knows which page it has in cache, so it technically has the storage path to each of those. Now let's say for kickstart, we ignore the saltshaker and load the request that most closely matches the current one – how do you decide of that. For an app I made I cached pages differently according to the selected language, if I don't have access to the saltshaker, which language do I load ?

Your proposition is very interesting and I'd like to add something like that but the above example doesn't even work because Composer itself takes a lot of time (in ms that is). To really boost performance you need to bypass Composer which means you're already quite limited in the choices you have.

from flatten.

What I think I'll do is add said kickstart method and allow the user to pass raw quicker versions of the saltshaker variables :

require 'vendor/anahkiasen/flatten/Flatten/src/Flatten.php';

$language = mysql_query('SELECT lang FROM settings')[etc I don't even remember how to use mysql_]
Flatten\Flatten::kickstart($language);

What do you think ?

from flatten.

Pushed a stub of the above on the develop branch.

from flatten.

Yeah ideally before composer indeed. About languages, I think every language should have it's own path and when a user is logged in, you probably don't want to cache the entire page.
I think this kickstart method is mainly useful for static pages, like a busy FrontPage or a blog that suddenly gets linked to by large sites.

from flatten.

My point is, "if the user wants to" I want him to be able to. As for skipping PHP entirely with mod_rewrite this is a bit trickier as the Laravel cache is hashed and not always file-based so doing that would require me to handle things a lot differently. :/

For languages it's different, there was already the locale in the URL, this was a different user-related setting. But yeah for most cases as the locale is in the URL it's already in the saltshaker by default.

from flatten.