smacker

I'm not very well versed with CURL design too but afaik it does reuse connections but only inside the same process (e.g. downloading 10 files with 1 command). In this case it shouldn't be re-using them as I ran 2 different commands. I should have included TLS handshake time in the output, though. You can see it here (overall time is lower because I hit preview env that is slightly different from staging/prod):

First hit: ``` DNS Lookup: 0.026284s Connect (TCP): 0.036498s Time app connect (TLS): 0.059136s Start Transfer: 1.282819s Total: 1.282928s ```

Second hit: ``` DNS Lookup: 0.003575s Connect (TCP): 0.016697s Time app connect (TLS): 0.032679s Start Transfer: 0.242647s Total: 0.242733s ```

Metrics description:

time_namelookup: The time, in seconds, it took from the start until the name resolving was completed.

time_connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.

time_appconnect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed.

time_starttransfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.

It makes requests to API server that is deployed to k8s, which doesn't have a cold start. Clearly, some caching by the runtime and framework is involved here.

My point is that "cold start" is often more than just booting VM instance.

And I noticed not everybody understands it. I used to have conversations in which people argue that there is no difference in deploying web frontend to Cloudflare vs a stateful solution because of this confusing advertisement.

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.

absolutely. But when PG is running out of open connections or has already consumed all available CPU even the simplest query will struggle.

I like using postgres for everything, it lets me simplify infrastructure. But using it as a cache is a bit concerning in terms of reliability, in my opinion.

I have witnessed many incidents when DB was considerably degrading. However, thanks to the cache in redis/memcache, a large part of the requests could still be processed with minimal increase in latency. If I were serving cache from the same DB instance, I guess, it would cause cache degradation too when there are any problems with the DB.

thank you! Indeed, it is shown on a new tab in such case!

That is exactly a service I was hoping Cloudflare would provide. Simple binding using wrangler is really a life quality upgrade when starting new projects.

I tried it a few days ago, a privacy-focused Chrome that doesn't break browsing experience resonates with me. The team seems to care about quality and the browser felt good overall.

A few things that made me go back to Brave: - No vertical tabs - Sync with mobile - I haven't found how to show bookmarks bar only on blank page - Little customization for new tab page (might be fixable using extensions)

I'll definitely follow the project as Brave is far from perfect too.