Possible integration with Roadrunner and Swoole.

[iamkarshe]

Roadrunner is a high-performance PHP application server, load-balancer, and process manager written in Golang.

Integration existing FlightPHP application with Roadrunner would provide faster throughput.

https://roadrunner.dev/
https://openswoole.com/

[n0nag0n]

Oh I'm super on board with this, I just think that this will take more massaging to get to that point. I've done this for Fat-Free in https://github.com/n0nag0n/fatfree-swoole. My goal is to get flight to that point, but it's not the goal right now.

[n0nag0n]

If you want, you could fork core and make changes to see if you can get swoole running properly and then based on what you learn I could make the changes in core to handle a swoole/roadrunner/workerman/reactphp implementation. You could base it off of my fat-free swoole project, and I based that a lot off of https://github.com/pachico/slim-swoole which is now archived. It would just help save me a step of figuring out what needs to be unset/reset/rebuilt to work with swoole or some other framework.

[pierresh]

Hello,

Unless I am mistaken, there is a new library for such needs which do not require (much) code change called FrankenPHP.

[iamkarshe]

I was not able to run it (when trying it for first time) through custom 8000 port. as Caddyfile was somehow getting assigned to port 80 and running with sudo permission I was not very sure.

Can you share any working code for running FrakenPHP with FlightPHP.

It would be great.

[iamkarshe]

Sure let me try and get back to you with my findings.

[iamkarshe]

Ran simple application, using Docker.

https://github.com/iamkarshe/flightphp-starter/tree/master/with-frankenphp

I think script/CLI/worker mode, we need to explore.

Also any benchmark available for Roadrunner v/s Franken!?

[n0nag0n]

Hey that's awesome! So all those routes work out of the box, no modifications to Flight? I would have guessed you'd have to inject the super globals and rebuild the request() and response() for each request.

One of the tough things to work out is database connections. When you start up the app, you have to build up a database connection pool (say 50 connections) and then in the app you have to "borrow" a connection, use it, and then when you're done you "put it back" in the pool. It's a very different way of thinking compared to normal PHP.

[iamkarshe]

I am planning to do few things to test it out thoroughly.

• Create DB repository and pull large data (say 1000 rows) - checks DB access, shall run on MySQL, PostgreSQL and SQLite.
• Create User session and filter data based on that - checks sessions
• Create Cache store and proxy some data through it - checks Cache stores, Redis as backend may be
• Create Image thumbnail generation API - checks REST APIs
• Queue a job to Redis (queue image generation)

After thoughts,
Shall also buy three small droplets on Digital Ocean and host sample application there with shared DB instance and using sticky session load balance three nodes with above Flight app to check.

[n0nag0n]

Keep it up! That's really neat what you're doing!

[pierresh]

Hey that's awesome! So all those routes work out of the box, no modifications to Flight? I would have guessed you'd have to inject the super globals and rebuild the request() and response() for each request.

One of the tough things to work out is database connections. When you start up the app, you have to build up a database connection pool (say 50 connections) and then in the app you have to "borrow" a connection, use it, and then when you're done you "put it back" in the pool. It's a very different way of thinking compared to normal PHP.

Hello,

As I tested, there is no need to create a pool of connections as the database connection could be instantiated in the constructor of the Kernel class above, and then it can be used later on. FrankenPHP might be a solution to the MySQL's problem Too many connections :)

I tried to do some benchmarks (see code below), and I got impressive results as early I request a bit on the API (just continuous clicking on Refresh in browser). In standard mode, For 1 route definition + Flight::start(), the execution time is about 0.005s; with FrankenPHP, the average is around 0.001s, so 5 times faster! Without the database connection, FrankenPHP is even much faster. My config is a MacBook Pro with M2 and 16G RAM.

Another good news is that FlightPHP can catch $_POST, $_GET, etc.. in worker mode without being injected.

However, I found one problem: Flight::json() might send 2 or more times the JSON for the same request.

I tried to use vanilla PHP json_encode() and met the same problem.
Then I tried JsonResponse() from Symfony's JsonResponse, and that problem got solved. I checked the source code of http-foundation, but I have not found the core reason yet (I found code related to fastcgi_finish_request, litespeed_finish_request, etc... but copy/paste in Flight's send() method does not solve).

My code:

<?php
// index.php

use Symfony\Component\HttpFoundation\JsonResponse;

require 'vendor/autoload.php';

class Kernel
{
    private string $createdAt;
    private PDO $db;

    public function __construct()
    {
        $this->createdAt = date('Y-m-d H:i:s');
        $this->db = new PDO(
            'mysql:host=host.docker.internal;port=3306;dbname=XXX;charset=utf8mb4',
            'XXX',
            'XXX'
        );
    }

