Update on the issue (and the solution)

It seems like a possible solution (at least to me) is to probably avoid having a generator tab open with so many comment frames at once, as they’re constantly filling up the whole TCP connection with requests for listening for new comments every time, which is what’s causing the “stalled” problem every time I load and save generators.

See this comment for a reference.

Update 1: Now I’ve just sort of reproduced this by opening the Comments Plugin tab while one of my generators is saving, and then after the tab is being open and then closed, the saving process just stalled out of nowhere.

Recently I was hit by the problem where the saving process just stuck in the background, and when I checked the DevTools Network, there’s a lot of stalled connections when fetching a few resources required for the generator page to fully load. The stall eventually ends for a short time (1-30 min), but sometimes even longer (30-60 minutes), and even after that, it’s either still hangs on “saving” whatsoever, or it rolls back to the perviously “unsaved” state.

I also got the problem with loading generators too, where it hangs very frequently now, for the same reason, except that I sometimes get an ERR_QUIC_PROTOCOL_ERROR from the console whenever the generator fails to load after the stalled connections.

Is this maybe just because of the internet connection, my browser, or probably the “cache-busting” issue in the end? I tried logging into my other browser (Firefox) and saving the same generator and found no issues. It also loads generators perfectly fine.

  • BluePowerOPEnglish
    1·
    8 months ago

    Alright, that just happened again recently. Here’s a few more screenshots. The Complete the Number Blocktrains one indeed didn’t save as it still stuck on the saving process, well, until I pressed the reload button at the bottom of the preview panel.

    Also pinging dev @[email protected]

    • perchance@lemmy.worldMEnglish
      2·
      8 months ago

      Thank you for collecting those screenshots! Looks like you had to wait quite a while to capture that, and it’s very useful in working out what’s going on here.

      That said, I certainly haven’t got to the bottom of this. This SO answer: https://stackoverflow.com/a/29564247/11950764 says:

      Stalled/Blocking: Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation. Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome’s maximum six TCP connection per origin rule.

      Which seems to indicate that there may be other connections (possibly in other tabs?) which are somehow taking a really long time, and so are “hogging” all the connections that Chrome will allow to perchance.org Would be interesting to note how many Perchance tabs are open when this next occurs - to see if it’s more than ususal.

      One thing I did noticed is that you still have lots of singular requests to the generatorStats API on your generator manager:

      I posted a reply to one of your comments at some point about using the API to get a bunch of stats with a single request, like this:

      let generatorDataArray = await fetch("https://perchance.org/api/getGeneratorStats?names="+generatorNameArray.join(",")).then(r => r.json());

      Example: https://perchance.org/generator-list-with-stats-2-template#edit

      Not sure if that’ll help, but it might be worth a shot.

      Strange that it works fine in Firefox though. I wouldn’t rule out it being a problem with the Perchance server, because traffic has been increasing, so weird scaling problems can arise. I also see ERR_QUIC_PROTOCOL_ERROR sometimes, and I’ve tried to look into it, but to no avail. I’ll keep an eye on this and try to keep digging into potential causes. If you get any other clues (like that it doesn’t seem to be an issue on Firefox), I’d be glad to hear about them.

      • BluePowerOPEnglish
        1·
        7 months ago

        Okay, so I got some more reports today. I woke up and opened my browser with a tab heading to the Comments Plugin page, with all the comments sections already loaded up. Then, I opened my Generator Manager, and it loaded just as usual, but when I saved it, it took a really long time, up to around 30 minutes, with usual long-stalling requests initiated by the /api/cv request. It even spit out a Couldn't get generator dependencies error midway. I left only the Comments Plugin tab and the Generator Manager tab open for the rest of the time in the same browser while doing some outside work.

        After trying to save it again after a couple of minutes though, it did save pretty well.

        Update: Now, almost every time I opened and saved my Generator Manager, the other generators I’ve opened seems to start loading for a very long time, while the saving requests from the generator hub page also clogs out of nowhere. It’s in the 30-minute mark again.

        • BluePowerOPEnglish
          1·
          7 months ago

          Update again: There are some cases where the generator stalls at loading for an even longer time, from 40 minutes to almost an hour. The initial page load wasn’t stalled, only the generator load after the perchance framework was loaded.

          As shown in the screenshot below, I only left one other Perchance generator instance open and active during this period of time.

          • perchance@lemmy.worldMEnglish
            2·
            6 months ago

            Sorry for the delay on this (and many other posts by you and others!). This is a super annoying bug - it’s really important to me that Perchance is snappy, so I’m committed to solving this. I think I’m starting to get an idea of what’s happening here.

            For some reason the server isn’t properly closing the connection, or Cloudflare has a bug with HTTP/3 which means it sometimes doesn’t recognize when the connection has been closed, and this causes the browser to think that the content download is still in progress, even though it finished long ago. And that causes a stall while it waits. But it’s strange because I thought with HTTP/2 and HTTP/3 the browser could “multiplex” downloads over a single connection so I’m not sure why one download is stalling the others.

            I’ve disabled HTTP/3 for now to test if this was the issue. Can you let me know if it happens for you again? Also pinging @[email protected] in case you’ve run into this problem too. If this doesn’t work, then I suspect it has to do with the server getting a bit overloaded, and not ending connections properly (though this still wouldn’t explain the apparent lack of multiplexing, which I’ll have to investigate - maybe there’s still a concurrency limit and it’s being hit somehow), and in that case maybe it’s time for me to do a big server upgrade - in that case it’ll probably take me a week or two of work but it’ll be worth it.

            • VioneT@lemmy.worldMEnglish
              2·
              6 months ago

              I haven’t been editing/creating (and saving) generators lately, so I haven’t experienced some delays (might also because my timezone might be on the opposite where the traffic might be high). Also haven’t experienced it (or maybe not realized that there was a problem) so I’ll keep it in mind!

            • BluePowerOPEnglish
              1·
              6 months ago

              Great, thanks! I didn’t notice the delay yet, but I’ll reply once it happened again.

      • BluePowerOPEnglish
        1·
        8 months ago

        One thing I did noticed is that you still have lots of singular requests to the generatorStats API…

        Yeah, I know that and actually have been using it to calculate the total views thing, but the repetitive generatorStats requests isn’t necessarily a major problem anyways, but I think I’ll need to use that alternative technique to retrieve the generator stats for each of the generators there, I suspect that was a repetitive call of the generatorStats API for every generator item in the hub.

        And from this, I just got one suggestion for the generator-stats-plugin: What if you could do the same technique that you mentioned earlier within the plugin itself, those data you can then pass it through a variable, for example:

        genStats = [generatorStats("power-name", "power-hangman", "power-input-twister", ...)]

        And then, when you want to retrieve these data:

        The Power Name Generator has been viewed [genStats["power-name"].views] times and was edited [genStats["power-name"].lastEditTime].

        With that, everyone and not only me can use the names technique just by using the plugin. And thanks for the more descriptive explanation on the “connection stall” problem! 😊

      • BluePowerOPEnglish
        1·
        8 months ago

        Yeah, the TCP connections limit makes more sense now. I don’t have any time to find out the cause, but I suspect that’s the issue.

        • perchance@lemmy.worldMEnglish
          2·
          8 months ago

          I just fixed a bug with the saving process that was causing infinite “saving…” in some situations. Not sure if it’s related, but if you don’t see this problem again, then this bug fix was probably the reason.

          • BluePowerOPEnglish
            1·
            8 months ago

            Thanks! I’ll check it on my PC later.

      • BluePowerOPEnglish
        1·
        7 months ago

        The final lookout

        So, it turned out the “stalled connection” thing was probably the effect of having so many comment frames open under the “Comments Plugin” tab, each listening for new comments all the time, which is probably why it filled all the TCP connections that I ended up getting stalled connections so often while loading generators. I left that tab pinned for the rest of the browser session and thought that wasn’t the core problem first.

        And now, after switching the active pinned tab to the Comments Plugin Example page, which only has one comment frame, I somehow remedied the issue and haven’t been easily getting the connection problem again. But again, thank you for describing all of them!