3 ms·

You don't seem to understand the basics of how Java web containers work. The thread stack size is irrelevant in most cases. You're going to be using a thread po

You don't seem to understand the basics of how Java web containers work. The thread stack size is irrelevant in most cases. You're going to be using a thread pooled server anyway to handle requests. Conceptually this is no different than using a forked model. You just use a pool of threads instead of processes. Are you telling me that you run a process pool of thousands of PHP instances on a single machine? I hope not. Your notion that forked = better is outdated. Running processes has overhead, even with read only shared mem. Micro processes are the way to go, and are being embraced by newer languages. You get min mem and context switching overhead, along with the parallelization of running on multiple cores. Even so, threads are still going to be lighter weight than forking new "heavy weight" (non micro) processes. And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc

bernawil 7y ago
>Your notion that forked = better is outdated. You're beating a strawman here. Nowhere did I make the claim that it was better. I even said multithreading is more performant. The only claim I make is that immutable and shared nothing model of PHP servers makes horizontal scalling more straightforward. >You're going to be using a thread pooled server anyway to handle requests That doesn't take away the fact that n parallel requests will require n threads. >And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc I don't make any claims here either. Of course Java is faster here. My point was specifically about which model of concurrency and paralellism is better for server IO.
- codesushi42 7y ago
  >That doesn't take away the fact that n parallel requests will require n threads. What's your point? In PHP's model, n requests will take n processes. There's no event loop in PHP. The forked model has nothing to do with making scaling horizontally more straightforward. In either scenario, you'll end up running a different process on another machine once you exhaust your resources.

bernawil 7y ago

>Your notion that forked = better is outdated. You're beating a strawman here. Nowhere did I make the claim that it was better. I even said multithreading is more performant. The only claim I make is that immutable and shared nothing model of PHP servers makes horizontal scalling more straightforward. >You're going to be using a thread pooled server anyway to handle requests That doesn't take away the fact that n parallel requests will require n threads. >And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc I don't make any claims here either. Of course Java is faster here. My point was specifically about which model of concurrency and paralellism is better for server IO.

codesushi42 7y ago
>That doesn't take away the fact that n parallel requests will require n threads. What's your point? In PHP's model, n requests will take n processes. There's no event loop in PHP. The forked model has nothing to do with making scaling horizontally more straightforward. In either scenario, you'll end up running a different process on another machine once you exhaust your resources.