[HN Gopher] Eliminating Cold Starts 2: shard and conquer
       ___________________________________________________________________
        
       Eliminating Cold Starts 2: shard and conquer
        
       Author : cmsparks
       Score  : 57 points
       Date   : 2025-09-26 21:40 UTC (3 days ago)
        
 (HTM) web link (blog.cloudflare.com)
 (TXT) w3m dump (blog.cloudflare.com)
        
       | bluelightning2k wrote:
       | I love Cloudflare engineering writeups & the workers platform
        
         | jtbaker wrote:
         | Same. Really wish they had a managed k8s offering to complement
         | it though. Some workloads just don't fit into the workers
         | paradigm.
        
           | arcfour wrote:
           | Containers+Workers is now a thing, at least.
           | 
           | It's very much still maturing as an offering. But it does
           | exist!
        
             | jtbaker wrote:
             | Yeah, I've tinkered with it when it first rolled out. The
             | dev experience and performance left a lot to be desired.
             | Poor visibility on the status of containers, weird phantom
             | bugs, having to learn new platform idiosyncrasies. Just
             | embrace k8s. Just roll it up into a wrapper that runs on
             | GCP or whatever under the hood that would allow people that
             | need more control over the infra to adopt the platform.
        
       | Havoc wrote:
       | Surprised none of the big clouds have duplicated the handshake
       | delay thing yet - CF is noticeably better at cold starts than the
       | rest for small scripts. I guess the big cloud functions are aimed
       | at bigger workloads perhaps
        
         | no_wizard wrote:
         | I never understood this either, even if due to constraints it
         | has to be a different product line.
         | 
         | I thought lamda@edge was going in this direction but it's a
         | slightly faster, more constrained version of lambdas with all
         | the same potential downsides
        
       | smacker wrote:
       | While I really appreciate Workers platform "eleminated cold
       | starts" advertising was always bothering me.
       | 
       | This is a curl request from my machine right now to SSR react app
       | hosted on CF Worker: ``` DNS lookup: 0.296826s Connect: 0.320031s
       | Start transfer: 2.710684s Total: 2.710969s ```
       | 
       | Second request: ``` DNS lookup: 0.002970s Connect: 0.015917s
       | Start transfer: 0.176399s Total: 0.176621s ```
       | 
       | 2.5 seconds difference.
        
         | omk wrote:
         | I'm not well versed with CURL design, but curious - is your
         | first connection handling TLS while second relying on the
         | previously established handshake?
        
           | swiftcoder wrote:
           | TLS handshakes (outside of embedded hardware) should be
           | measured in milliseconds, not seconds
           | 
           | Edit: you can kind of tell this from the connect timings
           | listed above. TLS is faster the second time around, but not
           | enough to make much difference to the overall speedup
        
             | scottlamb wrote:
             | I think you're right that TLS doesn't explain the
             | difference shown above, but for completeness: TLS 1.3 can
             | reduce the round trips from 3 to 2 on session resumption.
             | [1] Depending on your Internet connection, that could be a
             | lot more than milliseconds. I don't think `curl` uses it by
             | default though.
             | 
             | [1] https://blog.cloudflare.com/introducing-0-rtt/
        
         | kentonv wrote:
         | Does this app make any network requests that might have their
         | own cold start or caching effects?
         | 
         | 2.5 seconds seems way too long to be attributed to the Worker
         | cold start alone.
        
         | samschooler wrote:
         | I would say Cloudflare "eliminated cold starts" in the context
         | of bringing the server online, not in the form of rendering +
         | caching the SSR page.
        
       | candiddevmike wrote:
       | Maybe a hot take, but if you're that concerned about cold starts,
       | you probably shouldn't use a service that scales to zero. If your
       | service is really not used that heavily, it's like $5-10/month
       | for an instance that can handle more than your traffic needs
       | 24/7, hell you can even host other similarly unused services on
       | it!
        
         | stackskipton wrote:
         | Because attractiveness of Workers/Lambdas/Functions is whole
         | "write simple amount of code and pay pennies to run it."
         | Downside is cold starts, twisting yourself into knots you will
         | do at scale to make them work and vendor lock in.
         | 
         | If you start to say "If you are using this for production,
         | 5-10/month is real cost you need to pay + transactions" Well,
         | now the cost is about to same to deploy fly.io shared CPU
         | container and it does not come with cold starts, vendor lock in
         | and can run as long as you want. Cloudflare knows that so they
         | don't want to introduce that charge or even talk about it.
        
       ___________________________________________________________________
       (page generated 2025-09-29 23:02 UTC)