Ask a Jedi: Is my site slow because of Ajax or something else?

Paul asks:

I've been working on a project using Mach-II and Spry, which can be viewed at here. I'm using a Spry master-detail layout on each pages. All of the content is stored in xml files. So, I have Spry datasource configured for each page also.

I'm wondering if the slow page loading is related to Mach-II or Spry. The site is running on a shared hosted server (viux.com). If it's related to Spry, then could some of the problem be resolved by pre-loading the data sources somehow. If so, how would that be done with Mach-II.

I see you've delved into Spry, just not sure how far, or whether my question even makes sense. Anyway, let me know if you can help. I've trawled through Google and not getting many answers. Other people have complained about the slow loading on the Adobe website, but no answer was furnished to that particular point.

Perhaps if you browse my website as shown above, you can see what I mean. The page initially loads real slow, but after its loaded, it's fine. But customers will be gone before that happens.

When it comes to answering "Why is my page slow", there are a number of things you need to look at. A typical request to a ColdFusion site normally involves these items:

  • User request URL X.
  • CF works on creating the response to X.
  • CF returns a response (just a stream of text) to the browser.
  • The browser renders the response. This may involve more HTTP requests for CSS, images, and Ajax items.

So which of the above is the slow portion of your site? It seems like the response from the server is a bit slow. Since you are using Mach-II, one of the first things I'd check into is to see if the framework is reloading. If Mach-II is like Model-Glue, there is a setting that determines if the entire framework should reload on every request. This can really slow down the response and you are recommended to turn this off in production. I'd bet Mach-II is the same, and I'd check there first.

My gut here says the issue isn't Ajax. Using Firebug (you are using Firebug, right?) I see that your XML being returned is very little (3KB). Your Spry files look fat, so I'd be willing to bet you aren't using the minimized versions. I'd switch to that.

You also want to get the YSlow plugin to Firebug. As you can guess, it tries to tell you why your site is slow. Your grade was an F, but I'm not sure why. Most of the things it failed you on seemed minimal to me. Your C for JavaScript files doesn't surprise me.

How good is the connection to your site? It may just be the network between here and there. Since your site involves China goods, I'm guessing it may actually be in China. Is it? If so then you could always consider multiple servers based on the location of the requestor. (I've never done that myself.)

I'll let others chime in as well on things they may see in the request.

Comments (16) Apr 7, 2008 10:40 AM Views: 1437

Comments

[Add Comment]
Doesn't look like AJAX to me, as when the response starts to load it's quite quick. There is, however, a good 30 second lag before anything happens in Firebug, which suggests network or server-side problems.

CF Debugging being switched on on the server could kill it like this.
# Posted By Neil Middleton | 4/7/08 11:10 AM
I suspect that the config mode for Mach-II in your Application.cfc is set to 1 (always reload) since it's taking forever on each and every request. Set it to 0 (reload if config file changes) or -1 (never reload) for better performance.

FAQ here:
http://greatbiztoolsllc-trac.cvsdude.com/mach-ii/w...
# Posted By Peter J. Farrell | 4/7/08 11:13 AM
Oh, CF debugging could be turned on with "report execution times" on the server and we might not see it because we don't have the right IP. This is really bad for performance. Is debugging on?
# Posted By Peter J. Farrell | 4/7/08 11:15 AM
I would guess its a framework setting as mentioned above. I would rule out networking problems because if you go to the base url... the current version of the site loads pretty snappy for me. My trace to fastservers had barely any latency as well.

I'd stick with the auto reload mach-ii as mentioned above as your first stopping pt.
# Posted By DanaK | 4/7/08 11:19 AM
It does seem more like it is your server, same as the other comments check Mach-II's reload setting.

You should also enable gzip on your webserver just to give a little extra performance.
looks like you are running on windows. here is a link for how to enable that with IIS
http://www.microsoft.com/technet/prodtechnol/Windo...
# Posted By Mike E. | 4/7/08 11:40 AM
Yes, most likely you are calling onApplicationStart on every request (assumming your app start up code is heavy), I sometimes leave that on by mistake when developing.

