概况：最近使用python写了一段图片处理的小逻辑，之后进行了服务部署。
问题：由于python部署方面研究不深，所以使用了最简单的Flask框架直接就部署到了生产环境，并未考虑到并发、线程问题，直到出现管道破裂响应码449时才开始进行处理。
解决：在遇到这个问题之后在同事蓉哥大神大力帮助下解决了这个问题，期间学到了非常多调试、逻辑、部署、http等小知识，受益良多。十分有必要记录下来现整理如下。
1. https -- http && python env问题：
在读取图片时报错了，定位代码段在requests.get(imgUrl)，没有认真看报错信息简单的以为是超时了，
问了下爬虫同事他给了我一个方法使用retrying包进行get，如果报错会尝试三次。开心的把代码引入了程序，
from retrying import retry
@retry(stop_max_attempt_number=3, wait_fixed=100)
def toWaterMark(self, img_url):
req = requests.get(img_url,timeout=30)
return req
此时需要在我目前的env环境中安装retrying包。尝试在env安装此包时总报错，因为我之前安装了但是在整体环境中，然后整个环境就是很乱，我特别早的时候安装了conda2和conda3目的呆萌的觉得在conda2下使用python2，conda3下使用python3，不知道怎么回事现在conda2下面对应的是py3，同事决定全都卸载掉，嗯 ，我又重新安装了conda2，然后不将conda加入环境变量，使用开始菜单中的Anaconda2 先的Anaconda Promopt点开，然后创建虚拟环境。在pycharm中编译器选择新建的env，单个项目全都对应一个env，不在大环境下安装附加包，env单独需要的包就在自己环境下安装。
基于 python3.6 创建一个名为test_py3 的环境
conda create --name test_py3 python=3.6
# 基于 python2.7 创建一个名为test_py2 的环境
conda create --name test_py2 python=2.7
# 激活 test 环境
activate test_py2 # windows
source activate test_py2 # linux/mac
最后在安装期间趁机让研生哥帮我看了下错误，他一眼就看出了原因：端口443 协议https，之前已经解决过在目前我们这个环境下访问不通https的图片，需要改为http://图片，直接将s去掉。 关键之前我已经改过一次，但是忘了改这个项目，感觉很丢人这么简单的错误而且报错日志图片url也很清晰就是没注意到。改完确实好了。但是我知道了一个小知识：http默认80端口，https是443端口。这个我竟然不知道。后来决定要学习了解下http协议相关知识。
https://blog.csdn.net/mccand1234/article/details/54577413
2.管道破裂响应449 ---- 核心问题 ：
服务响应449，管道破裂 -》 超时 -》 修改超时时间 -》 449。
然后搜了下Flask服务部署和开多线程的问题：
1）查找问题：
在部署时，人家提示了不要用于生产环境，而我没在意这些警告-》大神提示要注意 -》449.
报错现象：有正确的有报错的。Broken pipe管道破裂。
我是有点懵懵的不知道原因，为啥出现管道破裂，大神给我解释了一下客户端 nginx反向代理 服务端的关系，我清楚了一点，但是具体什么原因还是不知道。
过了半天大神找到原因了，让我也认识了一个新工具---JMeter : 进行接口测试和压力测试.
测试发现一条一条发进行处理没什么问题，但是在JMeter里面起10个或更多个线程的时候要排队而且时间较长，相比下来就超时报449了。
计划可能问题：
a .程序现在问题及是否加入了多线程；
b. Flask部署服务器软件gunicorn
分析时间消耗在哪：
c. 本地多线程时，测试多次下载url时间是否逐渐增长；
d. 本地多线程时，测试多次处理任务时纯计算时间是否逐渐增长；
e. 本地测试多线程和单线程的时间消耗对比；
f:本地测试多线程和单线程的时间消耗 和 JMeter测试多线程和单线程时间消耗是否一样；
以上是这几天遇到并修改和测试的地方，事实证明不要疏漏每一个细节，都很重要。
详解如下：
a.程序简单的使用一下代码添加了多线程，通过打印线程来看确实线程起起来了，消耗时间后面再说。
app.run(threaded=True)
app.run(processes=20)
# print threading.currentThread() 查看线程号
# threading.Thread(target=run).start() 开启线程
b. Flask部署：Flask+Gunicorn+Nginx
https://juejin.im/entry/5b3ebfadf265da0fa8671f08 部署介绍链接
Gunicorn命令貌似只支持在linux上windows不支持
在python的env里面安装gunnicore, 然后导出requirements.txt --》 运行命令：gunicorn -c gunicorn.conf imgRepeatWeb:app -》重点是gunicore.conf的参数配置，第一版如下：
import os
cwd = os.path.split(os.path.abspath(__file__))[0]
bind = "0.0.0.0:5000"
workers =20
accesslog = os.path.join(cwd, "mediaGunicorn.log")
c. 本地测试 & JMeter测试
之前程序写完我并没有使用本地进行多线程的压力测试，看看运行耗时。现在讲图片下载时间、处理时间、整体时间分别打印出来，发现均会以线程数的增多时间增长，主要考虑是在cpu核数有关。单线程的时候单个执行会很快。
JMeter测试时发现多次线程时间要比本地时间长，整体时间也是增长，图片数多的时候后面直接就499失败了。
why?
最后还是依靠大神找到的答案，即gunicore的配置参数选择问题，
https://ox0spy.github.io/post/web-test/gunicorn-worker-class/
import os
cwd = os.path.split(os.path.abspath(__file__))[0]
bind = "0.0.0.0:5000"
workers =20
worker_class = 'gevent'
worker_connections = 1000
timeout = 120
keepalive = 2
accesslog = os.path.join(cwd, "/tmp/mediaGunicorn.log")
按照如上链接修改上述参数后测试发现线程数增多时间略有增长，但较之前有大大的提升，但是我是绝对不会想到修改这些的。所以以后应该详看各个参数，稍微没加或者没注意就会有这么大的性能影响，以此为戒。
https://github.com/benoitc/gunicorn/blob/master/examples/example_config.py
结语：
多积累、多调试、细心、耐心、感谢
链接参考：
//www.greatytc.com/p/484bd73f1e80
https://juejin.im/entry/5b3ebfadf265da0fa8671f08
