happy january 24th! it’s not a holiday or anything, but we’re in the mood to be needlessly specific.
lots of performance fixes these past couple weeks while we continue work on tipping and some other new features in the background.
- we made notifications more reliable by fixing a design flaw in the way we count new notifications.
- under the hood, we used to keep count by keeping a cache of all the notifications you’d gotten recently and counting how many of them you hadn’t seen yet. if we weren’t tracking a cache for you, we would ignore new notifications, which would prevent the “unread” count from being updated.
- however, the cache can get discarded if the site needs to keep track of something else and doesn’t have the extra cache space, and the only way to get a notification cache when you didn’t have one already was to click on the notification page in the menu.
- this poses an in-retrospect-obvious UI problem: if your notification cache gets disposed in favor of something else, how are you ever going to know to check your notifications again?
- now we keep a separate count — which is tiny by comparison — and refer to that if you don’t have a cache.
- we don’t want to break notifications worse on the way to fixing them, so we’re doing a gradual rollout on this change to field bug reports as we go, but we expect the rollout to be pretty quick.
- we finally fixed the bookmarked tag feed performance issues. this went in almost two weeks ago but we didn’t want to say it out loud and jinx it.
- this should also drastically reduce the number of First Byte Timeouts everywhere on the site; in problem cases, the database could be kept busy for several minutes trying to do one page load, and if the affected user tried reloading the page a few times (as we’ve all been conditioned to do by flaky web sites) they could affect the performance of the entire service, necessitating a restart.
- why was this so difficult? because the problem kept causing site-wide outages, we kept attempting to fix it on an emergency basis. as we eventually realized, the performance could get bad in two separate cases — if you had a very small number of posts in your tags, or if you had a very large number of posts in your tags; the performance was always okay in the middle — and the easy fixes for each case made the performance worse for the other one.
- our solution was to keep a rough estimate of how many posts the site expects to see in your feed, and based on that, use one of the fixes if you’re closer to one end of the spectrum and the other if you’re closer to the other end.
- FREE BONUS: tag search is faster now too
- “sometimes both of your ideas are bad and the solution is to do both of them at once” is a depressingly common theme in software development.
- we made a modest site-wide performance improvement from checking if you’re an editor of a project fewer times per request.
- our error pages now actually serve the HTTP status code they’re supposed to. this was a very easy fix and we just had to go looking for it in code that we didn’t touch often.
- we started work on making the dashboard view simpler and more robust by removing some internal state that we didn’t need to track; this should be invisible from a user perspective for now.
before we go, we have something exciting to talk about… in a few weeks. here’s a hint for now:
see y’all next week! 
