Powered by .NET Core 进展:验证高并发性能问题嫌疑犯 docker swarm

  • 时间:
  • 浏览:23
  • 来源:幸运快3_快3高手计划_幸运快3高手计划

相关博文:

  • 【故障公告】发布 .NET Core 版博客站点引起几瓶 5000 错误
  • 【网站公告】.NET Core 版博客站点第二次发布尝试
  • 暴风雨中的 online : .NET Core 版博客站点遭遇的高并发什么的问题进展

抱歉,.NET Core 版博客系统(博客后台除外)的发布给亲戚朋友 带来麻烦了,亲戚朋友 正在一边忙着修各种 bug ,一边排查访问高峰高并发性能什么的问题。

对于发布后遇到的高并发性能什么的问题,亲戚朋友 你这个都没去怀疑 .net core ,亲戚朋友 怀疑的是 docker swarm ,怀疑在高并发下 docker swarm 网络性能急剧下降,要我极不稳定。

对比新旧版博客系统所消耗的服务器资源,差距之大要我乍舌。同样的并发,完后 基于 .net framework 的旧版博客系统用 6台4核8G 的阿里云 windows 服务器就能撑住,而现在基于 docker swarm +  .net core 的新版博客系统用 6台8核16G 的阿里云 centos 服务器都撑不住。

为了验证亲戚朋友 对罪魁祸首 docker swarm 的怀疑,亲戚朋友 今天由于将 .net core 版博客系统改用 docker-compose 部署:

version: '3.7'
services:
  web:
    image: blog-web
    restart: always
    deploy:
      replicas: 1
      resources:
        limits:
          cpus: '4'
          memory: 7G
        reservations:
          memory: 5000M
    ports:
      - 500:500
    working_dir: /app
    environment: 
      - TZ=Asia/Shanghai
      - COMPlus_GCHeapHardLimit=1C0000000    
    command: bash -c 'sh run.sh'
docker-compose --compatibility up -d 

现在由于发布上线,由于真的是 docker swarm 的什么的问题,明天上午的访问高峰将验证出结果。

目前用了3台4核8G的服务器,明天根据负载状况再增加服务器。

【更新】

8:40 左右,响应速率单位单位更快,加了1台服务器,响应速率单位单位立马恢复。(完后 使用 .net framework + windows 也是在你你这个时间点加服务器)

9:00 左右,又加了1台服务器,现在是5台4核8G的服务器。

9:35 左右,又加了1台服务器,现在是6台4核8G的服务器。

10:00 左右,又加了1台服务器,现在是7台4核8G的服务器。

13:10 左右,退回到 .net framework + windows 博客系统,.net core 博客系统待调整部署与修复 bug 后再上线。

上午使用 docker-compose 部署时,博客系统所依赖的后端服务部署在另外另有十几个 多多 docker swarm 集群上,结果你你这个集群的路由转发老出 了什么的问题。使用 docker-compose 部署还时需将博客系统所依赖的服务进行 docker-compose 部署。

从上午的访问高峰的状况看,docker-compose 部署时的资源瓶颈在 CPU ,老出 响应速率单位单位慢时加服务器就能防止(这是正常状况),没办法 老出 使用 docker swarm 部署时那种响应速率单位单位极不稳定、加服务器也无补的状况。

docker-compose 部署是是不是不能在访问高峰长时间持续稳定运行以及时需有十几个 台服务器?待进一步验证。