Add the following lines to DummyClass in inline_attachment.rb

def parameters
    { :format => :html }
end 

def accepts
    []
end

def protocol

end

I was mainly interested in download speed in the Greater China region and North America.

To test relative speeds, I downloaded the same 20 megabyte file at several different locations from each of Cachefly, Amazon S3 and Amazon Cloudfront and noted the range of speeds.

New York City - Time Warner Cable (Queens)

• Cachefly: 1100 - 1200 kilobytes/s
• S3: 1000 - 1100 kilobytes/s
• Cloudfront: 1100-1200 kilobytes/s

Cleveland, Ohio - Time Warner Cable

• Cachefly: 88 - 172 kilobytes/s
• S3: 65 - 80 kilobytes/s
• Cloudfront: 74 - 92 kilobytes/s

Taipei

• Cachefly: 230-240 kilobytes/s
• S3: 140 - 150 kilobytes/s
• Cloudfront: 170 - 180 kilobytes/s

Guangzhou, China - China Netcom 4 mbit dedicated fiber

• Cachefly: 430 - 495 kilobytes/s
• S3: 220 - 240 kilobytes/s
• Cloudfront: 440 - 490 kilobytes/s

Fremont, California - Hurricane Electric

• Cachefly: 3580 - 3990 kilobytes/s
• S3: 270 - 850 kilobytes/s
• Cloudfront: 5940 - 6350 kilobytes/s

Conclusion
When Cloudfront is fast, it is really fast! It wins out for top speed and for flexibility given how like all Amazon Web Services offerings is controlled by an API.

Cachefly is still in our experience the fastest overall in the regions that are important to us. They also do not suffer from some of the restrictions Cloudfront places on updating files. With Cloudfront, updates can take up to 24 hours to reach edge servers. Cachefly does not have this problem. Updates made by ftp or sftp appear momentarily across their network.


eth1 = public ip
eth0 = lan ip


echo "1" > /proc/sys/net/ipv4/ip_forward
/sbin/iptables --flush
/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE --random
/sbin/iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT