背景
2015年5月 HTTP/2 标准协议正式发布后,已得到绝大部分的浏览器的支持,但截止发文时使用的网站占比还不到1/3。
本文目的是为了快速搭建一个本地HTTP/2服务,以供研发小伙伴开发测试,从而加深对HTTP/2的理解。
环境
OpenSSL:1.0.2qNginx:1.15.7
步骤
- 生成本地根证书:
1 | # 使用AES256-bit编码加密生成4096位的根秘钥 |
各参数可以查看man ca 或者 查阅这里。
2015年5月 HTTP/2 标准协议正式发布后,已得到绝大部分的浏览器的支持,但截止发文时使用的网站占比还不到1/3。
本文目的是为了快速搭建一个本地HTTP/2服务,以供研发小伙伴开发测试,从而加深对HTTP/2的理解。
OpenSSL: 1.0.2qNginx: 1.15.71 | # 使用AES256-bit编码加密生成4096位的根秘钥 |
各参数可以查看man ca 或者 查阅这里。
最近有一个线上的es查询问题,最后确定在使用
bool query多条件组合查询时出现should子句查询失效,于是查找资料来确定问题所在。
其中Elasticsearch: 5.5.0
找到相关的查询语句:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26"query": {
"bool": { // bool query 查询
"should": [ // should子句
{
"match_phrase": {
"name": {
"query": "星起",
"boost": 30,
"slop": 5
}
}
}
],
"filter": { // #filter子句
"bool": {
"must": [
{
"terms": {
"round": ["A轮"]
}
},
]
}
}
}
}
问题在于:使用 bool query组合查询时,should与filter 组合查询的结果只匹配了filter子句,并不匹配should子句,达不到should和filter取交集的预期。
最近用 Grape 重写了一份API,马上要上线了,突然接到boss通知,需要做好应用服务器监控,以便上线遇到突发情况。于是乎从万能的 github 上找到了这个开源的代码:unicron_metrics。用起来还不错,下面给大家介绍一下认识。
unicorn_metrics是采集基于Rack应用服务性能数据的工具, 尤其针对类似Unicorn
的多进程服务器,并提供一个对外查看数据的接口。
通过 raindrops 来采集Uincorn指标数据,同时通过构建Middleware统计应用中HTTP指标数据。
unicorn_metrics监控指标分2部分:http指标和raindrops指标, 下面介绍各方面的指标:
| 指标名称 | 指标类型 | 说明 |
|---|---|---|
| request.GET | timer | GET请求的消耗时间(ms) |
| request.POST | timer | POST请求的消耗时间(ms) |
| request.PUT | timer | PUT请求的消耗时间(ms) |
| request.DELETE | timer | DELETE请求的消耗时间(ms) |
| request.HEAD | timer | HEAD请求的消耗时间(ms) |
| responses.2xx | counter | 响应状态为2xx的次数 |
| responses.3xx | counter | 响应状态为3xx的次数 |
| responses.4xx | counter | 响应状态为4xx的次数 |
| responses.5xx | counter | 响应状态为5xx的次数 |
| raindrops.calling | gauge | 应用服务器调度的数量 |
| raindrops.writing | gauge | 被写入数据的客户端的数量 |
| raindrops.active | gauge | 所有进程中已连接并尚未关闭的sockets的连接数 |
| raindrops.queued | gauge | 等待连接sockets的请求数 |
最近在开发Cloud Insight API时,发现一个可以检测ruby代码质量的工具-RubyCritic。
RubyCritic 集成 Reek, Flay 和 Flog这3个分析代码的工具,对你的Ruby代码进行静态分析并生成质量报告。
可以总览你的项目,并且可以对代码打分(百分制)
根据各自的坏味道数量建立文件索引
对不同文件按照改动频率、复杂度、重复度和坏味道4个维度进行综合评定代码质量等级

最近在解决探针获取Ruby应用服务器的内存使用的情况,将解决的思路总结一下,希望对此感兴趣的伙伴一起探讨。
先对比应用服务器:Puma和Passenger,下面对比这2个服务器内存统计,
单进程模式:直接获取进程id: Process.pid1
memory = `ps -o rss= #{Process.pid}`.to_f / 1024 #单位:MB
cluster模式:以启动2个worker进程为例:

从上面截图可以看到,Puma启动后会出现3个进程:1个master进程和2个worker进程。
内存的使用情况(见RSS列):1
(109908 + 109868 + 7256 ).to_f / 1024 = 221.7109375 #单位:MB
而对于探针来说,一个探针实例是伴随进程一起启动的,也就说一个探针只能识别自己所在的进程id,那如何获取应用服务器使用的内存?我们用其中1个woker进程所在的进程组[PGID]看一下:(为啥不是父进程?, 见下文Passenger)