CMS and Site become nonresponsive

[aComAdi]

Hi,

I am aware that this is a very broad description of a problem - but that's because I could not narrow it down so far. I just wanted to see if others have made that exprience or if this is even a known issue.

On a regular basis, when logged into Processwire, the CMS and the front-end becomes nonresponsive. What happens is usually:

• User works for a while logged into the CMS and has another tab open, where she previews changes
• At some point, during a refresh/load of a new page IN THE CMS, the site is in an endles loading loop.
• When this happens, reloading the page, klicks on menu items, nothing responds. Closing the tab and and reopening in the same browser again results in endless loading loop (and eventual time out).
• When this happens, the front-end also cannot be loaded anymore in that browser.

It's noteworthy that:

• Opening the site  in another browser works
• Logging into Processwire in another browser works

This happens regularly across various setups:

• Different browsers (Chrome, Firefox - haven't seen on Safari yet, because that's usually the last one I use to keep edition after Chrome and Firefox are 'locked')
• Different servers
• Different PHP versions (most installs are on 7.2.)
• Different versions of PW. I had it on 3.0.128 up to 3.0.165 now.
• Having site in debug mode or not
• Having cache activate or not

Common to the installations is usually:

• Tracey Debugger
• RepeaterMatrix
• Rockmigrations

Has anybody experience this? I haven't had any complaints from the clients yet - but that doesn't mean it does not happen to them. Internally this does happen regularly. Almost during every longer work session.

Thanks for any insight.

Adrian

 

[dragan]

First things I'd do:

• check PW logs
• check server error logs (Apache / PHP)
• inspect in the browser (JS errors)

If you don't find any hints that way, you could see if it's a CSRF problem, or something to do with sessions. Switching to SessionHandlerDB can help (a core module). In one of my setups I had to put these two config values to false, when I encountered similar problems:

$config->protectCSRF = false;
$config->sessionFingerprint = false;

 

[teppo]

I've had similar issues with Chrome (probably because that's the only browser I really use) many times over, though not sure if it's ever occurred with a ProcessWire site. From your description it seems quite likely that "something" in the browser itself gets stuck — I'm really not an expert here, but again it's happened a number of times for me, and only things that seem to help are a) waiting until it goes away (could be a long wait), or b) rebooting the browser.

Pretty much just guessing here, but I'd suspect either some sort of JavaScript issue, a problem with a browser extension, some sort of network issue, or perhaps some piece of software installed locally. Ad blockers, for an example, are known to cause browsers to freeze, but typically only under some very specific conditions. (I've also helped clients debug some pretty weird issues cause by firewalls or virus scanners.)

Probably not very helpful, sorry; if you can see any console warnings or such please let us know, that'd make debugging much easier ?

[flydev]

Does the server(s) setup include NGINX ?

A server/php setting that could cause the browser hanging on a script instead of terminating it ?

 

Hard to tell without logs.

[aComAdi]

Hi,

Sorry for the late reply. First case of Corona in the company. All sorts of emergency actions necessary.

I will check @dragan's suggestions.

@flydev ??Relatively sure no NGINX involved in any of the incidences this occured.

Will report back if I find anything.

[aComAdi]

I figured, I will post the update:

Turns out the culprit is Tracey Debugger. Once turned off, this phenomenon does not happen anymore. Luckily we only need it during installation and development of new modules really. All editors are now working with Tracey off and the problem has disappeared. 

[dotnetic]

On 2/26/2021 at 7:48 AM, aComAdi said:

I figured, I will post the update:

Turns out the culprit is Tracey Debugger. Once turned off, this phenomenon does not happen anymore. Luckily we only need it during installation and development of new modules really. All editors are now working with Tracey off and the problem has disappeared. 

This could be because TracyDebugger loads Logfiles (by default?), namely Tracy Logs and ProcessWire Logs. If these files are large, it could take a while and make the site unresponsive. Try to disable them in Tracy's panel selector and see if that helps.

[adrian]

Hi @aComAdi - sorry about the problem with Tracy. 

You know, this is one of those strange things I have seen with Tracey on and off over the years. I actually just came across it again today, for the first time in a long time and @Robin S just PM'd me about it as well. In his case, it was the Field List & Values section in the RequestInfo panel, which once disabled fixed it for him.

For me it's when an image called on the frontend is not available. 

The weird thing I've noticed in the past is if I load all Tracy panels, then the problem goes away. I'd like to finally get this sorted out though. I thought I was the only one ever seeing it ?

I'll try to take another look soon, but I'd like to know if disabling the Field List & Values section fixes it for you, or if it is related to a missing image.

Thanks for your help in narrowing this down.

[aComAdi]

No worries. We greatly appreciate Tracy. 

I will work on a client site over the weekend and test these variations.

[aComAdi]

First report: Been working for an hour with Tracy on (iMac, Chrome Version 88.0.4324.192, PW 3.0.165, Tracy ).

In my case it's not connected to images. At the time that the 'lockup' happened, I had both the backend and frontend open in the same browser. Reloaded a page (with almost no content whatsoever) to test something. Then the endless load started. No missing images on this page. 

Note, that I currently have three bd-dumps on this page: 1 array, two booleans. 

[aComAdi]

Next lockup with log panels disabled.