At 11:23 AM 9/5/2003, Maarten Bekers wrote: >> >To prevent an DoS, perhaps WaitForSingleObject() could be called in a >loop >> >with, check the value of GetOverLappedResult() for a 'sane' value (this >can >> >be the old MAX_SEGMENT_SIZE), and if the amount of bytes transmitted >since >> >the last call to GetOverlappedResult() is smaller than MAX_SEGMENT_SIZE, >> >abort the loop and fall out of the sendfile() as the user is not >receiving >> >(quickly) enough. >> >> I was under the impression that until an overlapped operation COMPLETES, >> GetOverlappedResult doesn't give us anything useful in return other than >> ERROR_IO_PENDING. Was I misunderstanding the semantics? >Unfortunately you seem to be right. An early test led me to believe that >GetOverlappedResult() reacted as i expected, but this test was apparently >very wrong as i am unable to reproduce that behaviour now. I will test more >and see if i can find anything that improves performance without introducing >this issue. What did strike me as odd is that an quick test resulted in >this: > >- IIS - 6M/sec >- Apache - 0.9M/sec >- Apache with SendFile disabled in httpd.conf - 6M/sec > >which striked me as odd.
Most odd :-) But I had another question... I have some concerns about the APR_XTHREAD files (those opened for overlapped I/O) behaving correctly when we start to use those in normal operation - had you verified that these are actually going to apr_sendfile, or do you have intervening read/transforms going on due to mod_includes or other scripts? Note, too, that TransmitFile has several interesting options in re the 'mode' of transmission (kernel v.s. apc's etc). It might be very interesting to try flipping those options and see which actually affect performance in the rather clean environment you have already configured. Of course, you could try 256K, 1M etc as the split-size and see if the transmission speed converges twords 6M. Bill
