Options
speed
Swingman
Registered Users Posts: 35 Big grins
the slides on my site take a very long time to load. Is this my computer that is having a problem or is there something I can do when I create them to speed this up?
0
Swingman
Registered Users Posts: 35 Big grins
Comments
Portfolio • Workshops • Facebook • Twitter
traceroute to 24.107.206.239 (24.107.206.239), 30 hops max, 40 byte packets
1 10.27.0.1 (10.27.0.1) 0.590 ms 0.819 ms 0.693 ms
2 r2-po3.sv1.smugmug.net (10.1.1.29) 12.628 ms 12.630 ms 12.625 ms
3 nat2.sv1.smugmug.net (10.9.0.32) 1.139 ms 1.160 ms 0.982 ms
4 r2.smugmug.net (208.79.45.2) 13.095 ms 13.052 ms 13.092 ms
5 ge-6-9.car3.SanJose1.Level3.net (4.71.112.9) 1.884 ms 1.685 ms 1.799 ms
6 vlan89.csw3.SanJose1.Level3.net (4.68.18.190) 12.931 ms 8.706 ms 8.633 ms
7 ae-82-82.ebr2.SanJose1.Level3.net (4.69.134.217) 2.267 ms 2.263 ms 2.253 ms
8 ae-3.ebr1.Denver1.Level3.net (4.69.132.58) 40.063 ms 39.882 ms 40.053 ms
9 ae-1-100.ebr2.Denver1.Level3.net (4.69.132.38) 40.657 ms 38.422 ms 38.405 ms
10 ae-3.ebr1.Chicago2.Level3.net (4.69.132.62) 52.236 ms 51.794 ms 51.996 ms
11 ae-6.ebr1.Chicago1.Level3.net (4.69.140.189) 53.884 ms 53.884 ms 53.874 ms
12 ae-1-55.edge6.Chicago1.Level3.net (4.68.101.146) 51.897 ms ae-1-51.edge6.Chicago1.Level3.net (4.68.101.18) 51.764 ms ae-1-55.edge6.Chicago1.Level3.net (4.68.101.146) 52.264 ms
13 p0-0.charter3.bbnplanet.net (4.79.74.2) 60.611 ms 60.433 ms 60.483 ms
My Website index | My Blog
Dgrin is taking longer than normal, the SmugMug Popular Photos Thumbs are taking forever, my own site (link in sig, thumbs on main page or Galleries page) is slower than normal.
I just took a browse around to other sites and they don't seem to be performing abnormally like SM is, so I don't think it is my connection.
http://www.rpsommers.com/
Canon 5D Mk II
Portfolio • Workshops • Facebook • Twitter
Sorry, I thoght my site was connected to the post.
These are the pictures that are taking long to load.
http://swingman.smugmug.com/Alumni-Gallery-New-Pictures/New-Alumni-Slides/9351776_jxQQV#625749079_2fcsy
Portfolio • Workshops • Facebook • Twitter
My Website index | My Blog
As for the albums the image preview is very slow in appearing.
I have mirrored galleries at my still active Zenfolio site. The thumbnails and previews are virtually instant.
I have a very fast connection (download 19.7mbps and upload 1.5mbps)
Not to sure where to go from here since I have done everything I can from my end to run a clean Smugmug site.
Peter
The upload speed is fine (90/100 kbps, which around my max upload speed), but there is a pause (that wasn't there before) of 1-2 minutes between each picture uploaded (the iPhoto uploaded is in "Awaiting Response" mode).
So it's a bit annoying when you have 150 pictures to upload.
I am normaly uploading my pictures around that time, so I don't know if it's because of an unusual server load at night.
I also noticed a small slowdown on the access time of the website. Download speed looks nice, but establishing the session looks slower than usual.
(my website is http://pix.froggystyle.ca/)
Thanks!
Galleries showing thumbs but not photos. Photos sometimes only appearing as half a photo, until another page refresh.
This is not normal for my access in New Jersey. Attaching Trace Route and Ping results. Let me know if you would want me to do anything else.
Thanks
traceroute to smugmug.com (208.79.45.23), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 1.406 ms 1.051 ms 1.037 ms
2 * * *
3 68.85.76.229 (68.85.76.229) 8.826 ms 9.631 ms 9.426 ms
4 po-90-ur01.bayville.nj.panjde.comcast.net (68.86.210.57) 10.090 ms 10.114 ms 9.520 ms
5 po-90-ur02.manahawkin.nj.panjde.comcast.net (68.86.210.53) 10.234 ms 10.565 ms 9.763 ms
6 po-90-ur01.manahawkin.nj.panjde.comcast.net (68.86.158.169) 9.961 ms 10.329 ms 9.491 ms
7 po-60-ar01.absecon.nj.panjde.comcast.net (68.86.210.49) 10.870 ms 11.499 ms 9.560 ms
8 te-0-2-0-0-ar01.audubon.nj.panjde.comcast.net (68.85.159.26) 14.221 ms 11.531 ms 11.781 ms
9 pos-0-12-0-0-ar01.plainfield.nj.panjde.comcast.net (68.85.192.86) 14.543 ms 14.524 ms 16.363 ms
10 pos-0-8-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.91.217) 15.566 ms 17.839 ms 16.251 ms
11 xe-10-2-0.edge1.NewYork2.Level3.net (4.78.169.49) 44.075 ms 15.974 ms 16.791 ms
12 vlan52.ebr2.NewYork2.Level3.net (4.69.138.254) 16.763 ms 15.930 ms 16.843 ms
13 ae-6-6.ebr4.NewYork1.Level3.net (4.69.141.21) 25.997 ms 44.251 ms 18.048 ms
14 ae-2.ebr4.SanJose1.Level3.net (4.69.135.185) 101.877 ms 99.078 ms 90.021 ms
15 ae-94-94.csw4.SanJose1.Level3.net (4.69.134.254) 92.651 ms 98.096 ms 90.254 ms
16 ae-43-99.car3.SanJose1.Level3.net (4.68.18.197) 91.156 ms 90.094 ms 92.673 ms
17 SMUGMUG-INC.car3.SanJose1.Level3.net (4.71.112.10) 92.758 ms 91.319 ms 91.251 ms
18 www.smugmug.com (208.79.45.23) 91.500 ms 91.453 ms 91.290 ms
PING smugmug.com (208.79.45.23): 56 data bytes
64 bytes from 208.79.45.23: icmp_seq=0 ttl=238 time=89.929 ms
64 bytes from 208.79.45.23: icmp_seq=1 ttl=238 time=90.692 ms
64 bytes from 208.79.45.23: icmp_seq=2 ttl=238 time=91.119 ms
64 bytes from 208.79.45.23: icmp_seq=3 ttl=238 time=90.090 ms
64 bytes from 208.79.45.23: icmp_seq=4 ttl=238 time=90.572 ms
64 bytes from 208.79.45.23: icmp_seq=5 ttl=238 time=91.377 ms
64 bytes from 208.79.45.23: icmp_seq=6 ttl=238 time=89.365 ms
64 bytes from 208.79.45.23: icmp_seq=7 ttl=238 time=90.208 ms
64 bytes from 208.79.45.23: icmp_seq=8 ttl=238 time=90.739 ms
64 bytes from 208.79.45.23: icmp_seq=9 ttl=238 time=89.462 ms
--- smugmug.com ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 89.365/90.355/91.377/0.631 ms
"Never leave home without a camera"
I too have noticed sub-optimal speeds.. and I'm in San Jose with a Comcast Business connection ( 48mbps down, 8.5mbps up). I would say the site is "okay" but not speedy... and my wife keeps walking in asking if I'm maintaining our network because her iphoto picture upload (to smugmug) using the plug-in keeps stopping.
It appears the first load of an image is very slow, and subsequent loads are fast... this is indicative of a slow cache-fill, and or cache-fill problem (between akamai and smugmug).
$ wget http://pics.stonekitty.net/photos/605847751_VtNbi-O.jpg
--2009-08-24 21:07:50-- http://pics.stonekitty.net/photos/605847751_VtNbi-O.jpg
Resolving pics.stonekitty.net... 96.6.244.77
Connecting to pics.stonekitty.net|96.6.244.77|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8269616 (7.9M) [image/jpeg]
Saving to: `605847751_VtNbi-O.jpg'
100%[===========================================================================================================================>] 8,269,616 167K/s in 49s
2009-08-24 21:08:39 (165 KB/s) - `605847751_VtNbi-O.jpg' saved [8269616/8269616]
$ wget http://pics.stonekitty.net/photos/605847751_VtNbi-O.jpg
--2009-08-24 21:09:51-- http://pics.stonekitty.net/photos/605847751_VtNbi-O.jpg
Resolving pics.stonekitty.net... 96.6.244.77
Connecting to pics.stonekitty.net|96.6.244.77|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8269616 (7.9M) [image/jpeg]
Saving to: `605847751_VtNbi-O.jpg.2'
100%[===========================================================================================================================>] 8,269,616 2.51M/s in 3.1s
2009-08-24 21:09:54 (2.51 MB/s) - `605847751_VtNbi-O.jpg.2' saved [8269616/8269616]
the IP's there are Akamai... the speeds are in Bytes, so converted to mbps its 1.3mbps on the first go, and then 20mbps on the second load. Neither speed is "bad"... but I thought you might want to hear about the difference.
*during* my testing.. the ping times are solid... so I'd say this is an application slowdown in akamai, or in smugmug (fetching from origin)... or a network problem between the two. If there is a URL that I can fetch from that is not akamaized... I can test that for you.
--- 96.6.244.77 ping statistics ---
121 packets transmitted, 121 packets received, 0% packet loss
round-trip min/avg/max/stddev = 12.920/15.257/27.960/2.228 ms
EDIT: <disclaimer> - I'm only seeing the perspective of the Akamai cache that I'm pointed at... I haven't tried to force an affinity to any of the other couple-thousand akamai cache nodes all around the world... maybe I'll try to provide another couple views by using hosts in other time-zones... and/or try to find some test-files that come off Smugmug in San Jose to see if there's anything obvious. My test here may or may not be representative of the greater population of mugs.
Cheers,
N
I found that some of the galleries are not akamized (the IP below is smugmug)... and its wicked fast:
$ wget http://www.smugmug.com/community/4-Your-Top-50-Photos/popular/today/1/509064869_ZMJjr#509063637_9epFQ-O-LB
--2009-08-24 22:58:50-- http://www.smugmug.com/community/4-Your-Top-50-Photos/popular/today/1/509064869_ZMJjr
Resolving www.smugmug.com... 208.79.45.23
<snip>
2009-08-24 22:58:50 (5.39 MB/s) - `509064869_ZMJjr.1' saved [29349/29349]
...Thats 43.12mbps.
Then I tried it from work (came in at 97mbps):
~> wget http://www.smugmug.com/community/4-Your-Top-50-Photos/popular/today/1/509064869_ZMJjr#509063637_9epFQ-O-LB
--23:02:02-- http://www.smugmug.com/community/4-Your-Top-50-Photos/popular/today/1/509064869_ZMJjr
=> `509064869_ZMJjr'
Resolving www.smugmug.com... 208.79.45.23
<snip>
23:02:03 (12.15 MB/s) - `509064869_ZMJjr' saved [29349/29349]
So falling back to my own gallery... (from work this time)
host:~> wget http://pics.stonekitty.net/photos/605853751_CU7cE-O.jpg
first load:
23:06:02 (296.41 KB/s) - `605853751_CU7cE-O.jpg' saved [9354873/9354873] (2.3mbps)
second load:
23:06:17 (40.52 MB/s) - `605853751_CU7cE-O.jpg.1' saved [9354873/9354873] (324mbps)
Since my galleries are viewed by a relatively small number of people (maybe 20 people over the course of 3 days after I post updates)... I doubt Akamai really buys me anything (especially when the cache-fill is that bad), my photos are probably evicted from their cache shortly after they get the first and only hit because there are just so many other popular things that would wedge me out...... I'd argue that its worse for low-traffic users like me. I would say its good to cache photos if the gallery viewers are very-far-away, or the volume is high (to get any sort of decent cache hit rate), and/or only cache site components that everyone would fetch anyway (javascript and objects that makeup smugmug's site, that everyone will be loading anyway).
Note to self... look for an option to de-akamize my domain in the smugmug settings, when I wake up in the morning.
There's some serious apples to oranges comparison here... a few notes:
Yes galleries that are marked as hide owner are served out with www.smugmug.com (not akamaized) as the domain in the url for the html, however that is ONLY the html. The images are served out via photos.smugmug.com (akamaized) while the other content like CSS and JS are served out from cdn.smugmug.com (also akamaized). Your first speed test was pulling a small HTML file, less than 30k. At that size all sorts of small hickups on the network could have wildy impacted your results... and we probably spent more time generating the html then sending it to you. Your next test used an image weighing in a bit over 9M... a much better size to do a test with. Interestingly you choose to test it against a custom hostname url... while those are akamaized (if setup correctly, like yours) they use a different set of Akamai servers running a different Akamai product offering.
To factor out the Akamai vs SmugMug servers question when looking at a single first page hit like that, you need to take into account the time it took us to generate the content. If you capture the headers with wget, look for the X-extra header to get an idea of how long it took us to generate the response. But see below before you spend any time on that, for why that's kinda a useless thing to look into.
Sorry to say nullrouten, you're not going to find one.
Your analysis misses one of the key aspects of Akamai though... it's not just a simple dumb passthrough cache, it's a content delivery network, but even that moniker is an understatement... application acceleration is much more accurate. You're looking purely at a single file, to truly appreciate the performance boost Akamai gives every viewer, you need to look at the entire browsing experience. One example of the things that Akamai brings to the table: when you load a page, they look at all of the content on the page as they are streaming it back to you, then they go out to pre-fetch the contents while you're still fetching the html. So before your browser has even seen the html of the page, Akamai has seen all of the css, js and image files that page calls for, and has started up the process of fetching them. Given that the vast majority of viewers are hindered by the last mile problem in their network connection, this transfers the content to the Akamai cluster far faster, and enables a much quicker delivery of it to the browser by avoiding the long ping pong exercise that most web browsing is.
Using my home cable modem connection as an example, Akamai's servers are roughly 20 ms away, SmugMug's servers are roughly 85 ms away. A given thumbnail takes about 45 ms to transfer. So for every thumbnail on the page I could get it in either 65ms through akamai or 130ms from SmugMug's servers. That of course assumes that the file was there and immediately ready to transfer... in reality they aren't, so when you go fetch it from smugmug you have to wait for the image to be pulled from storage, say that takes 5 seconds.... now you're talking 65ms vs 5 seconds. Now say you're looking at a page with 36 thumbnails on it... given 3 image fetching threads in the browser you're looking at something like 780 ms to fetch them from Akamai, vs 60 seconds to fetch them from SmugMug's servers. Now admittedly, there is some upfront delay for Akamai to get them all transfered, but they're fetching them across much faster pipes than most viewers are, and they're fetching more in parallel. So you'll often see a short pause at the beginning when you first load the page, but then they rapidly fill in the images as your browser grabs them from Akamai's servers much faster than they could from SmugMug's.
We do several things in working with Akamai to speed up that initial lag as well, so it isn't as noticable in the real world as in the simplified example above. But that's getting into the secret sauce territory, so I'd rather not go into details there.
Needless to say, I wouldn't hold my breath on us adding a "please don't Akamaize me" switch any time soon... 'cause it's likely only to get even better as we do more work on it.
http://wall-art.smugmug.com/
Yes I know how Akamai works(mostly, I wont profess to be all-knowing)... and Okay, you did find an error in my paste... I obviously pasted a 30k html and put it up against a 9 meg picture... my mistake. I did 50 different tests before pasting anything and clearly I miss pasted.
wget http://pics.stonekitty.net/photos/489828468_oSMRM-O.jpg
Resolving pics.stonekitty.net... 208.79.45.23
Connecting to pics.stonekitty.net|208.79.45.23|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,383,790 (2.3M) [image/jpeg]
16:17:16 (336.14 KB/s) - `489828468_oSMRM-O.jpg.1' saved [2383790/2383790]
note the IP... its smugmug... note the size, its 2.3M... no redirection to any other hostname.
Now here's with my /etc/hosts entry removed:
dns resolution:host pics.stonekitty.net
pics.stonekitty.net is an alias for domains.smugmug.COM.
domains.smugmug.COM is an alias for domains.smugmug.com.edgekey.net.
domains.smugmug.com.edgekey.net is an alias for e1021.c.akamaiedge.net.
e1021.c.akamaiedge.net has address 69.192.36.77
wget first time:
> wget http://pics.stonekitty.net/photos/489828468_oSMRM-O.jpg
Resolving pics.stonekitty.net... 69.192.36.77
Connecting to pics.stonekitty.net|69.192.36.77|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,383,790 (2.3M) [image/jpeg]
16:20:59 (640.55 KB/s) - `489828468_oSMRM-O.jpg.5' saved [2383790/2383790]
Second load:
> wget http://pics.stonekitty.net/photos/489828468_oSMRM-O.jpg
Resolving pics.stonekitty.net... 69.192.36.77
Connecting to pics.stonekitty.net|69.192.36.77|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,383,790 (2.3M) [image/jpeg]
16:21:08 (16.06 MB/s) - `489828468_oSMRM-O.jpg.6' saved [2383790/2383790]
Note the 25x factor speedup.... note the ip's (whois + reverse dns shows akamai)... note the size and url... same image same size.
SO, *today* there's much less of a difference to talk about... akamai is fast after the first load... but I'll still stand behind my statement that the first load is slow-er (some-times its pretty dang slow)... and for me... 98% of my image views are a first loads. Last night I was getting 1-2mbps loading 12megabyte originals, and gallery pages taking 30 seconds to load all the thumbs... today I can't reproduce the problem to that level of badness.
I agree... Akamai is a complicated application... and I've only approached one dimension to a multifaceted process here. I was merely trying to figure out why I thought things were slow lately... and then I came to dgrin for the first time in months and found a couple threads talking about slowness. My first instinct is to dig with command line tools, as it presents data as opposed to "feel". I never said I found "the" problem... just that I have data for you... I know how complex things can be and I know I cannot see *every* aspect from my armchair in san jose, or my desk at work.
I think maybe its the initial-lag thats currently my issue (and I'll try to reproduce my tests with a different tool, and using a different method (hitting an old gallery (not cached) from firefox (using firebug), and then clearing cache and repeating test from same computer... note any difference or perceived slowness in first vs second). Again... things work... they just suck on the first hit. If akamai is set not to expire your content, you could try to pre-warm the cache by pre-fetching everyones images from every akamai cache, but that arguably invalidates the benefit of caching what's used and not wasting gobs of disk space for content thats not going to be hit. I also see some value in pre-warming the "next image" and "next page" worth of thumbs... that should be fairly easy to implement with some slide-show magic (load images ahead of current position if possible), or for gallery pages have the next page loaded by akamai before the user hits "next page" link...
You guys have done a great job, I love the service. Any time I pose a question or problem to the superhero's, they nail it. So, in conclusion... I'm just trying to provide more data than "my craps slow, here's a ping".
P.S. I like the pretty lights in your cage. My pretty lights shine towards your pretty lights.
What to do when you cant sleep? WELL, profile smugmug performance of course!!!
It is after 3am here... so its likely that the load on all west-coast infrastructure is pretty low... and as expected things are pretty darn fast right now, but I managed to get some firebug screenshots showing differences between first-load and repeat loads... I cleared my firefox cache after every gallery load.
A few images delay the first load to a total of 3-6 seconds, but repeat loads are nice and fast (sub 2 seconds).
http://pics.stonekitty.net/Computers/Smugmug-performance/9412546_xCPs2#630771173_jaFv3
I attempted to try and test if akamai is successfully pre-fetching pages as soon as a client requests the page... Method: tell FireFox not to load images (Preferences, Content, Uncheck - Load Images). Then I visited a new page in a weblog-style gallery. Waited 30 seconds. Re-checked the Load Images box. Went back to a gallery page I was on... went back to the test-page (that, in theory, I've loaded the UI, just no images)..
Verdict: on a weblog style gallery, all loads took 6 seconds and I cant discern a difference between a first load, repeat load, and a page first images later load... so things must be working fine right now.
so, no issues really... I'll poke again mid-day if I have a moment.
gnite.
Thanks
Yea sorry.. I did sorta hijack the thread with my own agenda.
Our network engineers identified a bottle neck that was slowing down some aspects of the site for some users. They've fixed that... should be back to normal now.
http://wall-art.smugmug.com/