best way to reduce per ssl connection memory

  • Let's say I have servers - each with many GBs of memory - and I want very many keepalive https connections, and I'm not streaming and the largest request/response is, say, never bigger than the MTU… how can I get yassl to use less memory?

  • Todd Ouska
    Todd Ouska

    Are you using yaSSL or CyaSSL?  How much memory are seeing each connection use?  CyaSSL has been using 16k fixed size buffers for input and output.  But even at 50k you could get 2 connections per 100k, 20 per meg, 20,000 per gig.  You could save yourself 32k a connection by making those buffers dynamic if you really need to.  That would get you down to about 12k per or 80,000 per gig.  If you don't want session resumption or some other features you could probably get up to about 100,000 connections per gig without much work.

  • yaSSL appears to use a few KB per connection while CyaSSL is just over 40 KB-ish. We need session resumption. All our https requests and responses can be guaranteed to be under ~ 1500 bytes (MTU)… so can you please estimate what our target per-connection with session resumption dynamic memory will look like? Under 12 KB? :-)

  • Todd Ouska
    Todd Ouska

    Using CyaSSL with dynamic memory, without fastmath,  with session resumption, and removing HC128 will get you down to about 5KB per connection.

    Dynamic memory will save you 32KB.

    Removing HC128 (define NO_HC128) will save you about 8K because the Cipher structure is a union including HC128 by default which is over 4KB and there's an encrypt and decrypt structure.

    Not using fastmath will save you an additional 4KB though it sounds like you're already doing that.  The reason is each connection holds an RsaKey.  That could be made dynamic but we had a big push last year to remove all dynamic memory for embedded use. 

    Some of these things could be made into build options I guess.

  • It's great that you moved away from the dynamic memory model. There are so many advantages to not using dynamic memory. What I would welcome is a non-dynamic memory model where memory is pre-allocated for (a) maximum x concurrent socket connections (this is what we want to maximize the number of connected clients per server so that very many clients can be 'constantly' connected in order to minimize latency when they do want to send a query), and (b) maximum y sockets actually sending or receiving data, and (C) maximum z bytes of data would ever be sent or received (in my case this would likely be the same as the MTU size). Additionally it would be great to optimize away e.g. the copy between CyaSSL's read buffer and our read buffer e.g. with an alternative API. Do you see any problems with this approach?