MASSIVE download delay from e-junkie with VIDEO

[jeffschmidt]

To avoid any confusion - I've created a video showing exactly what the problem is.



http://www.blip.tv/file/2485575



I host my own files because they are large. this one is almost 400mb.



I compare downloading one of my products through e-junkie url cloaking vs directly off my own server.



it's done on the same machine - the same connection - at the same time.



the results are frightening. e-junkie url cloaking introduces massive, unacceptable download delay.



e-junkie - please explain a fix. please?



thanks!



--jeff

[jeffschmidt]

after a few more tests I have yet to get ANY of my products via e-junkie download to exceed 95kbs - even (as the video shows) when my connection clearly allows over 4 MBPS download.



e-junkie - you there? whats up with this?



help please.



thanks!



--jeff

[E-junkie_Guru]

Please see my other reply here:

http://www.e-junkie.com/bb/topic/3193#post11098



Bear in mind that connection speeds are rated in bps (bits per second) while browsers report download progress in Bps (Bytes per second), a difference by a factor of 8 (bits per Byte). Thus 95kBps = 760kbps, which incidentally seems pretty close to the 768kbps speed rating/cap I've seen listed for some broadband services.



I used to have cable Internet service that was marketed as "up to 4Mbps" but in actual real-world practice, I was usually lucky to get anything over 1Mbps -- in their fine print, what the service is technically capable of sustaining under ideal conditions is often not even close to what you actually get, especially in some cable deployments where you're effectively on a LAN with your neighbors, all sharing a common high-bandwidth circuit.

[jeffschmidt]

I appreciate your reply but it doesn't answer my question.



did you watch the video?



can you address the difference in download speeds between e-junkie & direct as shown in the video?



why is there such a SIGNIFICANT difference?



Regarding your other post about e-junkie caching copies after initial download - that sounds wrong on 2 points.



1.) You charge for hosting (a lot actually on a per GB basis) so why would you "cache" (store) remotely hosted files on your S3 servers for free?



2.) I download files through e-junkie a few times - and the download speed did NOT improve with successive downloads.



So, if the files are cached as you suggest - it's not improving the customer experience.



still looking for help on this please.



thanks!



--jeff

[jeffschmidt]

Addressing the points you raised:



1) We are obliged to retain our copy of files uploaded for storage on our server indefinitely as long as the merchant keeps their subscription active.



For remotely-hosted files, we can delete any file copies from our cache at any time (most likely for small or rarely-downloaded files) as needed to optimize our storage use, as we expect to be able to restream the original file from its remote URL at any time, and caching a copy to serve up for future downloads also minimizes both your and our transfer bandwidth usage and costs while generally maximizing performance for the downloader via S3's high-performance service, which brings up your next point:



2) I tested the same Free Download links you'd generated for your own tests, and found I was getting nearly 200kBps from Amazon S3, saturating the 1.5Mbps pipe we've got to the office here. Did you wait at least 15 minutes after completing the first download attempt for the same product before testing again?



When you click your download link, an Open/Save dialog should appear (at least in Firefox) showing you where the file is coming from. If the file's already been synched up to S3 by then, that dialog should show the file's origin as s3.amazonaws.com; if the sync hasn't completed yet, then it would be showing as [somehost].e-junkie.com, in which case throttling would be involved to prevent saturating all of our available datacenter bandwidth and maintain high availability of our service for all users.



I'll ask our Lead Developer to check if there might be anything unusual going on at our end (or Amazon's end) at the moment causing download congestion from S3 in particular. You might also ask your ISP if they know of any congestion or other transient routing issues between them and Amazon S3 today. As I reckon you're aware, no Internet connection is a direct, point-to-point route; the routing between your ISP and your hosting may be far simpler and less congested than the route between your ISP and Amazon S3. You might try running a traceroute both to your host and to s3.amazonaws.com, to see if you can identify a clear delay along the S3 route somewhere upstream from you.

[E-junkie_Guru]

Addressing the points you raised:



1) We are obliged to retain our copy of files uploaded for storage on our server indefinitely as long as the merchant keeps their subscription active.



For remotely-hosted files, we can delete any file copies from our cache at any time (most likely for small or rarely-downloaded files) as needed to optimize our storage use, as we expect to be able to restream the original file from its remote URL at any time, and caching a copy to serve up for future downloads also minimizes both your and our transfer bandwidth usage and costs while generally maximizing performance for the downloader via S3's high-performance service, which brings up your next point:



2) I tested the same Free Download links you'd generated for your own tests, and found I was getting nearly 200kBps from Amazon S3, saturating the 1.5Mbps pipe we've got to the office here. Did you wait at least 15 minutes after completing the first download attempt for the same product before testing again?



When you click your download link, an Open/Save dialog should appear (at least in Firefox) showing you where the file is coming from. If the file's already been synched up to S3 by then, that dialog should show the file's origin as s3.amazonaws.com; if the sync hasn't completed yet, then it would be showing as [somehost].e-junkie.com, in which case throttling would be involved to prevent saturating all of our available datacenter bandwidth and maintain high availability of our service for all users.



I'll ask our Lead Developer to check if there might be anything unusual going on at our end (or Amazon's end) at the moment causing download congestion from S3 in particular. You might also ask your ISP if they know of any congestion or other transient routing issues between them and Amazon S3 today. As I reckon you're aware, no Internet connection is a direct, point-to-point route; the routing between your ISP and your hosting may be far simpler and less congested than the route between your ISP and Amazon S3. You might try running a traceroute both to your host and to s3.amazonaws.com, to see if you can identify a clear delay along the S3 route somewhere upstream from you.

[tonehammer]

We can confirm the downloads routed through e-junkie are super slow today. We have our files hosted on S3 and the direct link is blazingly fast. But we get about 1/10 of the speed routing it through e-junkie, so something is happening on your side guys (which is very rare - might I add)...

[E-junkie_Guru]

Earlier today, our Lead Developer found and fixed a glitch that was causing slow downloads since the past day or so. Let us know if you're continuing to experience any problems with download performance.