修正一堆BUG

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

发布于
2018-04-08

加入留言系统

网站重构

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

发布于
2018-01-29

进一步优化缓存组建

脑子里还是满脑子的程序优化。

回家可能是吃饱了,灵感一动,想到了新的提升页面效率的方法。

Golang的话,本身常驻内存,不和php似的要把缓存都放在进程外,也不向nodejs是那样对多核支持不佳。

程序内存就是效率最高的缓存了。

提高效率可以先从降低redis的使用率开始。

用redis而不是内存缓存其实最主要还是为了能够分布式,或者说是冗余。

那么其实redis只要负责缓存的状态就行了,实际较大的内容,比如页面,还是缓存在本地就好了

redis里放个内容的更新状态(摘要或者甚至是时间戳都行)

赶紧着手,就着我的redis缓存和cachegroup缓存改了一个hash缓存驱动出来。

测试跑通,感觉上手。

的确有一定的提升。

从10k左右到了13k不到。

效果还算暂时能让我满意。

发现目前影响缓存效率最主要的还是内容大小。

也就是,以profile来说,目前最大的大头是 分配内存以及传递数据了。

再下去怎么优化,暂时有点失去方向了。

发布于
2017-12-16

优化完成,发现自己自High起来越发不要脸了

终于把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的成本其实也是很高的。
发布于
2017-12-14

博客pprof分析

给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