Proof of concept: Application server - ~2400% laravel startup speed increase

Good stuff :-) There have been quite a few php app servers/workers appearing lately - you might want to have a look at some for inspiration, php-pm for instance :-)

I know this is different but Laravel on a ramdisk?

I know this is different but Laravel on a ramdisk?

Yes. On a ramdisk, every file included with require will still need to be loaded an parsed. With an appserver, the PHP script that ran require keeps running in memory so all the php include files are only parsed when the server starts, not every time someone visits a page.

Good stuff :-) There have been quite a few php app servers/workers appearing lately - you might want to have a look at some for inspiration, php-pm for instance :-)

Yeah, I've been working with Node.js recently and got used to the server approach. I created this over a year ago and thought I'd see if I could use it in the same way as Node :) This should be considerably faster than React as this uses sysv and react uses comparatively slower sockets.

There was another post on here with another app server - but now I can't find it. I think it worked in a similar way to yours - but it's a bit hazy ;-) Is the code up on the web somewhere?

The code is available on github here: https://github.com/Level-2/Aphplication :)

I shall try and have a play tomorrow - thanks! I've got the week off work so something to play with will help me avoid doing all the DIY and housework I was planning... ;-)

Oh yeah of course ramdisk is no different than normal (in terms of loading files) but just wondering how fast it would be to respond to requests :P

@TomButler Hi Tom, What is the memory model? How do applications share the same PHP VM? How can multiple calls to the webserver share the bootstrap without stepping on each other? In JAVA the classloader manages creating instances of a class running in the same VM. Am I just missing something here? Caching a result involves memory mapping to be truly effective. Memcache is nice but you still have to serialize it and copy it. Its no true caching because there is no shared address space.

@jimmck Yes, it doesn't use memcache because you can't share resources and serialization has some overhead. Here's an example of how it works.

Let's take a sample script:

<?php
require 'config.php';
require 'database.php';

$config = new Config();
$config->parse('x.json');

$database = new Database($config->getDbInfo());


//Now process the actual request

$result = $database->query('select foo from bar');

return json_encode($result);

This connects to the database and returns a resultset as JSON. Every time this script is run, config.php and database.php are parsed/executed and two objects, $database and $config are created. Only then can the script actually process the request.

Aphplication removes this bootstrapping logic. Here's how it works:

This code is moved into a server:

<?php
require 'config.php';
require 'database.php';

class App implements \Aphplication\Aphplication {
    private $config;
    private $database;

    public function __construct() {
        $this->config = new Config();
        $this->config->parse('x.json');
        $this->database = new Database($config->getDbInfo());
    }
    
    public function accept($appId, $sessionId, $get, $post, $server, $files, $cookie) {
        //Now process the actual request

        $result = $database->query('select foo from bar');

        return json_encode($result);
    }
}


//Now create an instance of the server 
$server = new \Aphplication\Server(new App());

//Check argv to allow starting and stopping the server
if (isset($argv[1]) && $argv[1] == 'stop') $server->shutdown();
else $server->start(); 

You'll see there are two parts: The boostrapping code in the constructor and the accept function.

The clever part here is the $server = new \Aphplication\Server(new App()); line. This will use the $app instance and create 24 PHP processes that keep running in memory in a paused state listening for messages using SYSV (think of it a bit like a database server, running in the background listening for connections).

When someone connects to the website, they don't connect to server.php they connect to client.php. This file is as simplistic as possible and contains some incredibly basic code. It sends a SYSV message saying "Run the accept function and give me the result`. The message is received by one of the active, running threads.

Because of the way that SYSV works, all 24 threads can listen to the same location. Whichever thread gets the message first (so the one that's least busy) will get the message, run the accept method and then use SYSV to send a message back to the the PHP scrip that sent the message in the first place (the client.php requested in the browser). Because the threads are always running, all that bootstrap code is already done. Each time someone connects, one of the threads run only the acccept method without needing to load config files, process all the includes or set up large object graphs.

Once the thread sends the result back, it pauses again and waits for the next message, always running in the background :) Each time someone connects the only code that's run on the server is the code in the accept method. Everything before that has already been done. And, once a request triggers the autoloader, that class is loaded and doesn't need to be loaded again until the server is restarted.