12 / 2 页下一页

论坛徽章:: 4

电梯直达

1楼 [收藏(0)] [报告]

发表于 2010-09-07 18:34 |只看该作者 |倒序浏览

本帖最后由 happy_fish100 于 2010-09-07 19:07 编辑

测试环境：
1台tracker server，2台storage server组成一个group，1台 client。

机器配置：
服务器配置：Dell PE1850, 2 x Xeon 2.80GHz, 2GB / 2GB 400MHz
网卡：eth0 (e1000): Dell/Intel 82541PI Gigabit
操作系统：RHEL AS 4 U7, Linux 2.6.9-89.0.16.ELsmp x86_64, 64-bit

硬盘配置：
存储服务器1：
1 x 73GB 15K U320 Seagate 15K.4

存储服务器2：
1 x 73GB 15K U320 Hitachi Ultrastar 15K147

对比测试结果：
一、上传文件
因磁盘空间有限，上传的文件只占用了约18GB的空间。
因为文件数和存储量都不够大，上传和删除这部分的指标，仅供参考。

上传文件大小及文件个数：
  5KB： 100000
50KB：  20000
200KB： 10000
  1MB： 2000
10MB：    200
100MB： 100

长短连接并发进程数 V1.29 IO       V2.0 IO
短连接       10          27355 KB       30965 KB
长连接       10          31127 KB       45850 KB
短连接       20          33276 KB       40352 KB
长连接       20          32194 KB       39028 KB

二、下载文件
连续下载8个小时
长短连接并发进程数 V1.29 IO    V1.29 CPU负载    V2.0 IO    V2.0 CPU负载
短连接       20          24316 KB       30.70%          23186 KB       21.29%
长连接       20          24592 KB       30.82%          23066 KB       21.63%
短连接       80          34386 KB       55.00%          21051 KB       20.51%
长连接       80          33846 KB       49.64%          21206 KB       20.30%
短连接       160                                                    23985 KB       20.60%
长连接       160                                                    23422 KB       20.52%
短连接       320                                                    31810 KB       22.37%
长连接       320                                                    31657 KB       24.38%
短连接       640                                                    35845 KB       23.95%
长连接       640                                                    38331 KB       24.68%

三、删除文件
长短连接并发进程数 V1.29 IO          V2.0 IO
短连接       10          168264 KB       112176 KB
长连接       10          171500 KB       109423 KB
短连接       20          202681 KB       143838 KB
长连接       20          205011 KB       168264 KB

请大家主要看一下下载文件的对比情况。
V1.29在并发数160以后，因服务器压力太大，错误比较多，测试数据基本没法看，所以没有整理出来。
而V2.0的压力随着访问量上升，并没有明显变化。

长连接和短连接性能差别并不明显。

word格式的测试结果更容易看一些，参见：

V1.29和V2.0压力测试结果.docx (14.66 KB, 下载次数: 299)

文库|博客

tianxueer

白手起家

论坛徽章:: 0

2楼 [报告]

发表于 2010-09-07 19:06 |只看该作者

从测试结果上来看2.0性能的确有很大的提升，LZ加油，期待推出更好的版本！

顺便请教happy_fish100一个问题：
对于在线存储之类的应用，目录结构和文件信息用什么数据库和结构存储比较好？

比如相册服务。

用于存储目录和文件的metadata信息，需求一般是列出某个目录下所有的文件，获得某个文件的信息，在某个目录下创建文件等等。

数据量非常大。

比如FastDFS用来存储文件，但总要有数据库把文件信息都记录下来吧？

简单了解了lz的FastDHT，但是基于Key/Value的，复杂的查询不知道能否实现，比如要列出某个目录下所有的文件？

我觉得最近比较火的NoSQL可能比较适合，性能高，能满足基本的sql检索功能，还支持分布式。

请LZ赐教，谢谢！

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

happy_fish100

巨富豪门

论坛徽章:: 4

3楼 [报告]

发表于 2010-09-07 19:12 |只看该作者

本帖最后由 happy_fish100 于 2010-09-07 19:13 编辑

回复 2# tianxueer

>>比如FastDFS用来存储文件，但总要有数据库把文件信息都记录下来吧？
是的，肯定要通过数据库记录下来的。

>>简单了解了lz的FastDHT，但是基于Key/Value的，复杂的查询不知道能否实现，比如要列出某个目录下所有的文件？
FastDHT只是一个分布式的key value pair（键值对）存储系统，尚不支持列表查询等功能。

正打算写一个分布式目录存储服务，数据检索完全基于内存，会实现持久化存储。
这样的服务应该是LS所期待的吧？