构建高效的python requests长连接池详解

前文：

最近在搞全网的cdn刷新系统，在性能调优时遇到了requests长连接的一个问题，以前关注过长连接太多造成浪费的问题，但因为系统都是分布式扩展的，针对这种各别问题就懒得改动了。 现在开发的缓存刷新系统，对于性能还是有些敏感的，我后面会给出最优的http长连接池构建方式。

老生常谈：

python下的httpclient库哪个最好用？ 我想大多数人还是会选择requests库的。原因么？也就是简单，易用！

如何蛋疼的构建reqeusts的短连接请求:

python requests库默认就是长连接的 (http 1.1, connection: keep alive)，如果单纯在requests头部去掉connection是不靠谱的，还需要借助httplib来配合.

s = requests.session()

del s.headers['connection']

正确发起 http 1.0的请求姿势是:

#xiaorui.cc

import httplib
import requests

httplib.httpconnection._http_vsn = 10
httplib.httpconnection._http_vsn_str = 'http/1.0'

r = requests.get('http://127.0.0.1:8888/')

服务端接收的http包体内容:

get / http/1.0
accept-encoding: gzip, deflate
accept: */*
user-agent: python-requests/2.5.1 cpython/2.7.10 darwin/15.4.0

所谓短连接就是发送 http 1.0 协议，这样web服务端当然会在send完数据后，触发close()，也就是传递 \0 字符串，达到关闭连接 ！ 这里还是要吐槽一下，好多人天天说系统优化，连个基本的网络io都不优化，你还想干嘛。。。下面我们依次聊requests长连接的各种问题及性能优化。

那么requests长连接如何实现？

requests给我们提供了一个session的长连接类，他不仅仅能实现最基本的长连接保持，还会附带服务端返回的cookie数据。 在底层是如何实现的？

把http 1.0 改成 http 1.1 就可以了， 如果你标明了是http 1.1 ，那么有没有 connection: keep-alive 都无所谓的。 如果 http 1.0加上connection: keep-alive ，那么server会认为你是长连接。 就这么简单 ！

poll([{fd=5, events=pollin}], 1, 0)  = 0 (timeout)
sendto(5, "get / http/1.1\r\nhost: www.xiaorui.cc\r\nconnection: keep-alive\r\naccept-encoding: gzip, deflate\r\naccept: */*\r\nuser-agent: python-requests/2.9.1\r\n\r\n", 144, 0, null, 0) = 144
fcntl(5, f_getfl)      = 0x2 (flags o_rdwr)
fcntl(5, f_setfl, o_rdwr)    = 0

session的长连接支持多个主机么？ 也就是我在一个服务里先后访问 a.com, b.com, c.com 那么requests session能否帮我保持连接 ?

答案很明显，当然是可以的！

但也仅仅是可以一用，但他的实现有很多的槽点。比如xiaorui.cc的主机上还有多个虚拟主机，那么会出现什么情况么？ 会不停的创建新连接，因为reqeusts的urllib3连接池管理是基于host的，这个host可能是域名，也可能ip地址，具体是什么，要看你的输入。

