暴风雨中的 online : .NET Core 版博客站点遭遇的高并发问题进展

  • 时间:
  • 浏览:37
  • 来源:大发快3_快3腾讯app_大发快3腾讯app

今天暴风雨袭击了杭州,而昨天暴风雨(高并发问题图片)席卷了园子,留下一片狼藉。

在前天傍晚,亲戚亲戚.我都.我都.我都 进行了 .net core 版博客站点的第二次发布尝试,在发布后通过 kestrel 直接监听取代 nginx 转发解决了高并发下的1秒延迟问题图片,成功地顶住了下班前的访问小高峰,但这这些 一场大雨,第多日 的上午和下午的暴风雨(访问高峰中的高并发)才是真正的考验。

昨天,面对暴风雨,亲戚亲戚.我都.我都.我都 哼一定会敢哼一声“让暴风雨来得更猛烈些吧”,这些 突然不停地默念“让暴风雨快点过去吧”,尤其在下午的暴风雨袭击下,跑在 docker swarm 上 .net core 版博客系统溃不成军,絮状请求响应强度单位极不稳定,时而快如闪电(10ms左右),时而慢如蜗牛(10s, 200s 甚至超时)。与第一次发布时不一样,不仅博客应用容器外是暴风雨,容器内也是暴风雨,在容器内用 curl 命令访问与內部用浏览器访问问题图片一样(难不成真的是 docker swarm 网络的问题图片?kestrel 监听取代 nginx 转发这些 将网络并发负载从 nginx 容器转到了 kestrel 所在的博客应用容器。。。有待验证。)

昨天 17:200 左右并发量回落到一定程度刚刚,暴风雨飘然而去,立刻风平浪静,晴空万里,下午的那场暴风雨宛如梦中。

在暴风雨刚刚,亲戚亲戚.我都.我都.我都 查看过服务器的 linux 系统日志,发现这些下面的日志,有刚刚都趋于稳定在暴风雨期间。

Aug  8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet
Aug  8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet
Aug  8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet

当时 docker swarm 集群中一共5台 worker 节点服务器,统计了一下每台服务器出現 "table full" 日志的数量。

blog-swarm-n3: 2149
blog-swarm-n4: 1964
blog-swarm-n5: 2451
blog-swarm-n6: 2095
blog-swarm-n7: 0

咦,为何有1台服务器为0?哦,这些 是这台如此 挂上所有负载均衡,只承受了 2/3 左右的流量,其实下的暴风雨,但对这台服务器来说这些 一场大雨。

针对里面的日志,亲戚亲戚.我都.我都.我都 调整了 linux 内核的 2 个设置置(参考文档),在 /etc/sysctl.conf 中打上去

net.netfilter.nf_conntrack_max = 6553200
net.netfilter.nf_conntrack_tcp_timeout_established = 1200

这些调整成为亲戚亲戚.我都.我都.我都 今天唯一的希望,但早上访问高峰来临的刚刚,迎接亲戚亲戚.我都.我都.我都 的一定会喜出望外,这些 昔日重来。。。

在熟悉的暴风雨背后,亲戚亲戚.我都.我都.我都 面临着艰难的选者,放弃-退回 windows 上的 .net framework 版博客系统,还是坚持-为宜要找到某种能抵挡一定程度暴风雨的临时解决法律法律依据?

那台如此 "table full" 日志的服务器给了亲戚亲戚.我都.我都.我都 启发——分而治之,将暴风雨变成每一台服务器的大雨,拆分流量到不同的服务器,减少每台服器的并发连接数,今天这些 通过这些临时的笨法律法律依据扛住了暴风雨,絮状减少了响应强度单位慢的清况 ,这些到现在 .net core 版博客站点依然在线。

在抗过今天上下午访问高峰的暴风雨后,杭州也被暴风雨袭击了,可能性有了房子,任凭外面风吹雨打,亲戚亲戚.我都.我都.我都 不需要 坐在房间里一边敲着代码,一边凝听着窗外的风雨声。对于这次遇到的高并发问题图片,亲戚亲戚.我都.我都.我都 相信总有一天会为亲戚亲戚.我都.我都.我都 的博客系统建造好房子,在暴风雨的风吹雨打中潇洒地在日志中写着“让暴风雨来得更猛烈些吧”。