FrankenPHP worker mode; what are the best practices regarding services resetting?

[Aielen]

Hello! I’ve been testing FrankenPHP for a few weeks, and I’m really impressed with the performance in worker mode.

However, I have a question about singletons, service resetting, and statefulness when using Symfony with FrankenPHP.

I understand that I need to implement the ResetInterface to reset the state of my services. I’ve tested FrankenPHP with 10,000 requests at a concurrency level of 100, and it worked flawlessly - the state was correctly reset for each request. But I’m curious about how this works under the hood, especially with concurrency.

Here’s my question: Imagine 100 parallel requests hitting the application. FrankenPHP needs to reset the service after each request to ensure consistency. But if everything is stored in RAM and there’s only one instance of a service (e.g., a singleton), how does FrankenPHP handle this? Does it create a separate copy of the service for each request? Or does it synchronize concurrency - perhaps pausing execution (like Thread.Stop()) until ResetInterface::reset() completes? For example, if my reset() method takes 5 seconds, would this latency stack up? Would the first request wait 0 seconds, the second 5 seconds, the third 10 seconds, the fourth 15 seconds, and so on?

Additionally, what are the best practices for managing statefulness and resetting state in FrankenPHP?

Let’s say I have an I/O-bound service, like one interacting with Redis, Memcached, or another cache storage.

Should I reconnect to the server within the reset() method, like this:

public function reset()
{
    $this->cache->reconnect();
}

Or should I handle reconnection lazily, only when I actually need to use the cache, like this:

class Cache
{
    public function get(string $key)
    {
        // Reconnect logic here, e.g., 
        $this->cache->reconnect();

        // Then normal logic, e.g., 
        return $this->cache->get($key);
    }
}

Which approach is recommended, and why?

[Aielen]

Also, regarding unhandled exceptions: what happens if something throws an exception inside the reset() method? How does FrankenPHP handle such scenarios?

[AlliBalliBaba]

Workers have a configured maximum number of threads, which limits how many requests can be run in parallel. Threads do share some memory, but in this case each thread has its own instance of the service.

You can reconnect to external services after each request, but it's usually better for performance to just keep the connection open across requests. The only time this is potentially problematic is if you forgot to commit a SQL TRANSACTion after a request. But in most cases it just makes IO more efficient.

Not sure how Symfony handles errors in its reset interface, but I imagine these would lead to a worker script restarting entirely, taking the performance hit to ensure safety.

[Aielen]

Thanks for your reply!

I have a few questions regarding the workers you mentioned:

Workers have a configured maximum number of threads, which limits how many requests can be run in parallel.

But what do you mean by "Workers"? Are "workers" actual processes or just threads? I'm asking because when I run ps aux, I only see one FrankenPHP process, even when using worker mode.

So does this mean that a worker is actually a thread that manages multiple threads to handle incoming requests? And does each thread have its own instance? For example, if I have 4 workers and each has 10 threads, does that mean I have 40 threads in total and 40 instances of a singleton service?

I'm asking because when I was testing it, I created a very simple service, something like this:

class Service 
{
   private int $a = 0;

   public function __construct() 
   {
        $this->a = 0;
   }

   public function incr(): void
   {
       $this->a = $this->a + 1;
   }
}

And without implementing the ResetInterface, the counter kept increasing continuously; 1, 2, 3, 4, 5, 6, 7, 8, and so on.

I assumed that if instances were created per thread (rather than a single global singleton instance), the behavior would look something like this (for, say, 3 threads): 1 1 1, 2 2 2, 3 3 3, 4 4 4, and so on.

So I'm curious; how does it actually work internally?

[AlliBalliBaba]

Yeah you are right, it will be 4 x 10 = 40 threads. Each thread has its own instance of the service. A worker is just a script that is executed by a configured amount of threads (calling frankenphp_handle_request). All threads run in a single process, even those of different worker scripts.

The reason you are seeing 1, 2, 3, 4, 5, 6 instead of 1, 1, 1, 2, 2, 2, 3, 3, 3 is that requests are dispatching to threads in order. So if thread 1 is busy, check thread 2, if thread 2 is busy, check thread 3 and so on. This helps workers be more efficient by primarily using the 'hot' threads and minimizes connections to external services.

It's also possible to start additional threads only once they are needed during runtime via the max_threads directive.

[Aielen]

The reason you are seeing 1, 2, 3, 4, 5, 6 instead of 1, 1, 1, 2, 2, 2, 3, 3, 3 is that requests are dispatching to threads in order. So if thread 1 is busy, check thread 2, if thread 2 is busy, check thread 3 and so on.

I just want to make sure I understand this part correctly.

So, I created another service:

class RandomService
{
    private int $randomNumber;

    public function __construct() {
        $this->randomNumber = mt_rand(0, PHP_INT_MAX);
    }

    public function getRandomNumber(): int
    {
        return $this->randomNumber;
    }
}

and another controller;

class TestController extends AbstractController
{
    public function __construct(private readonly RandomService $randomService)
    {
    }

    #[Route('/test')]
    public function test(): Response
    {
        return new Response($this->randomService->getRandomNumber());
    }
}

and now, without implementing the ResetInterface I always get the same number.

However when I add the sleep() function call;

    #[Route('/test')]
    public function test(): Response
    {
        sleep(10);
        return new Response($this->randomService->getRandomNumber());
    }

I get different numbers, so indeed, there is one instance per thread. I also noticed that these threads work very fast. All my requests were handled by only one thread - even when I used ab -n 1000 -c 100, I still got the same number, so I guess all requests were processed by that single thread. Amazing.

Okay, so now I understand it better:

1. Each thread has its own instance of every service.
2. The reset() method is called after execution, per thread that handled a request.

Now I’m thinking - since some threads may very rarely pick up requests, it might actually be better to re-open connections directly in the controller instead of doing it in the reset() method. Otherwise, from the moment, say, thread 33 calls reset() to the moment it handles the next request, a lot of time might have passed (literally even minutes if traffic is low), and the connection may already be closed.

[AlliBalliBaba]

Ideally you just keep the connection open. If reconnecting is absolutely necessary, it would probably be better for latency to do it after a request is finished.