工地 > 换个缓存组件

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一下可以使用。但看了下完整的代码中用的都是比较死,想要完全调整还是有点复杂的。

工地 > 修正一堆BUG

2018-04-08

果然相对于写代码,我更擅长的是写bug...

工地 > 加入留言系统

2018-01-29

网站重构

加入第三方登录和留言系统

工地 > 进一步优化缓存组建

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了。


顺便,在把模板系统也折腾过一遍以后,结论:

  1. 模板系统也和输出的内容多少直接相关。
  2. blog这种长度主要在数据的,还是直接缓存页面比缓存数据+渲染快很多。
  3. Golang的template模块是真心慢。Jet html相对好不少,但还是很难让人满意。同样的首页用本地内存缓存过的数据渲染的话,大概也只有5k-6k rps。走redis就真心没法看了,2k rps出头。
  4. 在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老化了,终于有理由可以换新电脑了-_____-