3 ms·
> Temporary files/shared memory won’t solve the cost of starting up a Python interpreter or a JVM or whatever and importing all your code with its dependencies.
by 10000truths 4y ago
> Temporary files/shared memory won’t solve the cost of starting up a Python interpreter or a JVM or whatever and importing all your code with its dependencies.
This is true, CGI is sensitive to startup latency. It can be addressed with pre-forking, but doing so bears the consequence of increased memory usage at idle workloads.
> As for the connection pooling daemon, you still need to connect to it. It might be faster than talking to the database directly on a different server, but no new connection still beats new local connection.
It’s a nothingburger. A connection pool’s bottleneck is in the TCP connection to the database. A UNIX socket has orders of magnitude less latency (a couple μs) and supports orders of magnitude more throughput (a few GBs/sec). Compared to spawning new processes running interpreters, it’s noise.
- naniwaduni 4y agoSome context: in 2017, I found by informal testing that I could run (just on a dev laptop) about about 180 lua no-op programs per second, 140 perl5, 35 py2, 30 py3, 15 node, 12 ruby; /usr/bin/true, as a benchmark, a bit over 500 Hz. Doesn't necessarily extrapolate back another 20 years, but perhaps sheds some light on how "slow" CGI would've been.