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

  • 时间:
  • 浏览:0
  • 来源:大发快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 部署算是并能在访问高峰长时间持续稳定运行以及并能 几条台服务器?待进一步验证。