背景交代
- 前一段时间，每当有新项目上线，或者爬虫来爬的时候，服务器基本上就爆满了。MySQL直接就宕机了。
- 为了解决这种情况，我们使用es来支持数据的检索，提供服务。MySQL的问题解决了，但是网站还是支持不了高并发。访问量一大就返回502。
- 我们先来看响应50x能带给我们什么信息
50x的报错信息
- 500，是指上游服务器错误，如果是PHP，也可以说是fastcgi的错误 ，比如在解释器（zend引擎，可以算是一个微型的虚拟机）解释代码的时候发现版本不匹配，或者php语法错误，就会报500
- 502是也是指上游服务器错误，但不是代码层面的问题,这个错误往往是php响应超时造成的，或者php内存太小，我们可以通过php.ini来合理配置相关的参数
- 504则是Nginx抛给用户的错误，比如php我设置了超时5s,但是Nginx设置了超时1s,如果程序响应超过了Nginx规定的时间，或者Nginx一下子接收的请求太多了，根本没时间处理，超时了，则Nginx返回504给用户，这个超时是可用通过设置nginx.conf来调优的
定位错误
- 通过分析日志我们发现，大部分的报错是502，那么就定位是php的问题
- 另一方面，我们的接口也很不稳定，有时候快，有时候慢，刚开始以为是es的问题，但是我们通过分段打印日志，发现es没有问题，而是php有时候响应有7-9s。
- 但是提供同样的服务和数据，有一个接口却从来不会超时，响应都在毫秒级。这个接口就是go写的。
go和php性能测试
代码展示
- go和php对于高并发的差别到底有多大呢，我想通过实际的测试，来和大家一起看一下
- 我写了两个接口， 一个是laravel写的获取列表的方法
public function list()
{
$sql="select * from cms_blog limit 20";
$list=DB::select($sql);
return $this->success($list);
}
在这里插入图片描述
- 一个是用gin+gorm写的一个获取列表的方法，两者返回一致
在这里插入图片描述
性能对比
- 为了模拟高并发下的性能，我们使用jmeter
-
这里面的设置解释一下：线程数20，也代表并发数。线程在10s内全部开启。每个线程循环100次，也就是说一共发送20*100个请求
在这里插入图片描述 -
添加聚合报告和结果树在这里插入图片描述
-
添加http请求
在这里插入图片描述 -
执行完毕之后查看结果，关注一下四个指标，平均值，90%百分位，异常和吞吐量，我们看到在20个并发下没有任何异常，感觉不错，
在这里插入图片描述
测试php并发量
- 我们必须得找到一个统一的标准来测试，所以我们要找出异常指标为0的情况下最大请求数
-
我们把20个并发改成200个再看一下，已经有异常了，我们关闭
在这里插入图片描述 -
100-200之间再取150试一下，还是有异常，php处理不过来，抛错误502了
在这里插入图片描述 - 使用二分法不断测试最大承受并发量，并发120，10s内发送请求12000个，我们得到指标如下
- 并发:120
- 吞吐量：90.8(每秒处理请求数)
- 90请求时间：1834（单位是毫秒，也就是90%的请求都是在1.8s内完成的）
-
平均请求时间：1204
在这里插入图片描述
用相同方法测试go并发量
- go相关代码
func (t *BlogController) GetList(c *gin.Context) {
blog:=model.BlogModel{}
List := blog.GetList()
c.JSON(200, gin.H{
"code":10000,
"msg": "ok",
"data": List,
})
return
}
func (m *BlogModel) GetList() ([]Blog) {
list := make([]Blog, 0)
err := Db.Limit(20).Find(&list).Error
if err != nil {
return nil
}
return list
}
-
我们先来看看在相同并发下，go的表现怎么样
在这里插入图片描述 在并发120的情况下，得出以下数据
并发:120
吞吐量：1122(每秒处理请求数) ，是PHP的10倍左右
90请求时间：42（单位是毫秒），只有PHP的1/400
平均请求时间：20 只有PHP的1/600
为了性能的考虑，我们加入超时机制，响应时间限制为2s以内,相关代码如下
func (t *BlogController) GetList(c *gin.Context) {
var res []model.Blog
// 在规定时间内返回成功进入success
var success = make(chan []model.Blog)
//设置超时时间2s
ctx, cancel := context.WithTimeout(c, 2*time.Second)
defer cancel()
go func() {
wg := sync.WaitGroup{}
wg.Add(1)
defer wg.Done()
blog := model.BlogModel{}
res, err := blog.GetList()
if err != nil {
fmt.Println("i got an error")
fmt.Println(err)
success <- nil
return
}
success <- res
wg.Wait()
}()
for {
select {
case res = <-success:
c.JSON(200, gin.H{
"code": 200,
"msg": "ok",
"data": res,
})
return
case <-ctx.Done():
c.JSON(http.StatusBadGateway, gin.H{"code": 999})
return
}
}
}
- 注意，处理err很重要，否则可能会导致有部分请求无响应
func (m *BlogModel) GetList() ([]Blog, error) {
list := make([]Blog, 0)
err := Db.Limit(20).Find(&list).Error
if err != nil {
return nil, err
}
return list, nil
}
- 我们再来测试一下，并发600有异常，大概并发是550左右
- 并发:550
- 吞吐量：1058.3(每秒处理请求数) ，这里的吞吐量增加，和开启goroutine有关系
- 90请求时间：770（单位是毫秒，也就是90%的请求都是在1.8s内完成的）
-
平均请求时间：407
在这里插入图片描述 -
如果限制吞吐量（一秒内处理的请求数，也称为rps Requests Per Second 的缩写,相对于qps Queries Per Second 的缩写，更能反映系统的实际处理能力。）的话，并发量（同一个时间点处理的线程数）还可以继续增加。比如下面我设置rps为500，我们看一下
在这里插入图片描述 -
这里我开启了800并发，总共发起请求是80000个，限制rps 500左右，发现并发能力大大增强，而且每个请求的相应时间更短，但是，要处理掉全部的请求，时间变长了。感觉cpu有点像消化系统，吃的太多，反而响应变慢了。如果细粒度喂养，就会响应更快
在这里插入图片描述
