Hey! 👋
Whether you’re an experienced PHP developer, a beginner just starting your journey, or an enthusiast interested in understanding more about the world of PHP, this is the place for you. We are a community dedicated to sharing knowledge, discussing new trends, and solving problems related to PHP.
As members of this community, we expect everyone to respect each other and foster a positive environment. Please make sure your posts are relevant to PHP, and remember to be kind and considerate in your discussions. Let’s learn from each other and help each other grow.
Whether you’re here to ask questions or to share your knowledge, we’re excited to have you here. Let’s make the most of this community together!
Welcome to /c/php! 🐘
You can check with is_resource maybe?
With the single process, you can cache queries in memory depending on how the data change for example and the frequency they have.
The manual https://www.php.net/manual/en/pdo.connections.php
Has some interesting notes and also
https://www.php.net/manual/en/function.pg-connect.php
Mentions a force_new kind of setting if you need. I think not PDO but the constant you might be able to pass.
Also SO has some stuff users say
https://stackoverflow.com/questions/3332074/what-are-the-disadvantages-of-using-persistent-connection-in-pdo
Personally, I don’t try to optimize so hard in PHP (5 to 10ms due to db connection). There is always an improvement on the way things work, like how the code works that would probably give you a magnitude of performance. Just saying!
So I finally found the time, and also my issue - it was a PEBKAC all along.
My retry loop was written so haphazardly, that it was stuck in an infinite loop after experiencing rebalancing, instead of correcting it.
After fixing that, it all works as expected. There was no issue with persistent connections after all. Rebalancing halts the benchmark for 3 seconds, then traffic re-routes itself to the correct node.
The current set-up is three node cluster Postgres + PHP, with HAProxy routing the pg connects to the writeable node, and one nginx load balancer/reverse proxy. I tried PgBouncer with and without persistent PHP connects, and it made little to no measurable difference.
The whole deal is a Proof of Concept for replacing current production project, that is written in Perl+MySQL (PXC). And I dislike both with such burning passion, that I’m willing to use my free time to replace both.
And from my tests it seems that Patroni cluster can fully replace the multi-master cluster with auto-failover, and we can do switch-over without losing a single request.
Glad to hear it. All of it actually. Sounds you are content with it now.
Had to Google PEBKAC. Aren’t all problems like that?
That’s more of a philosophical question.
My only current issue with PHP is resource handling, and the lack of ability to share sockets between threads/fibers. Erlang actually does this so well, it’s a shame that language isn’t more used, and so managers are afraid of it.
Back to the question: is the resource sharing an issue with PHP, or is it my PEBKAC that I’m trying to bend PHP to something it wasn’t designed for?
At a first level it certainly is an issue with PHP, but PHP was also designed by a human. That design comes with its own problems right? I guess what I said is just a generalisation of PEBKAC as all (mostly all) software is designed by some human. Fact that it’s a different chair may as well be considered not a PEBKAC ? Yes it’s philosophical or simply which perspective you choose to see.
Haven’t played with amphp/parallel but maybe worth a look to see how/if sockets are shared there.
Yeah, for a PHP socket server, the best route would be going React/Amp route, as building a custom event loop is a big undertaking, and anyone will shoot themselves in the foot or worse.
Since they are single process loops, you don’t need to ‘share’ them, as they all belong to the only process. But that does limit you to a single process.