迷你MVVM框架 avalonjs v6.1发布,性能大幅提高
本次更新,带来了几个新API与在IE6的更好性能。
- 添加ms-css绑定,用法为ms-css-xxx=yyy, 相当于jQuery的$el.css(xxx,yyy)操作,不同的,以后yyy有什么改动,框架都是自动帮你处理。
- 添加非常好用的html过滤器,即{{ xxx | html}} 相当于原来的 ms-html="xxx",不同的是ms-html是直接使用innerHTML,会替换掉原元素的所有子节点,而html过滤器只对原子节点进行替换,不会伤及无辜。
- 重构ready,原来的对document.readyState强行重置,目的是修复firefox3.5-没有document.readyState的BUG,但会在旧式IE下引起疯狂的检测,如果没有nextTick,这问题都就暴露出来,把IE6-8卡死了。现在去他妈的firefox3.5-,不修了!然后去掉each绑定的两个nextTick,基本上IE就“刷”的一下全部内容出来了。不像angular,knockout那样有明显的停滞!这次优化后,估计DOM就没有什么优化余地了。
- 循环利用文档碎片,整个库只使用一个文档碎片及其克隆。能不克隆的地方就尽量不克隆,因为文档碎片在插入DOM树后,又还原为一个子节点也没有了,作为搬运工,这特性很好用。
- 重构监控数组与each绑定,现在不会在排序时移动节点了,只是回填数据,这是knockout的“最短编辑长度”算法做得更绝。
- 添加noop 方法,就是一个空函数。
- addClass, removeClass, toggleClass现在可以处理多个类名了。
- data方法一个传参也没有时,行为与jQuery保持一致,返回一个对象。
此外,实现一大堆UI组件,包括
- ms-drag="dragcallback""
- ms-ui="slider"
- ms-ui="autocomplete"
- ms-ui="button"
- ms-ui="tabs"
- ms-ui="progressbar"
- ms-ui="accordion"
- ms-ui="spinner"
- ms-ui="datepicker"
官网地址为http://rubylouvre.github.io/mvvm/
减少zk超时时间(建议1分钟)
Rs与zk的timeout默认为3分钟,由zookeeper.session.timeout property决定。也就是说,如果一个rs挂了,那么master需要3分钟之后才能对其进行重启和恢复。建议调成1分钟会更低。
然而,你调低之前应该先确保JVM的配置合理,保证不会引发较长的gc,JVM配置之后会给出,也可以只这样,只要你超时时间可以忍受gc停顿即可。
增加handlers(建议100)
配置项 hbase.regionserver.handler.count 决定了用户表接受外来请求的线程数。默认为10。这个数目主要看你的场景。如果是put百万字节或者大量的scan你可以把它调低来减少对region的压力。如果是小的puts gets 则增加该值来挺高并发量。从而增加整体的吞吐。
Handler数量最好小于clinet并发量。一个典型场景就是多gets(可能是个网站,然后从hbase获取数据)。
调高之后的风险就是,一旦很多的并发写压到了一个rs上面,那么内存会陡增,可能引发OOM。另外,rs的内存不足会引发较长的gc停顿。
增加heap(稍好的8G,差点的自己定吧)
对于hbase当然是越大约好,因为他就是吃内存的东西。稍微好点的机器可以给8G,master相比rs不需要更多的内存,但是rs一定需要。
开启Lzo压缩
增加region的大小(100G,几乎永不分裂)
选项hbase.hregion.max.filesize默认为256M,如果region大小超过他则会分裂为二,如果你的数据量增长的比较快,那么还是建议把这个大小调高,可以调成100G,因为越少的region你的集群越流畅,100G的阈值基本可以避免你的region增长过快,甚至你的region数目会长期不变。当然大region在compaction时也会更加缓慢。几十G的region启动和compaction都非常的慢,如果storefile较多,一个compaction可能会持续几天。
block cache size(读写平衡0.3)
选项perf.hfile.block.cache.size 默认是0.2。调优这个参数需要你自己的观察,可以参照HBase权威指南的394页。
其实常见场景还是读业务比较多的时候可以把它调高。这样可以缓存更多的数据。读写平衡可以设置为0.3。
需要注意的是,block.cache.size memstore limits 这些内存加起来不要超过60%。因为剩余的内存还要用来做其他事情。否则容易OOM。
memstore limits(写多则调高,读多则调低)
这里主要由两个配置项决定:hbase.regionserver.global.memstore.upper 默认0.4和hbase.region.server.global.memstore.lowerLimit默认0.35。后者主要是当服务器需要释放内存时强制rs进行flush(不一定达到flush size)。尽量保证上面两个值接近,这样可以避免频繁的flush。
如果你的读业务比较多,那么调低他们。如果写多,则调高他们。(注意读写的参数相加最好不要超过0.6)。如果你发现flush很频繁,那么调高上面两个配置,这样减少频繁的I/O。
调高blocking store files(10)
选项hbase.hstore.blockingStoreFiles默认为7,如果超过其设定阈值,则会阻塞client的写。它主要是为了给compaction更多的时间来减少store files的数量。如果你是持续写入,那么稍微调高一点,比如10。你可以观察rs的storefile的数量,如果数量一直比较高,那么就不要把这个阈值调高了。因为持续很多的sf会让机器一直compaction,造成的一种情况就是compaction和flush的速度不匹配,然后持续的堆积compaction的任务,rs和dn的连接数会越来越大,直到too many open files。
调高block multiplier(稳定数据写入不必调正,数据量比较大或者偶尔出现峰值则调高)
选项hbase.hregion.memstore.block.multiplier默认为2。它是一种安全机制,如果memstores超过了flushsize的multiplier倍则会阻塞客户端的写。
如果你有足够多的内存,那么你可以把它调高,这样的好处就是可以很好的处理峰值的情况。比如一天可能只有一个时间段内写量很大,那么调高之后就可以避免阻塞写操作了。
减少maximum logfiles(导入数据直接关闭WAL即可,写多则调高,一般情况下小一点比较好)
选项hbase.regionserver.maxlogs默认为32。它只要是控制WAL文件flush的频率。如果写操作比较多,那么可以设置高一点。调低可以让rs更快的把数据持久化,那么就可以直接弃掉WAL了。其实写操作比较多可以直接把WAL关闭,这样更省事了。