2 ms·

> php-fpm re-bootstraps the framework on every request (10–50ms) What is the setup/benchmark that caused you to see this?

by nzeid 7d ago

EGreg 7d ago
It’s not about a benchmark. PHP-FPM executes your .php file from the beginning every time, so it does require(…) all the classes etc. and then proceeds to load the configuration from files etc. A good framework can maybe cache some of this with the opcode cache, and apcu. Saving some milliseconds. But regardless of all this, each worker process takes up a lot of memory (the entire framework, etc) which is often megabytes. By contrast, the Qbix webserver forks after you have loaded the classes. Being written in PHP actually gives it an advantage — the workers become much smaller and you can run 100x of them. This accomplishes what no other PHP webserver has managed to do: give you the speed of Swoole / FrankenPHP while at the samw time let you run unmodified PHP scripts in a “shared-nothing” fork environment, maintaining the strict isolation PHP is known for, so there are no memory leaks or data leaks between requests. Speaking of that, check out the “full-stack microservice” architecture that allows you to isolate your sensitive credentials / config from the main PHP process, preventing a host of attacks.
- nzeid 6d ago
  > A good framework can maybe cache some of this with the opcode cache, and apcu. Saving some milliseconds. This framing is confusing because OPcache has for the past 15 years taken care of exactly this bootstrapping you're worried about. In a competing share-nothing setup you merely come in at a tie for performance (barring first run of `require`). I do not see 10-50ms latencies in any of my deploys which is why I'm skeptical. That said, the big sell of your project for me might be memory management - less memory means more workers which is always a good thing if it comes at no cost to latency.
  - EGreg 6d ago
    Yep, you got it. The big difference is the memory savings, not as much the saving milliseconds per request, although that might be useful too if it takes 40-50ms to bootstrap and load configs every time.

> php-fpm re-bootstraps the framework on every request (10–50ms) What is the setup/benchmark that caused you to see this?

by nzeid 7d ago

> php-fpm re-bootstraps the framework on every request (10–50ms) What is the setup/benchmark that caused you to see this?

EGreg 7d ago

It’s not about a benchmark. PHP-FPM executes your .php file from the beginning every time, so it does require(…) all the classes etc. and then proceeds to load the configuration from files etc. A good framework can maybe cache some of this with the opcode cache, and apcu. Saving some milliseconds. But regardless of all this, each worker process takes up a lot of memory (the entire framework, etc) which is often megabytes. By contrast, the Qbix webserver forks after you have loaded the classes. Being written in PHP actually gives it an advantage — the workers become much smaller and you can run 100x of them. This accomplishes what no other PHP webserver has managed to do: give you the speed of Swoole / FrankenPHP while at the samw time let you run unmodified PHP scripts in a “shared-nothing” fork environment, maintaining the strict isolation PHP is known for, so there are no memory leaks or data leaks between requests. Speaking of that, check out the “full-stack microservice” architecture that allows you to isolate your sensitive credentials / config from the main PHP process, preventing a host of attacks.

nzeid 6d ago
> A good framework can maybe cache some of this with the opcode cache, and apcu. Saving some milliseconds. This framing is confusing because OPcache has for the past 15 years taken care of exactly this bootstrapping you're worried about. In a competing share-nothing setup you merely come in at a tie for performance (barring first run of `require`). I do not see 10-50ms latencies in any of my deploys which is why I'm skeptical. That said, the big sell of your project for me might be memory management - less memory means more workers which is always a good thing if it comes at no cost to latency.
- EGreg 6d ago
  Yep, you got it. The big difference is the memory savings, not as much the saving milliseconds per request, although that might be useful too if it takes 40-50ms to bootstrap and load configs every time.