2025/06/20

Newest at the top

2025-06-20 17:05:12 +0200caubert(~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 +0200ouilemur(~jgmerritt@user/ouilemur) (Quit: WeeChat 4.6.3)
2025-06-20 17:04:24 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-06-20 17:03:53 +0200ubert1(~Thunderbi@2a02:8109:abb3:7000:4172:3244:f389:d486) ubert
2025-06-20 17:00:18 +0200caubert(~caubert@user/caubert) caubert
2025-06-20 16:53:51 +0200trickard_(~trickard@cpe-60-98-47-163.wireline.com.au)
2025-06-20 16:53:37 +0200trickard(~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 +0200prdak(~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 +0200caubert(~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 +0200internatetional(~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 +0200poscat(~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 +0200poscat0x04(~poscat@user/poscat) poscat
2025-06-20 16:34:06 +0200prdak(~Thunderbi@user/prdak) (Read error: Connection reset by peer)
2025-06-20 16:32:26 +0200acidjnk(~acidjnk@p200300d6e70b66965c15a2f63f07173a.dip0.t-ipconnect.de) acidjnk
2025-06-20 16:28:25 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-06-20 16:28:03 +0200sord937(~sord937@gateway/tor-sasl/sord937) sord937
2025-06-20 16:28:00 +0200CiaoSen(~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds)
2025-06-20 16:27:43 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2025-06-20 16:27:43 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection)
2025-06-20 16:26:44 +0200poscat(~poscat@user/poscat) poscat
2025-06-20 16:25:57 +0200acidjnk(~acidjnk@p200300d6e70b6624416fe602ae3a0480.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2025-06-20 16:23:23 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-06-20 16:20:49 +0200machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2025-06-20 16:20:47 +0200Sgeo(~Sgeo@user/sgeo) Sgeo
2025-06-20 16:12:01 +0200sus0(zero@user/zeromomentum) zeromomentum
2025-06-20 16:03:27 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds)
2025-06-20 16:01:15 +0200Square(~Square@user/square) Square
2025-06-20 15:57:52 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)