PFQ's code is very old, and some of it is very bad. How much of it is actually needed?

Update - test conclusions and next steps TL;DR: I'm going to try turning off a thing that is supposed to be making the site work faster but might actually be breaking things. The game may lag a little more than usual during this test. Thank you for your patience. Let's give an example. Here's the steps taken to load a field full of Pokémon. 1. Ask database for the list of IDs of Pokémon in that field 2. For each ID... 2a. Check if the server-side cache knows of it 2b. If not, ask the database for it 3. For each unique species in the field... 3a. Check if the server-side cache knows of it 3b. If not, ask the database for it Checking the server-side cache involves checking for each column of the data row, because for some reason I thought it would be better to store columns individually rather than just storing the row as one single object. To try and reduce the amount of lookups, at some point I added code to only pre-load certain columns rather than all of them. Hypothetically (but not realistically) this could lead to a scenario where it would have all of the pre-loaded columns in cache, then proceed until it needed something extra that wasn't preloaded, realise that's not in cache, so would need to throw away the whole object and re-fetch it from the database. This is... not ideal. However the server-side cache does some very useful work. For instance, species data isn't going to change often at all, but is used a lot, so having it in memory is going to be a lot better than asking the database for it every time. According to stats, the server-side cache had about a 95% hit rate when it used to be set at 1 hour, but the downside was that in the case of a desync it would remain broken for that full hour. Reducing it to one minute greatly reduced the impact of desyncs, but also brought the hit rate down to 85%. The thing is, though, desyncs never went away. They just weren't noticed as much, because they had much less risk of being "clobbered" by subsequent actions. Lately though, EggSweeper has exposed desyncs quite a lot. If you've played it and seen one of your moves get reverted, that's a desync. Seeing how often they occur, I have to wonder if it's even worth having the cache at all if such desyncs are going to happen. So, experimentally, I am going to disable the server-side cache. This means that every request is going to go through the database, as the single Source of Truth. The downside, of course, being that the database is going to be asked for all of those 85% of data requests that would otherwise have been handled by the cache. It might not be so bad, though, because the database deals with entire rows at a time, whereas the cache was counting each individual column of the row one by one. The point is, I don't actually know how impactful the server-side cache really is. So let's turn it off and see what happens! This should not have any impact at all on how the game works. That's kind of the point of a cache. But if I had to sum it up... - Upside: Single source of truth (the database) means no desync errors can happen. - Downside: More requests to the database could be a bottleneck, meaning lag. We're going to find out what the impact of that downside is. I will be running this experiment for a few days to collect results, unless it's "really obviously important" in which case I'll turn it right back on again. In the meantime, I would really appreciate your patience if the lag is more than it usually is. I know lag is annoying, but patience will be the answer. (Can I just have PFNext's engine already? On PFNext loading a field is just "give me the things in the field, okay done bye")

Thanks for letting us know

Banner popped up out of nowhere after I read this post (I'm too fast for my own good sometimes). Thanks for the heads-up, hopefully there will be useful results!

Always best to experiment and tinker, hopefully this yields some useful info :)

I like experiments... Thank you for letting us know, and glad we could bring it to light with Eggsweeper reports? xD

Appreciate the heads up (and the banner!)

who knew something possibly so important would be revealed by Eggs

Thank you!

This is a lot of smart words which i do not understand fully, but is this the reason that, When i patry click via open 10 and click Next, for 10 new parties, 90% of the time the last party is loaded with 0 clicks given as first party of the new batch. Is that a desync thing?

No, that's just you clicking the Get More link before the system has actually received and processed your most recent set of clicks. This is a debouncing issue, not a desync issue, the fix for that is for me to have the UI disable the "Get More" link until all interactions are processed, but that's a minor thing for another time.