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
```
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.
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.
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.