Google Cloud Storage api performance regressions

Question

У меня есть приложение python 3.5, которое делает звонки в Google Cloud Storage с помощью python sdk.

Время от времени, в течение 10-30 минут, все вызовы API завершаются с ошибками BrokenPipeError или ssl.SSLError. Через какое-то время они снова начинают работать, я не заметил шаблона, почему.

Это известная проблема? Является ли он специфичным для sdk python или это реальная регрессия производительности на стороне google?

Следует также отметить, что эти ошибки будут исходить из того же кода, что и на моем локальном компьютере, а также на машине GCE.

Трассировка для BrokenPipe:

Traceback (most recent call last): 
    File "oauth2client/util.py", line 140, in positional_wrapper 
       return wrapped(*args, **kwargs) 
    File "googleapiclient/http.py", line 722, in execute 
            body=self.body, headers=self.headers) 
    File "oauth2client/client.py", line 596, in new_request 
              redirections, connection_type) 
    File "httplib2/__init__.py", line 1314, in request 
         (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey) 
    File "httplib2/__init__.py", line 1064, in _request 
      (response, content) = self._conn_request(conn, request_uri, method, body, headers) 
    File "httplib2/__init__.py", line 988, in _conn_request 
        conn.request(method, request_uri, body, headers) 
    File "/usr/lib/python3.5/http/client.py", line 1083, in request 
      self._send_request(method, url, body, headers) 
    File "/usr/lib/python3.5/http/client.py", line 1128, in _send_request 
      self.endheaders(body) 
    File "/usr/lib/python3.5/http/client.py", line 1079, in endheaders 
      self._send_output(message_body) 
    File "/usr/lib/python3.5/http/client.py", line 911, in _send_output 
      self.send(msg) 
    File "/usr/lib/python3.5/http/client.py", line 885, in send 
       self.sock.sendall(data) 
    File "/usr/lib/python3.5/ssl.py", line 886, in sendall 
        v = self.send(data[count:]) 
    File "/usr/lib/python3.5/ssl.py", line 856, in send 
       return self._sslobj.write(data) 
    File "/usr/lib/python3.5/ssl.py", line 581, in write 
      return self._sslobj.write(data) 
BrokenPipeError[Errno 32] Broken pipe 

Трассировка для ssl.SSLError:

File "oauth2client/util.py", line 140, in positional_wrapper 
       return wrapped(*args, **kwargs) 
    File "googleapiclient/http.py", line 722, in execute 
            body=self.body, headers=self.headers) 
    File "oauth2client/client.py", line 596, in new_request 
              redirections, connection_type) 
    File "httplib2/__init__.py", line 1314, in request 
         (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey) 
    File "httplib2/__init__.py", line 1064, in _request 
      (response, content) = self._conn_request(conn, request_uri, method, body, headers) 
    File "httplib2/__init__.py", line 1017, in _conn_request 
        response = conn.getresponse() 
    File "/usr/lib/python3.5/http/client.py", line 1174, in getresponse 
        response.begin() 
    File "/usr/lib/python3.5/http/client.py", line 282, in begin 
       version, status, reason = self._read_status() 
    File "/usr/lib/python3.5/http/client.py", line 243, in _read_status 
      line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") 
    File "/usr/lib/python3.5/socket.py", line 575, in readinto 
        return self._sock.recv_into(b) 
    File "/usr/lib/python3.5/ssl.py", line 924, in recv_into 
       return self.read(nbytes, buffer) 
    File "/usr/lib/python3.5/ssl.py", line 786, in read 
       return self._sslobj.read(len, buffer) 
    File "/usr/lib/python3.5/ssl.py", line 570, in read 
       v = self._sslobj.read(len, buffer) 
ssl.SSLError[SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac (_ssl.c:1974) 

Answer 1

Определенно выглядит как прерывистый вопрос о Googles стороне. Проблема сломанной трубы связана с тем, что httpclient2 не может повторно подключить существующее соединение к их API, это ошибка, которая оказывает наибольшее влияние на наши сервисы. Мы также несколько раз получали «503 Backend Error».

Наше «решение» заключалось в том, чтобы в основном позволить соединениям закрыться, выпустив клиент после его создания и создав новый для следующего запроса.

Услышав, что наши запросы очень разреженные, службы, использующие Cloud Storage в качестве основного хранилища, вероятно, хотят, чтобы соединения открывались как можно дольше.