Closed HoneyryderChuck closed 7 years ago
I believe the instance lookup is more efficient and uses much less memory.
Otherwise FFI is creating a new C-Function callback for each callback which I've found limits the number of concurrent connections and I need 1000's - I'm not 100% on the internals of FFI however I've hit weird memory limits (around 400mb pure FFI usage) that are independent of ruby's heap which can grow much larger.
Also on JRuby the current method is more likely to be JIT'd as the code path is hot versus an independent code path per connection
Fair enough, I was afraid something like that could be the issue. Thx for the heads up!
I've seen the pattern of defining the SSL callbacks in a static variable (ex:
VerifyCB
). From what I see, this has one downside: since it's defined globally, one loses the local scope. And probably this is the reason why concurrent-ruby is a dependency (to rely on theConcurrent::Map
), which has the downside of adding another level of lock contention.One could instead define the callbacks as normal methods, and just pass them as callbacks. Here's an example I've tested locally:
The current solution has one advantage though: it limits the number of
FFI::Function
allocations. It does so, however, at the cost of adding extra locking and adding one quite big dependency for a small feature (concurrent-ruby). But if that particular advantage was the reason you decided to go with it, you can ignore this request (both solutions involve a trade-off, question is, which one to live with).