s*****m
发帖数: 13092 | 1 这个问题被很多人抱怨过了，我也感觉到了，速度不令人满意。有软工知道技术细节吗
？为什么速度上不去？一般来说就一个文件改变了，按道理同步也就是30秒之内比较合
理吧。我理解同步实现就是比较本地文件修改时间列表和服务器修改时间列表（或者其
他细节）？一个列表上传到服务器应该也就是几十K吧，比较不需要时间，然后一个几
十K文件下载最新版本1秒钟？
不懂。 |
s*****m
发帖数: 13092 | 2 而且skydrive桌面版应该客户端有一个类似已修改文件列表啊，都不需要上传所有文件
状况。当然我的理解是个简单情况。 |
k*h
发帖数: 3668 | 3 我也发现，dropbox同步更快些，skydrive经常显示processing changes一段时间才开
始上传。不知道是算法问题，还是服务器的问题。 |
s*****m
发帖数: 13092 | 4 我看到下面这个帖子引用了skydrive INI file的内容，有人说改了设置以后快了很多
，但是没说是哪个设置。
http://answers.microsoft.com/en-us/windowslive/forum/skydrive-w
1. They are using HTTP upload.
2. Limits are set in an ini file
%localappdata%\Microsoft\SkyDrive\settings\ClientPolicy.ini
MaxClientMBTransferredPerDay = 131072
MaxClientRequestsPerDay = 500000
NumberOfConcurrentUploads = 1
AllowUserOverrideOfConcurrentUploads = false
我猜是倒数两个设置？ |
L*****e
发帖数: 8347 | 5 我说两句自己自以为是的理解吧。 skydrive和dropbox的速度差别主要不是在上传一个
同样大小文件的差别，而是在于这个文件变动后，dropbox采用的是差别同步，而
skydrive不是。
差别同步在同步这个功能上是有明显优势的，为啥skydrive不采用差别同步呢？我个人
认为，dropbox的主要目的就是成为一个优秀云同步产品，而skydrive的野心在于要成
为一个云协作产品。
skydrive pro就是完全建立在sharepoint上的（不清楚现在skydrive背后是不是其实也
是sharepoint），对于version control，version之间的比较，merge, resolve
conflicts这些功能，差别存储就捉襟见肘了。。。
【在 s*****m 的大作中提到】
: 这个问题被很多人抱怨过了，我也感觉到了，速度不令人满意。有软工知道技术细节吗
: ？为什么速度上不去？一般来说就一个文件改变了，按道理同步也就是30秒之内比较合
: 理吧。我理解同步实现就是比较本地文件修改时间列表和服务器修改时间列表（或者其
: 他细节）？一个列表上传到服务器应该也就是几十K吧，比较不需要时间，然后一个几
: 十K文件下载最新版本1秒钟？
: 不懂。
|
s*****m
发帖数: 13092 | 6 我已经看了无数community论坛帖子了,不是这个问题，有用户作了详尽测试。不是在同
步的时候，就是刚开始上传的时候，D G 都是S的十倍左右。我回家准备调一下那个ini
参数，然后报告。那个参数居然限制用户一天最多传输130M？？？
【在 L*****e 的大作中提到】
: 我说两句自己自以为是的理解吧。 skydrive和dropbox的速度差别主要不是在上传一个
: 同样大小文件的差别，而是在于这个文件变动后，dropbox采用的是差别同步，而
: skydrive不是。
: 差别同步在同步这个功能上是有明显优势的，为啥skydrive不采用差别同步呢？我个人
: 认为，dropbox的主要目的就是成为一个优秀云同步产品，而skydrive的野心在于要成
: 为一个云协作产品。
: skydrive pro就是完全建立在sharepoint上的（不清楚现在skydrive背后是不是其实也
: 是sharepoint），对于version control，version之间的比较，merge, resolve
: conflicts这些功能，差别存储就捉襟见肘了。。。
|
s*****m
发帖数: 13092 | |
c****e
发帖数: 1453 | 8 很难想象skydrive不是block sync的，每次都重新传一个文件。我倒是猜他们后台没有
dedup。在我机器上，好像1-2M的文档都很快，不是很在意这个问题。
【在 L*****e 的大作中提到】
: 我说两句自己自以为是的理解吧。 skydrive和dropbox的速度差别主要不是在上传一个
: 同样大小文件的差别，而是在于这个文件变动后，dropbox采用的是差别同步，而
: skydrive不是。
: 差别同步在同步这个功能上是有明显优势的，为啥skydrive不采用差别同步呢？我个人
: 认为，dropbox的主要目的就是成为一个优秀云同步产品，而skydrive的野心在于要成
: 为一个云协作产品。
: skydrive pro就是完全建立在sharepoint上的（不清楚现在skydrive背后是不是其实也
: 是sharepoint），对于version control，version之间的比较，merge, resolve
: conflicts这些功能，差别存储就捉襟见肘了。。。
|
s*****m
发帖数: 13092 | 9 无数人抱怨上传几个G要好几天，有人观察说上传连接burst mode，一会全速，一会儿
停几分钟。
【在 c****e 的大作中提到】
: 很难想象skydrive不是block sync的，每次都重新传一个文件。我倒是猜他们后台没有
: dedup。在我机器上，好像1-2M的文档都很快，不是很在意这个问题。
|
g*******t
发帖数: 7704 | 10 dropbox是分块block上传， 只传变动部分， 这个需要在server端搞一个更大的hash
数据库，
很明显，其他skydrive为了简化server端，都是整个文件上传， 这样是降低用户体验
， |
|
|
g***u
发帖数: 5413 | 11 dropbox好像是如果不同用户上传同样一个文件，只存一个拷贝，这样也会快一些。
hash
【在 g*******t 的大作中提到】
: dropbox是分块block上传， 只传变动部分， 这个需要在server端搞一个更大的hash
: 数据库，
: 很明显，其他skydrive为了简化server端，都是整个文件上传， 这样是降低用户体验
: ，
|
L*****e
发帖数: 8347 | 12 这就我上面说的，差别备份使得sync速度很快，但是协作工作变得很麻烦。假设有一个
文件，10个reviewer，然后大家都在这个文件上加review comments，然后sync，每个
reviewer要能看到其它reviewer的comments，也需要可以比较任意两个版本之间的差别
。这个时候差别备份要达到这个要求就很麻烦。。。
hash
【在 g*******t 的大作中提到】
: dropbox是分块block上传， 只传变动部分， 这个需要在server端搞一个更大的hash
: 数据库，
: 很明显，其他skydrive为了简化server端，都是整个文件上传， 这样是降低用户体验
: ，
|
L*****e
发帖数: 8347 | 13 不过，这个跟楼主所说的问题没关系。楼主说的是最初upload文件时速度很慢。。。
【在 L*****e 的大作中提到】
: 这就我上面说的，差别备份使得sync速度很快，但是协作工作变得很麻烦。假设有一个
: 文件，10个reviewer，然后大家都在这个文件上加review comments，然后sync，每个
: reviewer要能看到其它reviewer的comments，也需要可以比较任意两个版本之间的差别
: 。这个时候差别备份要达到这个要求就很麻烦。。。
:
: hash
|
c****e
发帖数: 1453 | 14 That's right. Dedup is the key to make uploading big video/audio file super
fast as the content is not transferred. If as LeftEye said skydrive uses
sharepoint, there might be some compliance issue to disable dedup across
users/orgnizations.
These are not rocket science. Even MS is very slow, it should at most take a
few months for them to deliver that. Windows server 2012 has deduplication
at file system level already.
【在 g***u 的大作中提到】
: dropbox好像是如果不同用户上传同样一个文件，只存一个拷贝，这样也会快一些。
:
: hash
|
k***e
发帖数: 7933 | 15 不懂，差别备份应该更容易做版本比较吧? 比如git.
【在 L*****e 的大作中提到】
: 这就我上面说的，差别备份使得sync速度很快，但是协作工作变得很麻烦。假设有一个
: 文件，10个reviewer，然后大家都在这个文件上加review comments，然后sync，每个
: reviewer要能看到其它reviewer的comments，也需要可以比较任意两个版本之间的差别
: 。这个时候差别备份要达到这个要求就很麻烦。。。
:
: hash
|
s*****m
发帖数: 13092 | 16 刚才测试了一下，没什么问题，concurrent=1的时候就已经是我这里的upload上限了，
上行带宽是2M,已经满了。弄大了也没区别，没看到别人说的burst effect.而且检测到
新文件也挺快的，直接拖一个大文件进skydrive目录，3秒钟就开始直接上传了。
下次碰到问题再汇报。
【在 L*****e 的大作中提到】
: 不过，这个跟楼主所说的问题没关系。楼主说的是最初upload文件时速度很慢。。。
|
j***f
发帖数: 3610 | 17
不是差别备份，而是差别上传。
对协作没任何影响
【在 L*****e 的大作中提到】
: 这就我上面说的，差别备份使得sync速度很快，但是协作工作变得很麻烦。假设有一个
: 文件，10个reviewer，然后大家都在这个文件上加review comments，然后sync，每个
: reviewer要能看到其它reviewer的comments，也需要可以比较任意两个版本之间的差别
: 。这个时候差别备份要达到这个要求就很麻烦。。。
:
: hash
|
j********2
发帖数: 4438 | 18 我倒觉得可能是服务器性能的问题，dropbox搭在aws上，相信比skydrive的负载能力要
强 |
j********2
发帖数: 4438 | 19
差别备份相当于对单个文件做了更深入的细化，不同人作出的不同差别显然在server那
边记录的更加详细了，这对协同应该是更加有利的。
再说SCM里面有用差别存储的，也有用整体存储的，都能实现最基本的协同工作，不同
也就是时间换空间，或者空间换时间的问题了，但对于最终用户来说，效果是没有区别
的，不知道所谓的麻烦从何而来。
【在 L*****e 的大作中提到】
: 这就我上面说的，差别备份使得sync速度很快，但是协作工作变得很麻烦。假设有一个
: 文件，10个reviewer，然后大家都在这个文件上加review comments，然后sync，每个
: reviewer要能看到其它reviewer的comments，也需要可以比较任意两个版本之间的差别
: 。这个时候差别备份要达到这个要求就很麻烦。。。
:
: hash
|
L*****e
发帖数: 8347 | 20 我理解差别上传决定了在服务器端它也是差别备份，如果要追溯到前面某一个版本，就
需要在服务器端undo那个版本之后发生的所有changes。
对于协作的影响，假设一个文件有10个人对v 1.0修改，然后某人修改完了以后上传，
这个时候这个上传的版本是和原来的 v 1.0比较差别呢？还是和这10个人中某个已经上
传的版本v 1.7比较差别呢？
协作需要知道三件事，你开始work on的版本，你work on的版本以后上传的change，还
有你自己做的change，差别上传及差别备份带来的麻烦是将来找到某个中间版本是什么
样时要费事。。。
这个有点类似于你复杂的四则运算，你记录每步的加减乘除及数字还有最后结果。如果
问你计算到第17步时的结果是什么，你只知道第17步你做了一个乘2的运算，但是这步
的结果是什么你不知道，你得undo第17步以后的所有运算。。。
【在 j***f 的大作中提到】
:
: 不是差别备份，而是差别上传。
: 对协作没任何影响
|
|
|
L*****e
发帖数: 8347 | 21 如果只是差别上传，但是在服务器端根据差别再生出完整文件进行完整备份，那么我说
的问题就不存在了。。。
但是我很怀疑它是做完全备份的话，如果完全备份，下次想做差别上传的话，hash到底
跟那个版本的文件去map比较？
具体的我也不懂，希望有清楚的童鞋给大家讲解一下。。。
【在 j********2 的大作中提到】
:
: 差别备份相当于对单个文件做了更深入的细化，不同人作出的不同差别显然在server那
: 边记录的更加详细了，这对协同应该是更加有利的。
: 再说SCM里面有用差别存储的，也有用整体存储的，都能实现最基本的协同工作，不同
: 也就是时间换空间，或者空间换时间的问题了，但对于最终用户来说，效果是没有区别
: 的，不知道所谓的麻烦从何而来。
|
s*****m
发帖数: 13092 | 22 office 2013就是差别上传啊，可以协作
【在 L*****e 的大作中提到】
: 如果只是差别上传，但是在服务器端根据差别再生出完整文件进行完整备份，那么我说
: 的问题就不存在了。。。
: 但是我很怀疑它是做完全备份的话，如果完全备份，下次想做差别上传的话，hash到底
: 跟那个版本的文件去map比较？
: 具体的我也不懂，希望有清楚的童鞋给大家讲解一下。。。
|
j***f
发帖数: 3610 | 23
对单独文件，无论redo还是undo，都不会太影响性能。现在的计算能力足够。
关于你说的例子，可以有很多放法进一步优化，比如每隔五步进行一次完整备份。
多个人协作，能做的只能是记录checkout的时候的版本，或者就像google doc那样在线
即时协作。那就完全是另一个问题了。
【在 L*****e 的大作中提到】
: 我理解差别上传决定了在服务器端它也是差别备份，如果要追溯到前面某一个版本，就
: 需要在服务器端undo那个版本之后发生的所有changes。
: 对于协作的影响，假设一个文件有10个人对v 1.0修改，然后某人修改完了以后上传，
: 这个时候这个上传的版本是和原来的 v 1.0比较差别呢？还是和这10个人中某个已经上
: 传的版本v 1.7比较差别呢？
: 协作需要知道三件事，你开始work on的版本，你work on的版本以后上传的change，还
: 有你自己做的change，差别上传及差别备份带来的麻烦是将来找到某个中间版本是什么
: 样时要费事。。。
: 这个有点类似于你复杂的四则运算，你记录每步的加减乘除及数字还有最后结果。如果
: 问你计算到第17步时的结果是什么，你只知道第17步你做了一个乘2的运算，但是这步
|
