Lucas66666的博客

一 前提与背景1 前提只要出现CLOSE_WAIT累积一定是自己服务写的有问题2 背景给自己服务访问第三方服务加了连接池后，压测时候发现请求结束后有很多连接处于close_wait状态，且一直不结束用连接池的原因是为了连接复用与连接控制二 解决过程1 知识点回顾在正式解决该问题前，先回顾下“TCP四次挥手”过程理解四次挥手时候不要用 服务端-客户端这样去理解每次挥手过程， 而是要以谁是主动断开连接的(即主动发送 FIN)为标准2 服务是如何解决如【背景】图所示，处于 CLOSE_W

一 问题描述接到上游调用方反馈到服务一直504，根本没办法使用，同时机器cpu 监控一直报警二 问题排查过程解决思路1思路一： 接口本身处理比较耗时，加上上游并发请求比较大，所以才会一直报警思路一解决方案： 确实也是如此，如果你的服务处理非常快且不是特别消耗资源那么确实不会在目前的并发下出现密集的504问题。那么先优化目前的接口。 接口是提供图像ocr功能，会加载深度学习模型的模型文件，代码中每一次请求都会重新实例化一个对象，这样做就会存在两个问题：1，每次请求都去load 一次模

python 协程安全理解一 背景二 详情三 总结一 背景在 Cpython中，由于GIL的存在，所以一次同时只能有一个线程占用CPU，但是即便如此，python 仍然存在线程不安全问题(下文解答)， 但是在python中，协程却是安全的二 详情 import eventlet import threading count = 0 def count_10000(): global count for i in range(1000

一 摘要本文基于netflix于19年在O’Reilly软件架构会议的分享做的简单总结，后续会持续更新理解内容。试想测试涉及大规模分布式系统的复杂应用程序，您觉得仅使用测试环境进行测试是否是可靠的？如今，Netflix客户端和服务器应用程序的自动化测试已在生产环境中大规模运行。在短短的几年内，该公司的测试已经从小批量的手动模式变为连续，大量和全自动的模式。会议分享的内容参考链接：netfli...