many people reported that problem as well for our App (that uses the tmdb api) but we never managed to pin point the issue. could be amazon, i am not sure

Hey r4mark,

Do most of these users share a similar geographic region? I ask because we server our assets from a CDN so they be getting delivered by servers from all different parts of the world.

Also worth asking is whether you are using our configuration method properly and piked up the new image URL (image.tmdb.org)? If you're still using the older CloudFront address (the one that preceded this) we're now redirecting those requests which may or may not be the issue.

Lastly, have you seen this behaviour yourself? Is there any particular asset that's slow all the time, or is it just on original load?

To answer your question though, no, we haven't had any server issues that we're aware of.

I'm using the new image url and it seems like all the images are loading slow not any particular asset, I'm getting 3-4 seconds latency for most of the images in debugging tools even ~20kb sized ones.

Do most of these users share a similar geographic region? I ask because we server our assets from a CDN so they be getting delivered by servers from all different parts of the world.

?

I'll use this file as an example: http://image.tmdb.org/t/p/w130/1NfhdnQAEqcBRCulEhOFSkRrrLv.jpg

It's loading basically instantaneous for me. Doing a trace route to image.tmdb.org show the POP I'm hitting is I believe to be in San Jose.

Zipper /~ > traceroute image.tmdb.org
traceroute: Warning: image.tmdb.org has multiple addresses; using 162.159.251.184
traceroute to cf-ssl50771-protected-image.tmdb.org (162.159.251.184), 64 hops max, 52 byte packets
 1  10.0.1.1 (10.0.1.1)  3.165 ms  1.033 ms  0.968 ms
 2  * * *
 3  rc2so-tge0-1-1-0-1.cg.shawcable.net (64.59.132.6)  30.872 ms  15.608 ms  24.636 ms
 4  rc1no-atm1-0-11.br.shawcable.net (66.163.77.82)  45.765 ms
    rc2wh-tge0-13-0-12.vc.shawcable.net (66.163.74.185)  32.692 ms
    rc1no-atm1-0-11.br.shawcable.net (66.163.77.82)  33.996 ms
 5  paix.99.xe-0-1-0.cr1.pao1.us.nlayer.net (198.32.176.13)  87.312 ms  113.669 ms  90.997 ms
 6  ae1-70g.cr1.sjc1.us.nlayer.net (69.22.143.165)  74.549 ms  61.888 ms  87.090 ms
 7  as13335.xe-8-0-0.cr1.sjc1.us.nlayer.net (69.22.153.198)  170.019 ms
    as13335.xe-8-1-0.cr1.sjc1.us.nlayer.net (69.22.153.214)  162.868 ms
    as13335.xe-8-0-0.cr1.sjc1.us.nlayer.net (69.22.153.198)  183.770 ms
 8  162.159.251.184 (162.159.251.184)  87.930 ms  61.845 ms  69.249 ms

What does that look like for you (specifically the datacenter it looks to be hitting (mine is hop 6 or 7, the xxx.sjc1.us.nlayer.net)?

That image is loading instantly for me as well about 9 out of 10 times, as for the trace it just times out at 6-7 hop, I've set timeout to 30000ms

Tracing route to cf-ssl50771-protected-image.tmdb.org [162.159.251.184]
over a maximum of 10 hops:

  1    <1 ms    <1 ms     1 ms  Dlink-Router.Dlink [192.168.0.1]
  2   402 ms    11 ms     1 ms  10.210.1.1
  3     1 ms     1 ms     1 ms  cr [10.0.0.1]
  4     3 ms     4 ms     3 ms  78.158.0.53
  5     5 ms     4 ms     5 ms  80.232.170.9
  6    11 ms    11 ms    13 ms  195.122.0.149
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.

If it's failing that early it's probably your ISP/another provider in the middle not letting trace routes through.

Where are you located? As I've said, this is very relevant since it looks like it's either a particular POP that is having trouble or, a combination of the POP + link between ISP's. I'm in Calgary and connect down in the U.S. and don't see any issues at all.

I'm from Lithuania, I find this very difficult to debug as sometimes it loads normally sometimes it doesn't.