4 ms·

Hmmm... I'm curious about the async explanation. I don't think that's the main benefit. The main benefit, at least on other platforms, is that while your functi

Hmmm... I'm curious about the async explanation. I don't think that's the main benefit. The main benefit, at least on other platforms, is that while your function is await'n for your db, the thread can service other requests. It doesn't have to be stuck on waiting for I/O. This can dramatically improve scalability. I don't know, maybe PHP/hack doesn't really support this somehow.

toast0 9y ago
In a traditional PHP installation, the interpreter is single threaded, and you run multiple instances of them. If all the instances are waiting on I/O, you just run more instances until you run out of ram. If you're not linking in crazy c libraries, your php instances shouldn't get too big, so you can run a lot of them. (Ex: on my well traveled site at work, the biggest php takes up 24M, elastic search for maybe 1000 documents (documents 128M on disc) takes up 5G; I can run a lot of php for parallelism, if needed) I'm not sure if HHVM changed the threading model to run multiple requests simultaneously in one interpreter.
- kyberias 9y ago
  Right, it's just that the thread that is kept waiting for database could serve other clients meanwhile. While keeping the thread sleeping, it's wasting system resources. For example, ASP.NET has a small number of threads and each async call allows one thread to process another request.
  - toast0 9y ago
    That's true in a thread oriented environment; but it's not the case in a traditional PHP environment, with one OS process per client. A PHP process does not know how to context switch between many requests; if the process is waiting for I/O the OS will schedule a different process. In this model, sending multiple backend requests concurrently, regardless of how, is of value when it lowers the total request time and lets it accept another request sooner. You can send requests to the backend through async/await language features, or more simply by using apis that separate sending a request from waiting for a response, assuming network buffers are large enough to enqueue the request(s) without blocking.

toast0 9y ago

In a traditional PHP installation, the interpreter is single threaded, and you run multiple instances of them. If all the instances are waiting on I/O, you just run more instances until you run out of ram. If you're not linking in crazy c libraries, your php instances shouldn't get too big, so you can run a lot of them. (Ex: on my well traveled site at work, the biggest php takes up 24M, elastic search for maybe 1000 documents (documents 128M on disc) takes up 5G; I can run a lot of php for parallelism, if needed) I'm not sure if HHVM changed the threading model to run multiple requests simultaneously in one interpreter.

kyberias 9y ago
Right, it's just that the thread that is kept waiting for database could serve other clients meanwhile. While keeping the thread sleeping, it's wasting system resources. For example, ASP.NET has a small number of threads and each async call allows one thread to process another request.
- toast0 9y ago
  That's true in a thread oriented environment; but it's not the case in a traditional PHP environment, with one OS process per client. A PHP process does not know how to context switch between many requests; if the process is waiting for I/O the OS will schedule a different process. In this model, sending multiple backend requests concurrently, regardless of how, is of value when it lowers the total request time and lets it accept another request sooner. You can send requests to the backend through async/await language features, or more simply by using apis that separate sending a request from waiting for a response, assuming network buffers are large enough to enqueue the request(s) without blocking.