Poor performance - is it modx, php, mysql or just my host?

Everett, are you saying the above info I found doesn’t help or doesn’t prove that there isn’t a DNS problem? Sorry this stuff is a bit over my head -- I’m "just" a web developer! Plus, this is a 3rd party shared hosting environment and I do not have access to make that kind of change or reboot Apache.

Hmmm... looks like I could add a hostname in the DNS manager... if I enter those values, e.g., an "A" record for test.advancesupply.ca pointing to 127.0.0.1, what should or shouldn’t happen? How do I test? What am I looking for?

No, if it’s on a shared host, that won’t work... what I’m trying to eliminate is the potential wait time for each request. If your page has links to your CSS/JS etc files, and they are referenced as "http://yoursite.com", then a request (requiring a lookup) is put out into the wild for yoursite.com -- that’s a domain name lookup when "yoursite.com" resolves to some IP address where your site actually lives.

By editing the hosts file, that call would never go out into the wild, it would get redirected immediately back to your server. So the thing I was trying to test was whether or not the delay happened when you put that request out to the wild. Editing the DNS entries for the site is editing the data "in the wild" -- so it’s too late in the food chain to test this particular thing. You should of course ensure that your entries are correct etc. but DO NOT make the changes you outlined -- it’s a different server entirely, so if you told THAT server (the DNS server) to redirect to itself (i.e. to 127.0.01), requests for yoursite.com would arrive at the DNS server, and then never leave. Make sense?

But why is your reverse DNS showing up as an ftp subdomain? That looks odd to me... maybe the FTP daemon is picking up the ringing phone on any requests... that would slow things down for sure. Just thinking out loud here...

I think the issue your having may have something to do with Revolution. I’m doing some unscientific testing on my site using Firefox and Firebug (Net Tab).

If I visit my site (amdbuilder.net) the first request (GET www.amdbuilder.net - 6.2KB) shows 3.16s waiting with connecting, sending, and receiving taking ms to complete.

If I run the same test on my evolution install (amdbuilder.net/evo) it spends 461ms waiting vs the 3.16 with Revolution. Granted I have a touch more content (little text), but not enough to justify the difference in my mind.

A similar wait can be noticed on other pages a second here and there... This install is also on a shared server. Checking another site on a VPS server the times seam inline with Evo, granted this site is all of about 47KB including images so it’s not a good test.

I suspect the delay is being caused by the processing overhead of revo that wasn’t present with evo...

That’s some pretty scientific "unscientific" testing you’re doing

Quote from: Everett at Aug 25, 2010, 12:19 AM

That’s some pretty scientific "unscientific" testing you’re doing

My brains too shot to call it scientific, if I did it about 2 hr ago then it would be scientific

AMDBuilder, thanks. There’s actually another thread on this forum that discusses the question of Evo vs Revo performance in depth, and while Revolution is a bit slower (again more noticeable with the Manager), it shouldn’t take 20-30 seconds to load a page (or time out). The Manager is simply unusable at that speed.

I’m guessing the issue is either the server or your internet connection... If you want to test the server theory shoot me and email username @gmail and I can hook you up with a test.

It wouldn’t hurt to test your connection speeds as well (speedtest.net is good site) to ensure that isn’t the problem.

Thanks AMDbuilder; I sent you an email (might have to check your spam folder).

It’s definitely not my connection speed as I don’t have issues with other sites. My download speed is around 4 Mbps.

Thought I should post an update. I was right that Bell hosting was the problem. I installed MODx on a completely different host (ethicalhost.ca) and now everything is fast. In addition, I think the fact that the Bell setup had different client/server versions of MySQL may have caused problems. The version numbers match in the new setup, and I suspect that’s the way it should be.