Fast Tracert, but Ultra-Slow Performance?

Jason Dunn

I'm a bit baffled here - I'm seeing mega-slow performance from Smugmug when doing a slideshow, yet a tracert from my location to hera.smugmug.com shows things mega-fast: under 60 ms all 11 hops to the server.

So how else can I confirm that the slowness I'm seeing is coming from Smugmug if a tracert shows things are fast? I was actually embarassed showing photos to someone else :uhoh - it was taking 6+ seconds to load one image, which is brutal. I'm on a hard-wire connection to a 10 mbps cable modem, so I don't think it's local. Pulling down a file from my Web server (located in Texas) was getting me 705 KB/s...so again I don't think it's local or even a networking issue between here and there.

I would love it if there was some quantifiable way to understand Smugmug's speed status, similar to a load number on a server. It's always so mysterious when Smugmug starts getting slow... :scratch

Andy

Hi Jason,

Are you speaking about the full screen slideshow? If so, here's a quote from our CEO & Chief Geek about it... and I'll add, that we've been doing what he says, "working on improving it" and we hope that it'll be out soon

First of all, the fullscreen slideshow thing is a difficult animal. We were the first site on the net to do it, and we've already revised it a few times to make it even easier to use. But that doesnt' mean it's perfect - we'll continue to work on it.

Most people have no problems using it, while others can't seem to get a fast image to save their skins. 99% of the time, this comes down to bandwidth - sending over a full-screen sized version of your photo takes a lot more bandwidth and time than sending over a smaller version.

The bandwidth problem is exacerbated by the fact that we pride ourselves on great image quality. So we use as little JPEG compression as we possibly can - which results in a larger file. So the tradeoff is better looking image versus faster speed. We chose the better looking image for a few reasons. The biggest of which is that more and more people have fast broadband, and that'll only increase in the future.

The "3 seconds" thing can be a little confusing. I wish I knew how to word it better on our site - if you can think of a way, let me know. It really means "display the photo for at least 3 seconds" and here's why:

Since people's connection speeds vary, we can't reliably be assured that the next photo will be ready in 3 seconds. If it takes 10 seconds to transfer to your PC, we'd then show you a 7 second black page. Ugh, that'd be no good.

So what we do is this:

- We request the next photo while we display the current one.
- As soon as we get the next photo to your web browser, we check the timer and say "Has it been X or more seconds yet?" (Where X = 3 in this case). If yes, we go to the next slide. If no, we wait the remaining seconds and then switch slides.

That way, even people on modems can see the image without seeing black pages, while people on super-fast connections can see the image without it whipping by so fast they can't see the details.

Big, screen-filling photos take time to transfer. I'm afraid we can't get away from that ... the one thing we could do is sacrifice a little quality to get a little more speed. I'll take a closer look at our balance between the two and see if we can fiddle with it a little bit there.

To be honest, we don't do nearly as much competitive research as people think we should - we're too busy listening to our customers and building the features they want. Most of our customers rave about our slideshow, but that's no reason to let it get stale. As a customer of ours, I take your feedback seriously and will definitely continue to work on the feature.

Bottom line, though, is that your family and friends who have fast connections should see a gorgeous full-screen image in a fairly short amount of time. Meantime, we'll work on it to make it even better.

scwalter

http://www.speedtest.net/

Try this site to check your actual bandwidth (and ping as well) The San Jose one is pretty close to Smugmug. When you are done, you can post your results here.

-Scott

Jason Dunn

scwalter wrote:

Try this site to check your actual bandwidth...

Seems plenty fast.

Jason Dunn

Andy wrote:

Are you speaking about the full screen slideshow? If so, here's a quote from our CEO & Chief Geek about it...

Yes, that's what I was speaking about tonight. I'm seeing a lot of "waiting for upload.smugmug.com". I did a tracert to that server, and it was just as fast as the previous tracert to hera.smugmug.com.

If it's not a bandwidth issue, is it a server load issue? Is hermes.smugmug.com overloaded? I was a bit surprised that the slide show function didn't come off hera, which is where my account is hosted.

Running two dedicated servers myself, I know how hard it is to nail down netwokring gremlins - quite often I'll view my galleries in the standard Smugmug style, and 13 of the 15 thumbnails will load...and the last one or two will just hang, taking 10+ seconds to appear. It's so bizarre.

darryl

Hi Jason:

I've been having the same frustrating problem of slow load times, both in slideshow, and in regular viewing (86 thumbs taking 86 seconds!?).

I've submitted countless traceroutes from my work, my home, and the homes of other parents at my son's pre-school that are experiencing severe slowness.

There has still been no definitive answer from SmugMug on what the problem is. But I wanted to let you know you're not alone. One theory I've had is that many of the people with the problem seem to be going through the llnl.net route from SmugMug.

To that end, I've asked people to post the beginnings of their traceroutes to [thread=71501]this thread[/thread].

Just go to http://www.smugmug.com/homepage/traceroute.mg to run a trace from SmugMug to you.

They also have their very own speedtest.net server set up, but like you, my times have been plenty fast (DS3 at work = 13446/12718, DSL at home = 3758/628). Try it yourself:

http://smugmug.speedtest.net/

Jason Dunn

darryl wrote:

There has still been no definitive answer from SmugMug on what the problem is. But I wanted to let you know you're not alone. One theory I've had is that many of the people with the problem seem to be going through the llnl.net route from SmugMug.

Indeed, my tracert shows ge3-1.fr3.sjc.llnw.net as one of the hops. I know that Smugmug can't control networks external to their own, and sadly my own ISP (Shaw) basically takes the same stance. I can't blame them, but it sure is frustrating that no one wants to be responsible for network problems (again, I'm not blaming Smugmug here).

Thought I'd try it again, and things are the same if not worse:

http://photos.jasondunn.com/gallery/3528586

Page one of that gallery took 71 seconds to load.

darryl

Jason Dunn wrote:

Indeed, my tracert shows ge3-1.fr3.sjc.llnw.net as one of the hops. I know that Smugmug can't control networks external to their own, and sadly my own ISP (Shaw) basically takes the same stance. I can't blame them, but it sure is frustrating that no one wants to be responsible for network problems (again, I'm not blaming Smugmug here).

Thought I'd try it again, and things are the same if not worse:

http://photos.jasondunn.com/gallery/3528586

Page one of that gallery took 71 seconds to load.

Hi Jason:

Yeah, your page(s) loaded slow for me too. :-{

So I'm trying to narrow down the scope of the problem. I wrote a script that tries to download the same image 500 times, pausing 2 seconds every time. Results have *not* been promising.

With a Medium-sized version of the photo (47K), 88% of the time it took less than a second to load. But 12% of the time it took anywhere from 2-14 seconds, with one load taking 60 seconds(!)

Trying the same test with a Tiny-sized version (4K - used for thumbnails), it's actually *worse*: 33% of the time it's taken over 1 second to load, and of those, 17% took 10 seconds or longer (!).

Actually, I believe it has now taken *longer* for the Tiny image to have been downloaded 500 times than for the Medium. 30 minutes vs 25 minutes, and the Tiny ones still aren't done. WTF!?

Maybe it has something to do with a router/gateway not being optimized for small files. Weird.