云服务 盛大云和又拍云配合起来使用的问题

huacnlee · 发布于 2012年08月21日 · 最后由 huacnlee 回复于 2012年08月23日 · 3646 次阅读
De6df3

这个是我最近才开始注意到的一个细节

由于盛大云有对网络传输的速度限制,导致在使用 UpYun 的时候上传图片会变得缓慢

进过我的在服务器上面用 FTP 上传文件到 UpYun 测试:

  • 2M 的盛大云上传最高速是 250K/s 左右
  • 4M 的是 570K/s 左右

注意上面的速度是总的上传限制,我有尝试同时在开两个 FTP 上传


这么一来有个问题了

下面来个例子:

  1. 2M 的带宽的情况下
  2. 如果用户上传一张 200K 的图片

进过裁剪,产生了 3 张(原图,中图,小图),假定 中图小图一共 100K,那么,一次上传需要的时间将是:

200K + 100K = 300K / 250K/s = 1.2s

这里还没有算上用户上传图片到 Web 服务器的时间耗费。

同时,这个 1.2s 还只是单个用户花费的时间,出现并发上传的时候还会更慢

共收到 11 条回复
650

使用插件的图片版本管理来使用upyun显然不合理啊。虽然没看代码,不过应该是提交多次请求吧。这样速度和流量都很亏,应该使用upyun自己的图片版本功能嘛。对rails插件来说,改写一下helper就可以实现多个版本的展示

162

可以使用upyun的表单API上传功能,相当于客户端直接上传到upyun的服务器,用callback来通知自己的服务器,这样不占用服务器的上行带宽。

De6df3

#2楼 @quakewang 我知道可以用表单上传,只是已经搞好的一套设计思路,不想重新搞一个

983

是不是可以放到后台传?

De6df3

@chucai 这不是是否异步的问题,带宽限制,怎么也快不起来的

D06bab

@quakewang 主要还是裁剪功能太弱,还不如一块处理好了在丢给那边。

15

@quakewang @huacnlee 其实对于网站,和移动设备,应该最适用客户端直传了,这样不仅节省服务端的运算和流量,而且一般云服务应该会对每个客户端所在的地区网络有智能速度优化,自动选择和客户端比较近/快的服务器来传,不知道又拍有没有这样做,七牛是这做的.

1267

裁剪没在服务器端做啊,那你客户端用什么处理啊

780

@huacnlee 改用 vps.42qu.com 吧

15

#8楼 @help5305fff 缩略是服务器端的,一个图片缩略几个版本,再传到云里去

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册