Fair enough. I was actually thinking about the request connection overhead - I used to run Kaspersky as my AV (not recommended for developers!) and it would additionally vet all connections.
Cheers for the info, Chris. On 13 March 2010 17:15, Oleg Kalnichevski <[email protected]> wrote: > Chris Lowe wrote: >> >> Nice work - I wonder what's going on with the Jetty NIO on Linux. >> > > I know little about Jetty so it can well be it has not been configured in > the best possible way. Optimizations are very welcome. > > >> Out of curiosity - was there an AV product running at the time of the >> Windows test? >> > > I had Windows Defender set to off and no other AV running. It should not > matter that much as the test case should perform no file system bound I/O > (beyond normal class loading) > > Oleg > >> On 13 March 2010 16:59, Oleg Kalnichevski <[email protected]> wrote: >>> >>> Ken Krugler wrote: >>>> >>>> Hi Todor, >>>> >>> ... >>> >>>> I was hoping it might be related to nio vs. threaded approaches to HTTP >>>> handling. >>>> >>>> There's been a lot of debate about the value (performance, simplicity, >>>> resource consumption) but I haven't seen much head-to-head comparison >>>> where >>>> the rest of the implementation is roughly comparable. If you ever get >>>> any >>>> comparison numbers, I'd love to see them. >>>> >>>> -- Ken >>>> >>> I have made a number of tests comparing HttpCore blocking vs HttpCore NIO >>> vs >>> Jetty blocking vs Jetty NIO. The results and the link to the source code >>> can >>> be found here: >>> >>> http://wiki.apache.org/HttpComponents/HttpCoreBenchmark >>> >>> Oleg >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