strace -p 25449 -e trace=connect
process 25449 attached - interrupt to quit
connect(13, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("61.216.13.196")}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(53), sin_addr=inet_addr("10.202.72.116")}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("125.211.204.141")}, 16) = 0
connect(8, {sa_family=af_unspec, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("153.37.238.190")}, 16) = 0
connect(8, {sa_family=af_unspec, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("157.255.128.103")}, 16) = 0
connect(8, {sa_family=af_unspec, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("139.215.203.190")}, 16) = 0
connect(8, {sa_family=af_unspec, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("42.56.76.104")}, 16) = 0
connect(8, {sa_family=af_unspec, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("42.236.125.104")}, 16) = 0
connect(8, {sa_family=af_unspec, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("110.53.246.11")}, 16) = 0
connect(8, {sa_family=af_unspec, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("36.248.26.191")}, 16) = 0
connect(8, {sa_family=af_unspec, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
connect(8, {sa_family=af_inet, sin_port=htons(80), sin_addr=inet_addr("125.211.204.151")}, 16) = 0

又比如你可能都是访问同一个域名，但是子域名不一样，例子 a.xiaorui.cc, b.xiaorui.cc, c.xiaorui.cc, xxxx.xiaorui.cc，那么会造成什么问题？ 哪怕ip地址是一样的，因为域名不一样，那么requests session还是会帮你实例化长连接。

python 24899 root 3u ipv4 27187722  0t0  tcp 101.200.80.162:59576->220.181.105.185:http (established)
python 24899 root 4u ipv4 27187725  0t0  tcp 101.200.80.162:54622->101.200.80.162:http (established)
python 24899 root 5u ipv4 27187741  0t0  tcp 101.200.80.162:59580->220.181.105.185:http (established)
python 24899 root 6u ipv4 27187744  0t0  tcp 101.200.80.162:59581->220.181.105.185:http (established)
python 24899 root 7u ipv4 27187858  0t0  tcp localhost:50964->localhost:http (established)
python 24899 root 8u ipv4 27187880  0t0  tcp 101.200.80.162:54630->101.200.80.162:http (established)
python 24899 root 9u ipv4 27187921  0t0  tcp 101.200.80.162:54632->101.200.80.162:http (established)

如果是同一个二级域名，不同的url会发生呢？ 是我们要的结果，只需要一个连接就可以了。

import requests
import time

s = requests.session()
while 1:
 r = s.get('http://a.xiaorui.cc/1')
 r = s.get('http://a.xiaorui.cc/2')
 r = s.get('http://a.xiaorui.cc/3')

我们可以看到该进程只实例化了一个长连接。

# xiaorui.cc

python 27173 root 2u chr 136,11  0t0  14 /dev/pts/11
python 27173 root 3u ipv4 27212480  0t0  tcp 101.200.80.162:36090->220.181.105.185:http (established)
python 27173 root 12r chr  1,9  0t0 3871 /dev/urandom

那么requests还有一个不是问题的性能问题。。。

requests session是可以保持长连接的，但他能保持多少个长连接？ 10个长连接！ session内置一个连接池，requests库默认值为10个长连接。

requests.adapters.httpadapter(pool_connections=100, pool_maxsize=100)

一般来说，单个session保持10个长连接是绝对够用了，但如果你是那种social爬虫呢？这么多域名只共用10个长连接肯定不够的。

python 28484 root 3u ipv4 27225486  0t0  tcp 101.200.80.162:54724->103.37.145.167:http (established)
python 28484 root 4u ipv4 27225349  0t0  tcp 101.200.80.162:36583->120.132.34.62:https (established)
python 28484 root 5u ipv4 27225490  0t0  tcp 101.200.80.162:46128->42.236.125.104:http (established)
python 28484 root 6u ipv4 27225495  0t0  tcp 101.200.80.162:43162->222.240.172.228:http (established)
python 28484 root 7u ipv4 27225613  0t0  tcp 101.200.80.162:37977->116.211.167.193:http (established)
python 28484 root 8u ipv4 27225413  0t0  tcp 101.200.80.162:40688->106.75.67.54:http (established)
python 28484 root 9u ipv4 27225417  0t0  tcp 101.200.80.162:59575->61.244.111.116:http (established)
python 28484 root 10u ipv4 27225521  0t0  tcp 101.200.80.162:39199->218.246.0.222:http (established)
python 28484 root 11u ipv4 27225524  0t0  tcp 101.200.80.162:46204->220.181.105.184:http (established)
python 28484 root 12r chr  1,9  0t0 3871 /dev/urandom
python 28484 root 14u ipv4 27225420  0t0  tcp 101.200.80.162:42684->60.28.124.21:http (established)

让我们看看requests的连接池是如何实现的？ 通过代码很容易得出session()默认的连接数及连接池是如何构建的？ 下面是requests的长连接实现源码片段。如需要再详细的实现细节，那就自己分析吧

# xiaorui.cc

class session(sessionredirectmixin):

 def __init__(self):
  ...
  self.max_redirects = default_redirect_limit
  self.cookies = cookiejar_from_dict({})
  self.adapters = ordereddict()
  self.mount('https://', httpadapter()) # 如果没有单独配置adapter适配器，那么就临时配置一个小适配器
  self.mount('http://', httpadapter()) # 根据schema来分配不同的适配器adapter，上面是https，下面是http

  self.redirect_cache = recentlyusedcontainer(redirect_cache_size)


class httpadapter(baseadapter):

 def __init__(self, pool_connections=default_poolsize,
     pool_maxsize=default_poolsize, max_retries=default_retries,
     pool_block=default_poolblock):
  if max_retries == default_retries:
   self.max_retries = retry(0, read=false)
  else:
   self.max_retries = retry.from_int(max_retries)
  self.config = {}
  self.proxy_manager = {}

  super(httpadapter, self).__init__()

  self._pool_connections = pool_connections
  self._pool_maxsize = pool_maxsize
  self._pool_block = pool_block

  self.init_poolmanager(pool_connections, pool_maxsize, block=pool_block) # 连接池管理


default_poolblock = false #是否阻塞连接池
default_poolsize = 10 # 默认连接池
default_retries = 0 # 默认重试次数
default_pool_timeout = none # 超时时间

python requests连接池是借用urllib3.poolmanager来实现的。

每一个独立的(scheme, host, port)元祖使用同一个connection, (scheme, host, port)是从请求的url中解析分拆出来的。

 from .packages.urllib3.poolmanager import poolmanager, proxy_from_url 。

下面是 urllib3的一些精简源码， 可以看出他的连接池实现也是简单粗暴的。

# 解析url，分拆出scheme, host, port
def parse_url(url):
 """
 example::
  >>> parse_url('http://google.com/mail/')
  url(scheme='http', host='google.com', port=none, path='/mail/', ...)
  >>> parse_url('google.com:80')
  url(scheme=none, host='google.com', port=80, path=none, ...)
  >>> parse_url('/foo?bar')
  url(scheme=none, host=none, port=none, path='/foo', query='bar', ...)

 return url(scheme, auth, host, port, path, query, fragment)


# 获取匹配的长连接
def connection_from_url(self, url, pool_kwargs=none):
 u = parse_url(url)
 return self.connection_from_host(u.host, port=u.port, scheme=u.scheme, pool_kwargs=pool_kwargs)


# 获取匹配host的长连接
def connection_from_host(self, host, port=none, scheme='http', pool_kwargs=none):
 if scheme == "https":
  return super(proxymanager, self).connection_from_host(
   host, port, scheme, pool_kwargs=pool_kwargs)

 return super(proxymanager, self).connection_from_host(
  self.proxy.host, self.proxy.port, self.proxy.scheme, pool_kwargs=pool_kwargs)


# 根据url的三个指标获取连接
def connection_from_pool_key(self, pool_key, request_context=none):
 with self.pools.lock:
  pool = self.pools.get(pool_key)
  if pool:
   return pool

  scheme = request_context['scheme']
  host = request_context['host']
  port = request_context['port']
  pool = self._new_pool(scheme, host, port, request_context=request_context)
  self.pools[pool_key] = pool
 return pool


# 获取长连接的主入口
def urlopen(self, method, url, redirect=true, **kw):
 u = parse_url(url)
 conn = self.connection_from_host(u.host, port=u.port, scheme=u.scheme)

这里为止，python requests关于session连接类实现，说的算明白了。 但就requests和urllib3的连接池实现来说，还是有一些提升空间的。 但问题来了，单单靠着域名和端口会造成一些问题，至于造成什么样子的问题，我在上面已经有详细的描述了。

那么如何解决？

我们可以用 scheme + 主domain + host_ip + port 来实现长连接池的管理。

其实大多数的场景是无需这么细致的实现连接池的，但根据我们的测试的结果来看，在服务初期性能提升还是不小的。

这样既解决了域名ip轮询带来的连接重置问题，也解决了多级域名下不能共用连接的问题。

以上这篇构建高效的python requests长连接池详解就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持。