Please see my other reply here:

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



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.

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.

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)...

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.