代码 > https的效率影响
2018-01-27
blog重构后，在本地跑了下性能测试。发现https，至少是nginx的默认设置对效率的影响还是很大的。
本地环境:rmbp 13,2014 mid 中配
debian testing,nginx version: nginx/1.13.8
测试结果:
使用证书和不使用证书，在某些情况下能有一个数量级，也就是10倍的效率差距。
测试结论:
普通应用全上https证书自然是没问题的，毕竟前端的负载均衡是最容易扩充的。真的要求极限性能的地方，比如内网验证服务，还是要考虑下的。成本敏感的话，全站https还是需要考虑下的。
测试数据:
直连:
ab -n 10000 -c 100 http://127.0.0.1:8000/site/blogi/150-
Requests per second: 19273.02 [#/sec] (mean)
nginx反代:
ab -n 10000 -c 100 http://local.jarlyyn.com:1000/site/blogi/150-
Requests per second: 12578.55 [#/sec] (mean)
nginx https(let's encrypt证书)反代:
ab -n 10000 -c 100 https://local.jarlyyn.com/site/blogi/150-
Requests per second: 1173.36 [#/sec] (mean)
nginx配置:
server {
ssl on;
ssl_certificate_key /ssl/local.jarlyyn.com.key;
ssl_certificate /ssl/local.jarlyyn.com.fullchain.crt;
server_name local.jarlyyn.com;
listen 443 http2;
access_log off;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8000;
}
}
网络 > 第三方登录的选择
2018-01-17
最近在给博客加评论，那势必最方便的是直接使用各家的第三方登录。
国内的微信/支付宝之类的登录虽然轻车熟路，但需要支付费用还不提，还需要审核。
备案还是小事，博客这玩意实在不容易过审，也就不考虑了。
除了吃饭必备的github,之前还打算用Steam登录的。
Steam的第三方登录只有一句openid,什么其他的文档都没有，在坑兹坑兹找了一通后，发现cli下curl访问不到。
对，想起来了，被墙了。
上dotamax上重新授权steam帐号，直连的话无法访问……可怜的dotamax……
反过神来考虑下其他第三方登录的选择。
facebook/twitter,之前倒是做过，但实在是用起来不方便
linkedin到还不错，但是信息太敏感。
纠结了下，能搞定中国政府的美国大互联网公司，应该也只有田字牌，水果和亚马逊了。
亚马逊帐号有的人少。
水果的不喜欢，好像也没提供oauth
那就只能田字牌了，毕竟没用过windows的还是少数啊。
无论如何，只要windows和office还在，微软总不会倒闭的。就怕他乱改。
Linux > 记录:恢复windows更新后，grub rescue> error unknow filesystem错误
2018-01-11
在grub resuce模式中，通过ls确认自己的所有分区。
找到自己的root和boot分区.
如果你的root分区是(hd0,gpt7)
set root=(hd0,gpt7)\
如果你的boot分区是(hd0,gpt6)
set prefix=(hd0,gpt6)\grub
(如果没有将boot和root区分开，则为实际目录.
然后正常进入grub菜单
insmod normal
normal
正常启动linux后，以root权限执行
update-grub
grub-install /dev/sda
完成收工
参考:https://askubuntu.com/questions/142300/how-to-fix-error-unknown-filesystem-grub-rescue
代码 > 记录:golang中错误在for range中对值使用了指针。
2018-01-08
某段程序出错，最后定位到错误在大概这样的结构
for _, v := range data {
c <- &v
}
这样，整个cannel里，都只有最后一个v值
整理了下思路，也很好理解。
这样的代码某种角度相当于
{
var v int
for _, v = range data {
c <- &v
}
}
而非
for _, v = range data {
var v int
c <- &v
}
那自然都是最后一个值了。
作为一个每个循环中都要使用的值，自然不可能不停的创建新的。这太不环保。
但直接的写法里比较难直接看出来。
记录下，以后至少记得解决的方向
代码 > 记录:通过golang的reflect包创建value的指针
2018-01-03
这个问题困扰了我一定时间，搜了一圈后发先自己2了
先用New创建空指针
然后给指针的Elem设置为具体的值。
主要一直以为New出来的对象没发用，是个zero value,到处panic,没反映过来elem还是可以用来set的。
其实想想也是，如果没法赋值的话，这个New函数有什么用……
大概代码:
var v = mapvalue.MapIndex(reflect.ValueOf(key))
var vp = reflect.New(v.Type())
vp.Elem().Set(v)
游戏 > 最近沉迷于神界原罪
2018-01-01
黑5的时候发现最近很火的神接2原罪2的上一代有了官中，赶紧乘打折买了。
发现自己还是喜欢这一口老式游戏啊。
为了熟悉系统，不停的重新build重开任务，几十个小时了第一章还是没过，也是服了自己了。
最后完的还是变态了，每个队友一人学一点土系，蜘蛛，游，落石，本职技能都不高兴放，先构筑个火烟带。
把视线屏蔽了，逼迫对方移动进来，然后一群蜘蛛堵路，出头一个秒一个。
一下子体会了赤壁是面对曹军的周都督的感受啊。
自己都觉得自己太不人道了……
好久没过这么投入的体验了。上个一个能让我长时间放下dota2不玩的应该是文明5/6？
现在开始期待2出官中。
结果写这篇文字的时候，去看2有没有官中，顺手又入了个Pyre……
杂言碎语 > 2017年终总结
2017-12-29
一眨眼，又到年底最后一个工作日了。
这一年过得怎么样呢？
这一年过的真不怎么样。
收入也没什么提升。
工作上用的代码，基本没什么更新，更多的时间建花在了团队构建上了。
一年过去了，自己的代码包还没完全定型。几个早早就确定要做的功能还停留在构想阶段。
不知道是不是娃越发的皮了，感觉有时候还是有点累了。
应该算是正式到了中年危机吧。
今年和去年相比，连steam上的游戏都没精心多少。照片也少拍少修了不少。
除了娃的成长。
不尽如人意啊。
杂言碎语 > 手机又被娃摔了
2017-12-28
继6月份买的mix,10月份买的米6,之后，昨天又狠狠的把米6的后背摔的粉碎了。
好吧，继续换手机。换了mix2。
半年里话了9000块买小米手机，真心不容易啊……
再摔，小米也没其他机型了，估计要换华为的了……
工地 > 进一步优化缓存组建
2017-12-15
脑子里还是满脑子的程序优化。
回家可能是吃饱了，灵感一动，想到了新的提升页面效率的方法。
Golang的话，本身常驻内存，不和php似的要把缓存都放在进程外，也不向nodejs是那样对多核支持不佳。
程序内存就是效率最高的缓存了。
提高效率可以先从降低redis的使用率开始。
用redis而不是内存缓存其实最主要还是为了能够分布式，或者说是冗余。
那么其实redis只要负责缓存的状态就行了，实际较大的内容，比如页面，还是缓存在本地就好了
redis里放个内容的更新状态(摘要或者甚至是时间戳都行)
赶紧着手，就着我的redis缓存和cachegroup缓存改了一个hash缓存驱动出来。
测试跑通，感觉上手。
的确有一定的提升。
从10k左右到了13k不到。
效果还算暂时能让我满意。
发现目前影响缓存效率最主要的还是内容大小。
也就是，以profile来说，目前最大的大头是 分配内存以及传递数据了。
再下去怎么优化，暂时有点失去方向了。