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