Newest at the top
| 2025-06-20 17:29:47 +0200 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 244 seconds) |
| 2025-06-20 17:27:27 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-06-20 17:25:26 +0200 | prdak | (~Thunderbi@user/prdak) prdak |
| 2025-06-20 17:24:32 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-06-20 17:24:28 +0200 | weary-traveler | (~user@user/user363627) (Ping timeout: 252 seconds) |
| 2025-06-20 17:24:23 +0200 | user363627 | (~user@user/user363627) user363627 |
| 2025-06-20 17:20:34 +0200 | trickard_ | (~trickard@cpe-60-98-47-163.wireline.com.au) |
| 2025-06-20 17:20:20 +0200 | trickard_ | (~trickard@cpe-60-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-06-20 17:19:49 +0200 | prdak | (~Thunderbi@user/prdak) (Read error: Connection reset by peer) |
| 2025-06-20 17:17:22 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-06-20 17:17:05 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-06-20 17:07:48 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-06-20 17:07:37 +0200 | ubert1 | ubert |
| 2025-06-20 17:07:37 +0200 | ubert | (~Thunderbi@2a02:8109:abb3:7000:3fad:3f8c:983d:e01d) (Ping timeout: 265 seconds) |
| 2025-06-20 17:05:42 +0200 | <tomsmeding> | or at least, the indicators are there, I didn't prove that all requests go through the pool |
| 2025-06-20 17:05:12 +0200 | caubert | (~caubert@user/caubert) (Ping timeout: 272 seconds) |
| 2025-06-20 17:05:04 +0200 | <tomsmeding> | https://docs.twisted.org/en/stable/api/twisted.enterprise.adbapi.ConnectionPool.html#__init__ |
| 2025-06-20 17:04:58 +0200 | <tomsmeding> | https://github.com/element-hq/synapse/blob/74ca7ae720c9fdb09a2271ade28d909132bd9b7b/docs/postgres.… |
| 2025-06-20 17:04:51 +0200 | <tomsmeding> | [exa]: seems to do pooling just fine |
| 2025-06-20 17:04:49 +0200 | ouilemur | (~jgmerritt@user/ouilemur) (Quit: WeeChat 4.6.3) |
| 2025-06-20 17:04:24 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-06-20 17:03:53 +0200 | ubert1 | (~Thunderbi@2a02:8109:abb3:7000:4172:3244:f389:d486) ubert |
| 2025-06-20 17:00:18 +0200 | caubert | (~caubert@user/caubert) caubert |
| 2025-06-20 16:53:51 +0200 | trickard_ | (~trickard@cpe-60-98-47-163.wireline.com.au) |
| 2025-06-20 16:53:37 +0200 | trickard | (~trickard@cpe-60-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-06-20 16:52:10 +0200 | <[exa]> | :D |
| 2025-06-20 16:52:07 +0200 | <[exa]> | I'd like to optimistically agree |
| 2025-06-20 16:50:59 +0200 | <tomsmeding> | I can't believe a large-scale Python webserver doesn't do DB connection pooling |
| 2025-06-20 16:50:43 +0200 | <tomsmeding> | isn't connection pooling like the most basic feature of every PHP web framework |
| 2025-06-20 16:50:30 +0200 | prdak | (~Thunderbi@user/prdak) prdak |
| 2025-06-20 16:50:29 +0200 | <[exa]> | I'd bet not |
| 2025-06-20 16:50:14 +0200 | <tomsmeding> | one would hope that synapse does connection pooling |
| 2025-06-20 16:49:48 +0200 | <[exa]> | btw not sure how it's nowadays but ~10 years ago the individual connections to postgres were quite resource-heavy, so if you threw some kind of pgbouncer in front of that and configured it to stream easy queries into say 2 connections, everything was suddenly very efficient |
| 2025-06-20 16:49:02 +0200 | <tomsmeding> | *wearing out, I guess |
| 2025-06-20 16:48:49 +0200 | <tomsmeding> | and if you run things on a stupid VM in the cloud, then wearing down disks is not your concern :p |
| 2025-06-20 16:48:04 +0200 | <[exa]> | postgres can be tuned down a lot, esp if you don't care about raw throughput |
| 2025-06-20 16:47:36 +0200 | <tomsmeding> | if you have more than a particular lower limit, then giving the DB less RAM just results in more disk IO and thus higher latency |
| 2025-06-20 16:47:22 +0200 | caubert | (~caubert@user/caubert) (Ping timeout: 252 seconds) |
| 2025-06-20 16:47:13 +0200 | <tomsmeding> | for databases, I tought that RAM is typically not a hard-required commodity |
| 2025-06-20 16:44:54 +0200 | <geekosaur> | not really yet, since I don't know how much RAM the new appservice will use. (one advantage of the HF plan is I should be able to use someone else's postgres, which as I said is currently the biggest memory hog) |
| 2025-06-20 16:44:13 +0200 | <tomsmeding> | (how expensive would this be) |
| 2025-06-20 16:43:55 +0200 | <tomsmeding> | geekosaur: do you have an idea of the specs of the machine you'd need? |
| 2025-06-20 16:42:51 +0200 | internatetional | (~nate@2001:448a:20a3:c2e5:62fe:762f:270f:e642) (Quit: CoreIRC for Android - www.coreirc.com) |
| 2025-06-20 16:41:55 +0200 | <geekosaur> | what I really want is for HF to sponsor me (request is in but have heard nothing yet) which will allow me to move it to IPv6-capable hosting and switch to appservice_irc (puppeted connections on both sides) |
| 2025-06-20 16:40:53 +0200 | <geekosaur> | right now it's untuned and the postgresql instance is using a fair amount |
| 2025-06-20 16:40:06 +0200 | <[exa]> | geekosaur: how much RAM does it need? I can throw it at a VM or so |
| 2025-06-20 16:38:09 +0200 | poscat | (~poscat@user/poscat) (Ping timeout: 248 seconds) |
| 2025-06-20 16:37:44 +0200 | <geekosaur> | on subsequent review, the disconnects seem to be me accidentally doing things that made the router reset/reconfigure (still figuring out what's safe), looking up. (last night's disconnect was me disabling wifi7 on 2.4 because it was interfering with bluetooth connections) |
| 2025-06-20 16:34:24 +0200 | poscat0x04 | (~poscat@user/poscat) poscat |
| 2025-06-20 16:34:06 +0200 | prdak | (~Thunderbi@user/prdak) (Read error: Connection reset by peer) |