I think it depends. Not entirely sure though. Now given the context of Lemmy right, you can certainly post to instance C from both A and B. Even if your instance (either A or B) will not fetch messages from each other (due to not federating) you can always go see the messages through instance C (not logged in). That probably works for all defederation scenarios but that is also a very loosely defined interaction as both parties will have to do the same.
A diplomatic answer I know.
Don't like leaving anything to the imagination, right?
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.
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?
Also how's the setup? You setup for example 5 max children in fpm and 5 persistent connections? Per server? So your overall connections to the db server will be 5x your server instances?
If you setup 5 fpm children and less connections, one child will eventually reuse from another, but only when the connection is free (does not do a query for another process or pdo does not consume a resultset). If it tries to do a query at that time it will have to wait and it will block. This is my understanding. Also how you do transactions with persistent connections?
This has evolved into such an interesting conversation.
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
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!
Also, to work with persistent connections you will have to have a pool right? Because when you query from instance 1, the connection is not available until you consume the result set. Or is that only for MySQL?
It's not that there isn't the option, it's just that I don't know how to help you. MySQL has an option to reconnect, I suppose might be the same for postgres?
The single running process that was so easily dismissed, could save tons of queries, for example! Sorry I keep thinking about that direction
Fair point.
However why do you need persistent connections ? I am thinking that the growing rate of the connections should be very low as the instances increase, given that the queries are quick.
I haven't used persistent connections although I have been tempted in the past. I believe, if you haven't used it before, it might come with more trouble than it solves.
As an alternative I could propose using amphp (or maybe react PHP) which will let you handle a pool of connections in a single long running process. But it's a bigger change really, the more I think of it.
I've been working on a small TUI framework and sound was something I was wondering if possible to be done. My code is in PHP though not Rust. So this might give me some insight on how capturing works (I have no idea how sound works) but what I wanted to create is the capability (more or less) that for example TIC-80 provides where you have input from sound and make graphics respond to it (see Lovebyte jam sessions on youtube for example).
I really like the detail on the non filled ones where the last one on top might not always be a full one.