Another week that didn’t quite go as planned…
In issue 2026-11 I was still happy about finally getting the Spring Cleaning update out of the door. But it quickly became apparent that something was awry…
I got reports left and right from players about abysmal performance…especially from players in Asia. At first, I thought this was a time-related thing, with bursts of traffic hitting the servers at a specific time, causing more issues for some timezones than others. But the server metrics provided absolutely no clue that would support that theory. Memory, CPU, even request numbers were more or less perfectly flat lines (within the usual fluctuations).
So my next suspect was the embedded web server I switched out for the release. It employs a different approach to how it handles requests, so I thought maybe there was a subtle issue caused by this change in behavior. One that might pass by my response time metrics for some reason, so it doesn’t show up in the charts. But after a lot of research, AI conversations and experimentation, this also looked like a dead-end.
As it’s so often the case, I discovered the solution (or at least I hope it’s the solution…so far it looks good, so fingers crossed) by pure accident while analysing client-side request statistics from a few players. The response times for a lot of files looked suspiciously long. The respective users were based in Asia, so latency almost certainly played a role here, given that our servers are located in Germany. But then it hit me: Why are those files downloaded on every request in the first place?! The files in question are static assets like client-side JavaScript, CSS stylesheets etc. Those get compiled during build and get assigned a cache-busting filename. That means that if the content of the file remains the same between builds, the filename stays the same as well and a browser knows that it can cache that file and doesn’t have to reload it.
But probably due to the Spring Cleaning framework updates, a subtle change snuck in that I missed: One middleware would add “no cache” headers to all files…including static assets. As a result, the servers were bombarded with requests for these files. Not an issue for the server, because serving these files is trivial. But it’s an issue for the clients, as it causes sluggish loads, jittery UI and weird timing issues if download times become too high. Some of those static assets are quite large, like the data files required to render maps, so they can block a whole bunch of requests for several seconds.
Once I told the middleware in question to behave, perceivable performance increased immediately. Even for me…with our servers effectively “in my neighborhood”.
Be that as it may: If you continue to see performance issues, please let me know and make sure to include the game world, airline, any pages particularly affected, a rough timeframe of when you encounter the issues and whether they are persistent or sporadic. Thanks a lot!
In other news: Timing-wise, I picked the perfect week to go on a business trip for the first time in a long while. I spent a day in Munich to participate in a pitch event at which developers were granted the opportunity to present a 4-minute pitch to a group of investors. I did one, too. Mostly for fun, as I am not actively seeking investments in simulogics at this time. But it felt good to speak in front of a crowd again and meet-up with a whole bunch of really nice indie developers to exchange war stories. Except for a few smaller meet-ups, I hadn’t done this properly since Covid.