3 ms·
Your high level buckets are languages but the constraints you list are usage patterns. You can build applications in any language that have many short-lived tr
by tyre 2mo ago
Your high level buckets are languages but the constraints you list are usage patterns.
You can build applications in any language that have many short-lived transactions in single connections or a few huge, blocking one, or anything in between.
The former case is a good one for PGBouncer (it can interleave transactions) and the latter isn’t (it can’t do much about your three minute long BEGIN…COMMIT). Neither has to do with the language.
- atomicnumber3 2mo agoThey addressed this though? I suspect you are unfamiliar with the GIL in python. The reason for a language distinction is because, as OP says: "As it's much easier to share a connection pool locally". This may change vaguely soon, but right now you typically scale python apps by starting multiple python processes, while for Java you can just add threads. Python processes can't share a thread pool among all of them, while Java can.
- tyre 2mo ago> I suspect you are unfamiliar with the GIL in python. Sadly, I’m deeply familiar. What made Evan Phoenix’s Rubinius work so exciting in ~2012 was getting rid of the GIL and seeing what was “fixed” by parallelism and what was not. You make a good point. I didn’t read the parent comment that way but you’re right about how you scale python with the GIL vs JVM.
- ketozhang 2mo agoYou've misunderstood the GIL and Python threads. For I/O, you can add threads and share the same connection object. Like any other languages, you are responsible for making it thread-safe. There's also async. Many Python web apps spawn a thread per worker in your web server, not processes. Look into ASGI vs WSGI.
- pocksuppet 2mo agoLanguages have affordances. At the extreme ends are PHP, and Java or Go. PHP runs a separate logical process on every request which can't share resources with any other request. Almost everyone using Go is writing a long-running server process because that's how the libraries are designed. Almost everyone using Java is writing a long-running process or a module for one, because Java startup times are obscene. Java also has a very convenient synchronization primitive.
- mike_hearn 2mo agoMulti-threaded processes are used because that's the most efficient model, hardware wise. Tasks can maximally share resources. It's not to do with library design or startup time.
- pocksuppet 2mo agoThe hardware doesn't know anything about processes. The most efficient model, hardware-wise, is to disable virtual memory and never do a context switch, but we don't see anyone programming like that, except for the crazy SDN folks who are doing software packet forwarding at hundred-gigabit rates.
- mike_hearn 2mo agoWell, a server running a single process is fairly close to that. Switching to kernel mode doesn't require a full context switch and nor does switching between threads.
- tredre3 2mo ago> PHP runs a separate logical process on every request which can't share resources with any other request. PHP allows persistent connections to postgres that will be reused by subsequent requests. But of course the connection isn't shared by concurrent requests (unless you use Swoole), so it doesn't solve the process-per-connection on postgres' side, it merely saves some overhead.