工地 > 换个缓存组件
2019-03-25
花一晚上用atomic和sync.map撸了个缓存组件。
占了不用复制内存的优势，在笔记本跑一跑本机轻松首页90000+rps ……
我怎么记得我的台式机也才这个值…………
不管了，先切换一下，看看稳定性和bug.
然后在腾讯的vps双核一跑，6k+rps....
突然觉得我的笔记本好神……
工地 > 蛋疼的rps瓶颈
2019-01-20
这两天闲来蛋疼，对博客继续跑benchmarking。
编译了wrk,效率还是在100%左右。不信邪。同时跑几个ab,发现加起来还是和跑单进程差不多。
那说明就是代码问题了。
各种检查代码，profile,替换代码。最后锁定到之前的内存缓存库上。
跑个测试比用redis的缓存驱动还要慢，也真是福。
最蛋疼的是我ryzen 1700的台式机，居然比我i5 的笔记本还慢个20%，实在过分了
最后换了个内存驱动测试，效率终于上去了。
首页从3xxxxrps变成8xxxxrps了
倒是空api接口从20xxxx降低到了16xxxx rps
所以凡事都是有代价的么……
倒是ryzen的多核性能在某些情况下并不比移动i5好多少，实在有些出乎我的意料。
工地 > 搞了个乌龙，目前的服务器还有一年多到期
2018-11-28
今天辛辛苦苦把服务器迁移到do，开始感叹这三年一事无成之后，突然发现，时间线对不上啊。
怎么算都没三年啊。
赶紧登账号一看，服务器2010到期...
好吧，突然感觉多活了一年，赚大发的感觉...
还是把域名再指回来了。
不过话说回来，do的服务器还是相当不错的。
明年估计还是会迁移到Do
工地 > 给代码加入了toml支持
2018-08-01
足足忙了半年，代码也没怎么更新过，每天靠游戏强行提神，最近终于空点有精力调整代码了。
首先做的是调整了配置文件格式。
从配置文件来说.TOML比JSON好的太多了。
唯一的问题是golang的两个toml库
https://github.com/pelletier/go-toml
https://github.com/BurntSushi/toml
都有各自的问题。
后者已经停止更新很久了。
前者的话，功能十分强大。但是无法有类似json.RawMessage般可以二次解析的库，也没不能解析结构中的interface.把代码hack一下可以使用。但看了下完整的代码中用的都是比较死，想要完全调整还是有点复杂的。
工地 > 进一步优化缓存组建
2017-12-15
脑子里还是满脑子的程序优化。
回家可能是吃饱了，灵感一动，想到了新的提升页面效率的方法。
Golang的话，本身常驻内存，不和php似的要把缓存都放在进程外，也不向nodejs是那样对多核支持不佳。
程序内存就是效率最高的缓存了。
提高效率可以先从降低redis的使用率开始。
用redis而不是内存缓存其实最主要还是为了能够分布式，或者说是冗余。
那么其实redis只要负责缓存的状态就行了，实际较大的内容，比如页面，还是缓存在本地就好了
redis里放个内容的更新状态(摘要或者甚至是时间戳都行)
赶紧着手，就着我的redis缓存和cachegroup缓存改了一个hash缓存驱动出来。
测试跑通，感觉上手。
的确有一定的提升。
从10k左右到了13k不到。
效果还算暂时能让我满意。
发现目前影响缓存效率最主要的还是内容大小。
也就是，以profile来说，目前最大的大头是 分配内存以及传递数据了。
再下去怎么优化，暂时有点失去方向了。
工地 > 优化完成，发现自己自High起来越发不要脸了
2017-12-14
终于把blog代码走redis缓存在本机提升到10k rps以上了。
手法相当无耻。
在各种分析代码后，发现cpu主要耗费在redis连接和反序列化这两个和内容长度直接相关的部分后。
直接写了个简单的gzip中间件挂在了缓存后面，缓存压缩过的数据。
一下子就ok了。
顺便，在把模板系统也折腾过一遍以后，结论：
- 模板系统也和输出的内容多少直接相关。
- blog这种长度主要在数据的，还是直接缓存页面比缓存数据+渲染快很多。
- Golang的template模块是真心慢。Jet html相对好不少，但还是很难让人满意。同样的首页用本地内存缓存过的数据渲染的话，大概也只有5k-6k rps。走redis就真心没法看了，2k rps出头。
- 在c10k这个层面，走redis的成本其实也是很高的。
工地 > 博客pprof分析
2017-12-13
给blog程序做了个pprof分析。
先是安装 工具库
go get github.com/pkg/profile
然后再引入
import "github.com/pkg/profile"
再在入口中加入代码
defer profile.Start(profile.CPUProfile).Stop()
然后go build,ab跑需要的值。
再go tool pprof ./app pprfo文件位置,输入web指令，看到全图，能按时间占用来分析网站的问题点在哪了。
就我这次分析，一共是151s/238s。
其中
http请求头解析 13s
http相应写入 26.8s
属于硬消耗，除非不使用net/http,否则基本无法避免和优化。
fd操作：
accept fd_unix 6.07s
destory fd_unix 9.76应该也是避不过。
msgpack的反序列化是27s,比我一直预期的其实要更好。
然后大头就是redis连接使用的70s了。
直接就占了总cpu消耗的1/3了。
看来只要用了 redis库，这个数量级就逃不掉了。
唯一能优化的地方是，为了能按分类优化，我加如了一个临时前缀。
这部分走的也是redis,占用了大概占用了一般的redis消耗，这是个很大的问题。
工地 > 博客负优化中
2017-12-13
最近终于有了一点时间，开始完善自己的go框架，拿博客作为方向。
重做用户系统，加入评论功能。
在修改/调整缓存模块的时候，再跑了一下ab,发现网站访问的愈发的慢了。
同一台2014 rmbp
在使用freecache做程序内缓存的时候，从之前有记录可查的首页18k rps/内页22k rps下降到了 13k /18k
驱动切换为redis的话，低到令人发指的，8k.12k
连c10k都实现不了了。
充分暴露我了我只是一个喜欢写代码的渣渣票友的本质……
真担心等真的调整完功能都实现后rps连php都不如了。
只能催眠自己这是因为电脑Cpu老化了,终于有理由可以换新电脑了-_____-