-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在原有基础上实现了一个基于多种关联因素的(根据文件大小差异,权重可配置 ,访问比例,命中率等)size_adjusted 动态自调整的多级LRU cache,一些环境下对比测试,性能有很大提高 #486
base: master
Are you sure you want to change the base?
Conversation
|
||
typedef struct { | ||
level levels[10]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
最大是9级,另外还有一个0级: 暂时存放没有开始传输的文件
能否把性能测试步骤描述一下,最好添加一个性能测试脚本。 |
脚本主要分两部分:一个是为后端apache2产生文件的脚本,一个是测试脚本。 python3.3.5 for win7(同学的笔记本,磁盘性能一般) 这是后端apache产生文件的脚本 在自建的 /www下
后端同学的电脑的系统是win7系统 不是很了解NTFS寻道策略,但是大范围的随机访问(最开始我用1.2G=600M小文件+600M大文件) 即使命中率很高,只要随机范围很大,性能没有变化(纵向比较,自身无变化) 这个结论是和顺序访问做了对比后得出的(顺序访问要快很多,而且nginx命中率和速度正相关,而大范围的随机,很慢,命中率即使很高也很没有变化, 缩小范围减少寻道代价就OK) |
这里是测试脚本 随机 批量交替的连续访问,计时,最后对比。。。。(可回归测试)
|
测试结果 |
改进后nginx测试结果 result1.txt 大概在序号20的时候 开始执行分层的max_size的调整 这个改进还是很明显的 |
改进前后都是用同一个nginx.conf:
|
目前测试的结论是:文件大小差异带来的网络传输的速率差异也是很大的(这个我做了很多对比测试), 如果nginx的磁盘足够大(大到足以对命中率没有影响),那么我实现的所谓的分层的意义不是很大,如果磁盘相对宝贵,改进后的算法可能会有一定的意义(至于多大?没有在生产环境下跑一跑,另外还需要合理的配置(程序里面的weight等等,还有一些常系数的调整)需要多去尝试) |
在这个测试用例中: 按照原来的LRU算法,那么大文件和小文件的命中率都在50%左右, 改进后的程序会按照改进算法和配置 提高小文件的缓存空间的大小(当然就缩小了大文件的空间,不过代价是值得的) 这样一来,就提高了小文件的缓存命中率,减少了apache向nginx传输小文件的概率,最难得性能得到很大提高。 |
ack #1214 |
|
1.首先说一个场景:对于300000个1KB的小文件和300个1M 的大文件,虽然总大小一样,但是nginx和后端就此传输代价不一样(测试时差在十三倍左右,两个笔记本做测试所得) 基于此,我设计出基于多种关联因素的 size_adjusted (根据文件大小差异权重可配置)动态自调整的多级LRU cache。
2.通过动态的改变 每个层级的LRU 的max_size 达到更多的缓存 更有价值的文件,提高cache 性能,调整因素包括:各层在这一阶段的访问大小,各层在这时段的命中字节/自身max_size,各层权重,调整前的各层的max_size等等相关因素。
3.随机对比测试(测试环境为两个笔记本,磁盘一般) 改进后性能提高一倍, 测试情景简单表述:1000个1Kb的小文件和1M 大文件交替访问,后端一共有30000个小文件和30个大文件,一共测试100个总轮回,随机测试,(随机测试对磁盘不能跨度很大,否则笔记本的磁盘的寻道排队会成为瓶颈,生产环境的SSD或者其他磁盘会好很多,所以我的测试总的文件大小占据的磁盘空间不能很大(200M)否则大范围的随机寻道会带来大瓶颈)
4.很好的上限控制(根据size动态监测),防止max_size过大造成浪费