GuestNo new alerts

Mini Benchmarks and Optimisation

- Announcements744
It's been quite a few months since I last did a benchmark, a long long time, so I've gone through the benchmark code and fixed it up, so that we can take a look at which areas have the most room for improvement.

The results may vary from computer to computer, it drops down to about 50k when I have Chrome shut, and I can probably close even more things, but I'm more interested in what I can improve than precise numbers here.

To explain the benchmark, the ops in the ops/ns bit are basically calls to the route. Each call to the route is one op, simple right?
The number to the left of the number of ops is the number of times that the benchmarker has called that function, faster functions are called more times to get a more precise result.

The stuff to the right of the ops per nanosecond are things related to memory like the number of memory allocations and the number of bytes per op (I'm not exactly sure what that means exactly myself, but I have a inkling of an idea of what it is, definitely memory related).

Topics refers to /topics/ which is also / by default, although you can change that to /forums/, if you like that better. And Forums refers to /forums/

Topic refers to /topic/1, the alt versions are to run the same benchmark again, as I was seeing some screwy results before, usually indicative of errors, but that's been fixed now.

In addition, we have data for how long it takes to fetch a user from memory (UserGet), and how long it takes to fetch the same user from the database (UserBypassGet).

First, we'll turn our attention to the routes, as this is where we can get the biggest gains.
As we can see from the benchmark, /forums/ is six times faster than /topic/ which in turn is five times than /topics/... Approximately. I'm eyeballing, so it might be slightly off, but that's the gist of it.

Interesting, right? Well, why is /topics/ so slow and /forums/ so fast. This is because /forums/ is served entirely from memory, while /topics/ consults the database for information, /topic/ is actually a hybrid and it's architecture is slightly different.

While things have shifted here and there and we fixed a problem with /topics/ growing endless a few months back due to the lack of pagination, it is still in a very... undesirable position, as it's one of the top routes surpassing even the traffic of /topic/

In addition to that, it's actually fairly easy to optimise, very easy in fact. But how will we do it? That's easy. We're going to cache the data, do we really need to fetch the data every request? Even if it changes once or two in half a hundred milliseconds, does it matter?

We're going to cache it. We'll fetch the data once every half a second, and then we'll just work with that until the next tick, and then we'll fetch it again. Rinse and repeat unto perpetuity.

By doing this, we should be able to bring the sluggish /topics/ down from a slow 300 microseconds (my competitors would hate to see me call that slow, but who can ignore a big optimisation staring them in the face?), oops more like 400 microseconds, down to a more manageable 10 microseconds.

Perhaps, not exactly, I'd love it to be faster than /forums/, but around there. In other words, we're going to make /topics/ faster by a factor of 40, an incredible improvement and it won't even take that long, more on this in the coming days.
P.S. I'm also going to fix the ridiculously big attachments on Cosora and the polls which don't belong on Shadow.
I've made some progress on the topic list caching, the first page of the topic list now loads 25 times faster for guests than it did before, I'm going to extend this to the other groups now.

Do bear in mind that this is a casual benchmark I did with a video running in the background, so in reality, it's likely an even bigger jump.
It's been fully implemented, committed and deployed. I have plans to refine it further, but for now, it's complete. I'll see about throwing another benchmark soon to see how it compares with the previous speeds.
I guess I spoke too soon, I've started adding more optimisations. As you're probably aware, Gosora stores the opening post in the topics table, this is in stark contrast to the methods I've seen used in some of our competitors.

This isn't inherently good or bad, but it does allow for a very interesting optimisation which I've overlooked upto now. I can just cut out the query to the replies table, if a topic reply count column is set to zero, which I have done and will be pushed in the next commit.

I've also reduced the number of queries run every second to stay synchronised with the database down by six for new / really small sites.

If this scares you, then please don't let it. You have to bear in mind that our competitors run the same queries, except on every request, so what we can do in ten or so queries every second, they would do in a hundred, or possibly a thousand queries per second (it goes up with the load).