背景交代

• 前一段时间，每当有新项目上线，或者爬虫来爬的时候，服务器基本上就爆满了。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有点像消化系统，吃的太多，反而响应变慢了。如果细粒度喂养，就会响应更快