Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PHP Superpowers with FrankenPHP

PHP Superpowers with FrankenPHP

Avatar for Mario Blazek

Mario Blazek

February 25, 2025
Tweet

More Decks by Mario Blazek

Other Decks in Programming

Transcript

  1. About me • Mario Blažek • Backend Team Lead @4ofthem

    • Married with children • Believes in Open Source • Zagreb PHP Meetup organizer (ZgPHP) • Chief Fire O ffi cer
  2. Existing setups • Apache + mod_php • Apache + php-fpm

    • Nginx + php-fpm • Standalone PHP servers (ReactPHP, Swoole, RoadRunner) • FrankenPHP
  3. Nginx • Event-driven architecture, handles thousands of concurrent requests e

    ff i ciently • Serves static fi les directly without passing requests to PHP • Load balancing and reverse proxy capabilities • Handles concurrent connections better than traditional web servers
  4. php-fpm (FastCGI Process Manager) • Handles dynamic PHP requests separately

    from the web server • Uses process pools (static, dynamic, ondemmand) to e ff i ciently manage multiple requests • Provides better security by isolating PHP execution from the web server • Allows tuning of worker processes, memory limits, and timeouts for performance optimization • Communicates with Nginx via FastCGI protocol
  5. Problems with nginx+fpm • Process model challenges • Inter-process communication

    overhead • Complex scaling • Resource consumption • Deployment complexity
  6. Franken to the game • PHP application server based on

    Caddy web server • One service! • Two modes: classic + worker • 103 Early Hints support • HTTP2 and HTTP3 native support
  7. Franken to the game • Developed by Kévin Dunglas •

    Symfony Core member • API Platform • Mercure • Vulcain
  8. Caddy web server • Modern and fast (event-driven, non- blocking

    architecture) • Caddy fi le - user friendly con fi guration • Automatic HTTPS • Works seamlessly as a reverse proxy, LB, cache and request forwarder • First-class support for PHP
  9. Superpower - worker mode • Boot your application once •

    Keep it in memory • Process incoming requests without having to boot your application again • Relies on goroutines and channels • Symfony Runtime compatible • Some resemblance with RoadRunner
  10. Symfony Runtime • Abstracts the application bootstrap logic into runtimes

    • Front controller remains generic • Basically application remains decoupled from the infrastructure • Di ff erent runtimes provided by community