The live site doesn't respond instantly at all times

[mbacarella]

That is, I'm surprised by how sluggish it is for how simple the site's workload is. E.g. clicking the latest Culture War thread takes about 6 seconds.

Are there thoughts on what's causing this and what directions to go in to improve it?

[zorbathut]

Yeah, it's not great.

The page generation logic is complicated and slow. We've actually done some stuff to make it a lot better - it used to be worse - but it's still bad. Some possible solutions:

• We could spend time working on optimizing it further! I'm not sure what the pain points are at the moment, but there's definitely pain points somewhere. Part of our problem may end up being "we're generating a giant webpage with Python", and it's hard to figure out how to solve that one; I've come up with architectures that would let us start swapping performance-critical parts into Rust, but that's way out of scope of what we're currently able to do.

• We could upgrade the server! But we're already paying around $80/mo for various server fees. I am getting a surprising amount of money via Patreon at this point, and I could spend that money on this, but I'm not sure it's worth it for the marginal benefits. In addition, it might not even help - if we're bottlenecked on single-core performance, adding more cores ain't gonna be an improvement.

• We could cut down on the number of comments shown on the front page! But honestly it's already lower than I wish it was.

• We could upgrade to Python 3.11! We actually did this earlier . . . and then downgraded because we were getting crashes. It's unclear why - this just shouldn't be happening - and unfortunately I was never able to reproduce this in a test environment. But maybe the problem is fixed and we should try again?

• We could set up some kind of async-load so the front page loads very fast and then gradually loads other stuff! But that would be a huge amount of work and may actually end up feeling worse (personally, I hate pages that can't decide when they're done loading.)

The core problem comes down to a lack of manpower; our volunteers are great, but we're still very much bottlenecked by how many people we have available to put time into things.

[justcool393]

ref #285, #439, #490

[mbacarella]

We could spend time working on optimizing it further! I'm not sure what the pain points are at the moment, but there's definitely pain points somewhere. Part of our problem may end up being "we're generating a giant webpage with Python", and it's hard to figure out how to solve that one; I've come up with architectures that would let us start swapping performance-critical parts into Rust, but that's way out of scope of what we're currently able to do.

My vibe is this is trivial work that should take milliseconds so maybe I should pop the hood and take a closer look. I know Python doesn't do favors but it shouldn't introduce that much a burden.

[mbacarella]

(By this I mean I'll download this myself and get it running)

[zorbathut]

I'd appreciate help! It is worth noting that we did find a regression and fix it, so it should be faster than it was before.

A big slowdown here is the fact that this is Python talking to a SQL server; I agree that if it were all in memory on a fast language, it would take essentially no time. But that's not the environment we have, so it's a bit chunky.

If you're on Discord, come to https://discord.gg/KChpcdaNJC for the dev discord :)

[TLSM]

After 509332e (re-reducing SELECT query volume from 5 * (N comments) / req to ~60 / req after previously regressing), I did a clean flask seed_db and profiled against repeated requests of GET /post/1. Remaining expensive paths (percentages relative to route handler timeshare):

13% of the time in posts.py:178 (pagination logic) 10% in posts.py:189 (pagination logic) 7% in get_comment_trees_eager (requires modifying comment rendering logic to improve; legitimately the expensive core of the logic) 6% Jinja2 template compilation (got about 3% speedup using app.jinja_env.bytecode_cache = jinja2.FileSystemBytecodeCache() in __main__; noisy enough data that not an obvious improvement; memcaching might help) 32% in the comments.html Jinja2 macro (all the string templating)

About to put a PR up to fix the pagination voodoo and extend the eager loading to /viewmore/

[justcool393]

ref #504, #502

[mbacarella]

Hey I think the site is nice and snappy now and has been for months. Closing this. Thanks for what you do!