In NIO Selectors, a single thread can handle multiple sockets IO read\write operations,instead of the old 'thread per connection' paradigm.Still,the *processing* of the request (not its IO) is probably an issue for thread per request.

The question is:

since a processing of a request will start only when the selector thread will get (in its inner loop) to the peer socket ,how many sockets IO operations can be served concurrently by a selector thread without harming the perfomance ? for example ,what if the index of the request in the loop is '1000' , does '1000' IO operations before starting processing the request is OK ?

When using NIO in the selector thread you would
read the request and queue it. The request would be read and served by a pooled thread, so no serving of requests in the selector thread.

The major difference between NIO and multithreaded server is finite number of processing threads (NIO) versus one thread per client (multithreaded), so less resources allocated in NIO architectures.

It's slightly off-topic (doesn't address your question) but still related with nio performance so it wouldn't hurt to read this forum:

http://forum.java.sun.com/thread.jsp?thread=303899&forum=4&message=2020650

before deciding whether to use java.nio or not. I mean - it was definately a(n unpleasant) surprise for me.