Since the issue with the forums breaking (wherein no one was able to get to the forums because all attempts to do so redirected to the main page, unless we used direct links), I've been noticing that opening a tab to the forums causes my browser to slow down tremendously.
Checking this over the past couple of days, it appears to be consistent.
I've been monitoring system activity, and immediately upon opening a tab to the forums, the Firefox Web Activity process jumps to 100+ percent for CPU load and stays there for several minutes. Attempting to open any forum thread repeats this activity. At no point does the process drop below 90% CPU.
Closing the tab immediately returns the process to its normal 6-9% activity state.
This only occurs with the Paizo forums, no other websites (not even the usually resource-hungry Facebook). I have not tested in other browsers.
Is there a back-end script or process call on the forums that could be chewing up resources like this? I'm hesitant to blame it on Firefox, given the behavior observed.
Color me curious.
Follow up - just posting this thread caused web activity to spike to over 100%, which it shouldn't do.
The activity spikes only occur while on the Paizo forums, and only while performing any form/navigation functions. Pushing a button, opening a new thread.
I'm positive it's not due to a browser update, as the browser hasn't been updated since well before the forum redirection issue.
The "activity" process is a child process of the main Firefox application, for all that it matters.
Testing in Chrome shows a severe spike (up to ~110%) when opening the forums. Navigating to this particular thread from the main forum landing page took approximately 3 seconds per navigation (main forum -> Website Feedback -> Website Feedback -> Thread).
Once it's here, Chrome steadies out.
Safari doesn't show anything unusual at all, which (if I'm being honest) is kind of odd, for Safari.
I'm willing to bet it's something specific to the Mac OS Firefox implementation that doesn't like a script on the forums, though that 3 second retrieve/render time for Chrome is bugging me.
Chief Technical Officer
|
| 1 person marked this as a favorite. |
We'll look into it, but the work we've been doing shouldn't have any user-side impact. This is just a hunch, but can you guys try dumping your browser caches?
Looks like everybody in this thread so far is using Firefox, either OS X or Windows. Any non-Firefox users seeing problems?
System Administrator
|
| 1 person marked this as a favorite. |
There are a few scripts that run on that page, mostly dealing with creating or removing certain content when click on a button. Very little in the background. But those scripts are largely referenced all over so I'm not sure what might be specific. I've not noticed anything super weird in firefox on my side on mac. The big thing is the massive insert of info from an ajax call for the forums information. There is a lot to render at first and since it's inserted as an ajax call it might be having some weird side effect but nothing has changed as far as I know. It's all the same scripts since forever. We don't change them super often and would have been at least about 3 weeks back.
Ugh, Ajax. Not as bad as some, but I've had bad experiences in my work history.
I've dumped my cache already, and should have mentioned that, but I'll dump it again, just in case.
As I said, I only started seeing this after the recent kerfluffle with the forums: before that, everything was peachy keen.
Thanks, Vic and Lissa!
Everything after clearing cache is still showing those spikes.
I'll keep watching on my end to see what I can see, but it's still only happening on the forums.
If I see anything that I can determine is off-kilter, I'll let you know.
|
Chief Technical Officer
|
If it's something to do with the AJAX call, I would expect the spike to begin at just about the same time that you might see a "spinny progress wheel thing*" appear on the page before the messageboard content loads.
Thing is, that should normally load so fast that if you have a decent computer and a decent internet connection, you should usually only see that progress wheel when you're asking it for something big, like the main messageboard page.
*Stop me if I get too technical!
As soon as the spike hits, approximately 50% of the time it does start to time out (the, as you put it, "spinny progress wheel thing"). This occurs whether:
Clicking a link to a thread
Clicking a link to a forum subsection ("Technical Issues" for instance)
Clicking Submit/Preview/Cancel/Reply (though not "Favorite")
It's almost as though the AJAX call is happening every time, when it shouldn't. It should just be loading on the first time I hit the forums, not whenever I navigate or mouseover in preparation for clicking on a link.
Oladon: Nope. I am adamantly anti-extension wherever possible, for precisely this purpose. Too many years in technical support.
|
I've complained about this before - this is not related to the recent changes I suspect. But it did seem to get better for a while in there. I gave up using Chrome (on a Mac platform) for this web site, and this web site only for that reason so I'm not completely sure when it seemed to get better.
In my case CPU usage ratchets up anytime I looked at a page in the message board area, but not the PRD.
|
Chief Technical Officer
|
This is probably not going to do much, but can you try disabling Firefox's "link prefetching" and "speculative preconnections"?
• In the address bar, type about:config and press Return. The about:config "This might void your warranty!" warning page may appear. Click "I accept the risk!" to continue to the about:config page.
• In the about:config page, search for the preference "network.http.speculative-parallel-limit". If its value is set to 0, it's already disabled. If it is set to a different value, write down that value, then double-click on it to set it to 0, which disables it.
• On the same page, search for the preference "network.prefetch-next". If its value is set to false, it's already disabled. If it is set to true, double-click on it to set it to false.
If that makes things better, let me know. If it doesn't (and it really *shouldn't*, as this page shouldn't trigger Firefox to use either of them), set them back to the values they had before.
This is probably not going to do much, but can you try disabling Firefox's "link prefetching" and "speculative preconnections"?
• In the address bar, type about:config and press Return. The about:config "This might void your warranty!" warning page may appear. Click "I accept the risk!" to continue to the about:config page.
• In the about:config page, search for the preference "network.http.speculative-parallel-limit". If its value is set to 0, it's already disabled. If it is set to a different value, write down that value, then double-click on it to set it to 0, which disables it.
• On the same page, search for the preference "network.prefetch-next". If its value is set to false, it's already disabled. If it is set to true, double-click on it to set it to false.If that makes things better, let me know. If it doesn't (and it really *shouldn't*, as this page shouldn't trigger Firefox to use either of them), set them back to the values they had before.
No change whatsoever.
| 1 person marked this as a favorite. |
Marking so that I have some ideas what to look for next time I try to submit a post and get a prolonged spinning disk on my Mac -- I thought it was an internet connection problem.
FWIW, I'm still seeing the spikes during all the normal day-to-day link-clicking operations here on the site.
I'm not willing to rule out client-side issues, here, but the fact that it occurs across browsers (again, except Safari - and never on iOS, which I find odd), makes me hesitant to do so.
Oladon - Nope. And I wouldn't be hitting the forums on one, as a matter of professionalism. (Too many years of conditioning not to do personal things on work property.)
Vic - Yes, as I mentioned on the 30th, I'm also seeing the spike on Chrome (Chromium engine). It's not as persistent as it is on Firefox, but I've seen retrieve/render times of up to 3 seconds on load/submit/mouseover.