    public function handle(string $mode): void
    {
        $start_time = microtime(true);

        Flight::route('/', function () {});

        Flight::start();

        $query = $this->db->prepare("
            SELECT name
            FROM item
            LIMIT 1
        ");
        $query->execute();

        $item = $query->fetch();

        $end_time = microtime(true);

        // Calculate the execution time
        $execution_time = $end_time - $start_time;
        $execution_time_formatted = number_format($execution_time, 5);

        $r = Flight::request();

        (new JsonResponse([
            'mode' => $mode,
            'dbCreatedAt' => $this->createdAt,
            'now' => date('Y-m-d H:i:s'),
            'executionTime' => $execution_time_formatted,
            'flightQuery' => $r->query->getData(),
            'flightData' => $r->data->getData(),
        ]))->send();
    }
}

$myApp = new \Kernel();

// Uncomment below for standard mode
// echo $myApp->handle('standard');

// Comment below for standard mode
$handler = static function () use ($myApp) {
    echo $myApp->handle('worker');
};

for (
    $nbRequests = 0, $running = true;
    $nbRequests < 5 && $running;
    ++$nbRequests
) {
    $running = \frankenphp_handle_request($handler);

    gc_collect_cycles();
}

[n0nag0n]

So that's interesting about generating the json() response. There is another issue about streaming json and it has similar hiccups. It's really interesting to see this in action because it's understanding PHP on a totally different level where instead of it being linear execute of your scripts, it's cyclical and will keep calling the same code over and over again (almost like a compiled extension). Great work though!

[n0nag0n]

So I got this to work on Swoole, at least a crude example. It was the weird type of behavior I was expecting, and I needed a few hacks to get it to work properly (as well as some changes to the core to make it work)

Things I needed to change:

• response->getBody();
• engine->unregister();
• Needed to remap the engine->stop() method to not send the response();
• The route had to manually set the headers and such

$app->route('/', function() use ($app) {
	$app->response()->header('Content-Type', 'application/json');
	echo json_encode([
		'hello' => 'world'
	]);
});

And this was the gist of the $swoole->on('request'); method.

$server_vars = $request->server;
$server_vars = array_change_key_case($server_vars, CASE_UPPER);
$_SERVER = $server_vars;
$_GET = $request->get ?? [];
$_POST = $request->post ?? [];
$_COOKIE = $request->cookie ?? [];
$_FILES = $request->files ?? [];
$_REQUEST = array_merge($_GET, $_POST, $_COOKIE);

$Engine->start();

foreach($Engine->response()->headers() as $header => $value) {
    $response->header($header, $value);
}

$response->status($Engine->response()->status());
if($Engine->response()->getBody()) {
    $response->write($Engine->response()->getBody());
}

$Engine->unregister('response');
$Engine->unregister('request');
$Engine->register('response', 'flight\net\Response');
$Engine->register('request', 'flight\net\Request');

$response->end();

Once I finally got it working, it was a fun performance boost :)

With PHP Dev-Server:

Server Software:        
Server Hostname:        127.0.0.1
Server Port:            9501

Document Path:          /
Document Length:        17 bytes

Concurrency Level:      100
Time taken for tests:   0.192 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      192000 bytes
HTML transferred:       17000 bytes
Requests per second:    5221.85 [#/sec] (mean)
Time per request:       19.150 [ms] (mean)
Time per request:       0.192 [ms] (mean, across all concurrent requests)
Transfer rate:          979.10 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0       4
Processing:     1   18   5.4     17      28
Waiting:        1   18   5.3     17      28
Total:          4   19   4.9     17      28

Percentage of the requests served within a certain time (ms)
  50%     17
  66%     21
  75%     21
  80%     22
  90%     25
  95%     27
  98%     28
  99%     28
 100%     28 (longest request)

With Swoole Server:

Server Software:        swoole-http-server
Server Hostname:        127.0.0.1
Server Port:            9501

Document Path:          /
Document Length:        28 bytes

Concurrency Level:      100
Time taken for tests:   0.060 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      191000 bytes
HTML transferred:       28000 bytes
Requests per second:    16534.39 [#/sec] (mean)
Time per request:       6.048 [ms] (mean)
Time per request:       0.060 [ms] (mean, across all concurrent requests)
Transfer rate:          3084.05 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   0.8      2       4
Processing:     1    3   1.9      3      11
Waiting:        0    3   2.0      2      11
Total:          2    5   1.6      5      11

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      5
  75%      5
  80%      6
  90%      7
  95%      9
  98%     11
  99%     11
 100%     11 (longest request)

It was roughly 3x faster on Swoole! Pretty cool :)

[joanhey]

I think that we are going in the wrong direction !!

[n0nag0n]

Not sure what you mean? It's an old framework that's trying to cram itself into a tool that didn't exist for years after it was created 😅