If you're wondering when to use TCP_QUICKACK, I think it's completely orthogonal to NODELAY on Linux: the kernel will disable QUICKACK based on some heuristic, so setting it once won't necessarily do what you want.
I think it makes sense when you expect to receive large payloads though: faster acks let the sender queue up new packets faster. This might be hard to observe in readiness-based async servers because reasonable buffer sizes are small, so throughput tends to see-saw, but I've observed the impact on blocking recv (and if you only use non-blocking sockets for timeouts, SO_SNDTIMEO/SO_RCVTIMEO now make sense on Linux [i.e., they apply to each syscall, not each blocking step in the syscall's internal loop]).
@pkhuong Heh, I've seen real code (for some definition of real) that called setsockopt with TCP_QUICKACK after every recv. That surely can't be intended.
@pervognsen That's kind of how it goes :| IIUC, the heuristic tries to detect request/response patterns (like telnet... the root of all TCP weirdness), so you should only need it between send and recv?