Ajax is pretty lightweight, I have been using it without any problems for a while. Except for some real weird loadData issue that Im trying to figure out (another story :))
# Posted By Raul Riera | 4/7/08 11:44 AM
Ray, this isn't critical, but more of a comment: this current post rates an F from my install of YSlow/Firefox. I've often thought that YSlow was built to be pretty aggressive. I guess my point is that the individual tests within YSlow may be more helpful than the grade.
# Posted By Tom Mollerus | 4/7/08 11:46 AM
@Tom - good point.
# Posted By Raymond Camden | 4/7/08 11:52 AM
One more thing - Ray mentioned the 'minified' versions of the Spry files, but the 'packed' versions are even smaller.
# Posted By todd sharp | 4/7/08 12:08 PM
Could this be an issue with CF8 and Java 1.6? Isn't that still a problem? Can the hosting company check which JVM they're using?
# Posted By Adrian J. Moreno | 4/7/08 12:38 PM
@Todd: Thanks. I always get those confused.

@Adrian: It could be.
# Posted By Raymond Camden | 4/7/08 1:05 PM
1.) If this is on CF 8, can the hosting company look at the Server Monitor and give you details on what the problem might be? (or are they that savvy?)

2.) If it's CF 6.1 - 7, can they put SeeFusion monitoring on it to see what's going on?

3.) Do you have access to the DB such that you can put traces/profiling on it to see if the DB or SQL statements need tuning? (the usual suspects are poorly-written queries, poorly implemented table indexes, and queries that pull in much more data than they really need - too many columns or too many rows, or both)

If you can't figure out any way to get access to the info for 1-3 above, then I'm afraid you're probably just taking shots in the dark at what the problem *might* be.
# Posted By Aaron Longnion | 4/7/08 1:15 PM
This is a useful online tool for getting a performance report on a site:

http://www.websiteoptimization.com/services/analyz...
# Posted By Johan | 4/7/08 3:13 PM
Quite correct on the config mode. It was on "1" (oops). That takes care of subsequent loads. I'm working through the other issues. Thanks for the feedback. This should help others too.
# Posted By Paul Baylis | 4/7/08 4:16 PM
I used the tool suggested by Johan. Very useful. Thanks for the link. I scored warnings on:

-------------------------------------------------
TOTAL_OBJECTS - The total number of objects on this page is 16 - consider reducing this to a more reasonable number. Combine, refine, and optimize your external objects. Replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests.

TOTAL_SIZE - The total size of this page is 208140 bytes, which will load in 44.68 seconds on a 56Kbps modem. Consider reducing total page size to less than 30K to achieve sub eight second response times on 56K connections. Pages over 100K exceed most attention thresholds at 56Kbps, even with feedback.

IMAGES_SIZE - The total size of your images is 114183 bytes, which is over 30K. Consider optimizing your images for size, combining them, and replacing graphic rollovers with CSS.

SCRIPT_SIZE - The total size of external your scripts is 79245 bytes, which is over 8K. Consider optimizing your scripts for size, combining them, and using compression where appropriate for any scripts placed in the HEAD of your documents.
-------------------------------------------------

I'm not worried about the image sizes. But, I'll need to attend to the others.

For a pretty simple page, I'm not sure how I end up with 16 objects on there.

I'm now on the packed versions of the spry js files. They are apparently still quite large, but at least better than before.

The site is faster at least once the framework is loaded and I'll keep tweaking it.

Should I get off XML and onto JSON?
# Posted By Paul Baylis | 4/7/08 5:27 PM
I just dropped my hosting from ViUX due to a pretty irritating slant against ColdFusion. Even though it's offered, they're not very helpful when you start encountering problems. And expect them to pretty quickly take the "blame the developer" stance when they can't figure out why performance is so poor.
# Posted By Joshua Curtiss | 4/7/08 8:20 PM
[Add Comment]