Doctrine Entity Manager for Long Running Processes #6658

New Issue

admin · 2026-01-22T15:36:34+01:00

admin commented

2026-01-22 15:36:34 +01:00

Originally created by @aftabnaveed on GitHub (Mar 25, 2021).

We recently adapted swoole and are using it in production. Since it keeps our Laravel framework in memory thus eliminating the 50 ms boot time. On top of the that instead of keeping most of our Application configurations (read from XML) in cache we are now able to load it into memory during application startup thus tremandously optimising the response time. The accumlated time we are saving per request is now more than 100 ms which is a significant time for a heavy load and traffic website.

However, PHP is meant to be short lived processes and all the libraries and frameworks are built that way. We are able address to some of the framework related issues either by avoiding some of it's singleton pattern services such as Users, Sessions provided by them. We still re-use these services but instead we re-create these ourselves.

This does not seem to be so simple when dealing with Libraries, there are a few issues I would like to mention here which are specific to Doctrine PHP.

Opening and Closing a connection: Since the framework is now in memory what would be the best way to create an entity manager and open a database connection? Should we open a connection on each request and then close it when the response has been returned?
How many connections should open: In other languages like nodejs and golang there is a concept of connection pools, but it looks like PHP MYSQL does not have that ability, now is there a way in doctrine we can create a pool of a limited connections and then use that for making queries?

Although the performance benefits of using Doctrine in such an environment may not be that big, but due to the aforementioned scenario where you can put the entire framework and cofiguration in memory thus avoiding using cache, it would be great if a conversation like this opened and see the possibility of improvements.

Originally created by @aftabnaveed on GitHub (Mar 25, 2021). We recently adapted swoole and are using it in production. Since it keeps our Laravel framework in memory thus eliminating the 50 ms boot time. On top of the that instead of keeping most of our Application configurations (read from XML) in cache we are now able to load it into memory during application startup thus tremandously optimising the response time. The accumlated time we are saving per request is now more than 100 ms which is a significant time for a heavy load and traffic website. However, PHP is meant to be short lived processes and all the libraries and frameworks are built that way. We are able address to some of the framework related issues either by avoiding some of it's singleton pattern services such as Users, Sessions provided by them. We still re-use these services but instead we re-create these ourselves. This does not seem to be so simple when dealing with Libraries, there are a few issues I would like to mention here which are specific to Doctrine PHP. 1. **Opening and Closing a connection:** Since the framework is now in memory what would be the best way to create an entity manager and open a database connection? Should we open a connection on each request and then close it when the response has been returned? 2. **How many connections should open:** In other languages like nodejs and golang there is a concept of connection pools, but it looks like PHP MYSQL does not have that ability, now is there a way in doctrine we can create a pool of a limited connections and then use that for making queries? Although the performance benefits of using Doctrine in such an environment may not be that big, but due to the aforementioned scenario where you can put the entire framework and cofiguration in memory thus avoiding using cache, it would be great if a conversation like this opened and see the possibility of improvements.

admin closed this issue

2026-01-22 15:36:35 +01:00

admin commented

2026-01-22 15:36:35 +01:00

@beberlei commented on GitHub (Mar 26, 2021):

You need one entity manager and thus one commection per request because of the UnitOfWork. Doctrine is made for shared nothing architecture.

Some database drivers support persistent connections, which afaik is just connection pooling.

@beberlei commented on GitHub (Mar 26, 2021): You need one entity manager and thus one commection per request because of the UnitOfWork. Doctrine is made for shared nothing architecture. Some database drivers support persistent connections, which afaik is just connection pooling.

admin commented

2026-01-22 15:36:35 +01:00

@aftabnaveed commented on GitHub (Mar 26, 2021):

You need one entity manager and thus one commection per request because of the UnitOfWork. Doctrine is made for shared nothing architecture.

Got it! thanks for clarifying.

@aftabnaveed commented on GitHub (Mar 26, 2021): > You need one entity manager and thus one commection per request because of the UnitOfWork. Doctrine is made for shared nothing architecture. Got it! thanks for clarifying.

admin referenced this issue

2026-01-22 16:06:23 +01:00

[PR #6658] Drop explicit conflict with stable symfony/yaml #10089

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6658