Modx Manager Hangs Inconsistently on Internal Network

Some of our developers have been having issues with the manager hanging for up to 3 or 4 minutes. It’s a feast or famine type thing, where some days they’ll have to go home and work just because it’s so frustrating to wait, while other days the manager won’t hang at all.

This issue seems to only happen inside of the office. Computers accessing the manager externally have never gotten this issue to occur. On top of that, only certain developers have had the hanging issue affect them.

We run a dual wan network using load balancing. I’ve protocol locked the developer machines to a single wan port to avoid session errors. Inside the manager there appears to be an option to use https exclusively for sessions, but we’ve had zero success with that option as well. We are pretty certain that it is not the developer workstations, as we’ve moved some of them to offsite locations to test and see if the issue occurred.

Is it the case that manager operates on a different port than the default http port of 80? if so does anyone know which port?

Thank you for your time and assistance.

I’ve included the request system information:

Web Server:

PHP Version: php-5.2.9 Running via mod_php
Apache Version: Apache/2.0.52
OS Version: Red Hat Enterprise Linux ES release 4 (Nahant Update 7)

Database:

MySQL Version: mysql-4.1.22
There should be no databases over 1MB that modx accesses

MODx:

Version: 0.9.6.2
Default installation (no special changes)
Snippets shouldn’t affect the manager (according to the dev team)
Plugins: tinymce3101for manager (default/unchanged)
tinymce321 added by dev team but not used in the manager
Bottom Button Bar
Forgot Manager Login
Image TV Preview (7) - 1.2.0.2
Inherit Parent Template
QuickEdit
Search Highlighting (6) - 1.2.0.2

Browser/Client:

Browser name and version: Firefox 3, IE 6 & 7
Operating System and version: Windows XP SP3

Network Hardware:

Router: Netgear FVX538NA
ISP: Comcast Business

Your manager port is set from in your /manager/includes/config.inc.php file, derived from $_SERVER[’SERVER_PORT’].

Is your internal LAN a 192.168... net or a 10.... net for instance, do you run an internal DNS server for your office?.

I’ve seen strange effects before occasionally where accessing the site internally then accessing it externally causes stylesheets not to be loaded etc as internal hostnames are present in the CSS stylesheet paths, these obviously wont resolve externally, admittedly this has not been with the manager and 99% of the time it works as it should.

Clearing the cache on the affected machines seems to fix this.

In firefox what does firebug say when the fault occurs?

Thank you for your prompt response. We do have dns setup on one of the servers. The primary dns listed in all the clients ends up being the internal ip of the dns server, but in addition to it, the secondary dns ends up being the router, which even though it’s the internal ip of the router, I think that it gets it’s dns addresses from the wan ports, meaning comcast’s predetermined dns servers.

I’ll get one of the developers to see if they can’t get firebug to output some useful data. Thanks again.

Edit:

I’ve attached a screen shot of the output firebug gave one of the developers when got the manager to hang.

OK, re-running the manager login here on a 0.9.6.2 test install I have on localhost and cross-referring this to your supplied gif image the request your getting hung on is the one that has a post parameter of ’updateMsgCount true’ , it returns a content length of 3 and just updates the ’Inbox’ icon with the number of messages and unread ones. On my system this takes 1.2 secs, not the 1.65m your seeing.

The actual call just includes the file /manager/includes/messageCount.inc.php, this just prepares a bit of SQL, queries your database, gets the info, returns it and exits, nothing spectacular.

So, if this is the place it always fails in it looks as though this query is taking a long time, but, as you say it works from the outside, so do you have any probs getting to your MYSQL server from the inside that you know of? Or it could be that ’it just hung here this time’ and at other times it could be elsewhere. I can’t see any reason to do with dns/hostname resolution here unless you are not somehow resolving the host of your MYSQL server sometimes but that should affect both inside and outside equally I would have thought.

It just happens that it hung at that part. The manager will hang at random spots. As far as this hanging thing, we’ve seen something similar with gmail and google documents, where if you left your account open for a while and tried to open a different document or email, it would hang for a good amount of time. However, we resolved it by using the option in gmail to force it to use https and then protocol binding all https traffic to a single wan port. In this case, we’ve tried statically assigning an ip to a dev workstation and then forcing that ip to send all it’s traffic through a single wan port, but with no effect.

Hmm, the gmail thing may work because the google server is external to you whereas your MODx/Web server is internal to your workstations presumably and is routed differently. You can use https with MODx as set in the system configuration options but this will swap your whole site into https, not just manager access. To rule out DNS you could hard wire the address of your web server in the hosts file of your test client, it will resolve to this instantly now although it doesn’t sound like a DNS prob now. Also tail your apache access log when you log into the manager from your test client, you should see the POST requests/response in firebug matched in this log as apache sends the info back to you, if you get a hang ion your client have look what your servers doing.

the gmail thing may work because the google server is external to you whereas your MODx/Web server is internal to your workstations presumably and is routed differently.

Our webservers with modx on them are hosted at an external site. we use rackspace for hosting. Do you think that that might have an effect?

Ah, sorry, I’d assumed you were running your MODx installation on your RHEL servers.

OK, from the above posts its looking like you have some probs on your office network somewhere, if things like MODx, gmail etc. work from the outside but not the inside it is looking like this now. You can still however try and diagnose the problem, you can still tail your servers access logs and tie this up with your POST requests in firebug. Also is there any other apps you can access on your MODx servers such as a control panel of some sort or even phpMyAdmin. I suspect these would hang also. Do you have any other probs accessing internet sites from your office. i.e. slow page loads etc?

I apologize for the delayed response, I was out of town.

Thank you for the response, I’ll put dev on the task of trying to follow those logs. In the mean time, I’ll try my best to answer some of your questions.

As far as gmail working internally, we did have an issue with it, but once we specified that it should use https for sessions and then bound the https protocol to a single wan port we no longer encountered any hangs.

The rackspace servers that have modx on them also have a plesk interface, as well as some php management tools. Like gmail, we use to get hangs within those management tools, but the plesk interface uses port 8443, so once that port was bound to a specific wan port we no longer encountered any hangs.

In general, it seems like we have decent access and load speed to most websites. The connection is 2 cable connections that are 22/5 aggregated together.