Per results of https://github.com/mozilla-services/push-service/issues/76, our support libraries (boto, gcmclient) use the ssl module's top level wrap_socket func which unnecessarily creates an SSLContext per connection. pypy's GC doesn't appear to keep up w/ all of them: in one scenario we see half of a 3gb heap taken by boto's SSLContext remnants.
SSLContext's aren't cheap depending on their loaded cert store. E.g. the mozilla cert store shipped w/ ubuntu 17.04 is 632k
pypy should better handle this (there's probably a bug here) but libraries shouldn't follow this anti- pattern either. They should create one SSLContext and call its wrap_socket method instead. The hyper lib (used by our apns2) does the right thing: allows passing in a custom SSLContext otherwise defaulting its own singleton
In the meantime we can workaround this with a monkey patch to ssl.wrap_socket that caches contexts.
Per results of https://github.com/mozilla-services/push-service/issues/76, our support libraries (boto, gcmclient) use the ssl module's top level wrap_socket func which unnecessarily creates an SSLContext per connection. pypy's GC doesn't appear to keep up w/ all of them: in one scenario we see half of a 3gb heap taken by boto's SSLContext remnants.
SSLContext's aren't cheap depending on their loaded cert store. E.g. the mozilla cert store shipped w/ ubuntu 17.04 is 632k
pypy should better handle this (there's probably a bug here) but libraries shouldn't follow this anti- pattern either. They should create one SSLContext and call its wrap_socket method instead. The hyper lib (used by our apns2) does the right thing: allows passing in a custom SSLContext otherwise defaulting its own singleton
In the meantime we can workaround this with a monkey patch to ssl.wrap_socket that caches contexts.