Some fragments:
The early Web servers were obscured by the short HTTP links, because Web pages and embedded images were generally small (at least as much as they would normally get from FTP), because the Web browser hangs the connection after acquiring each file, rather than keeping the sister for a few minutes or hours at a time, So web users do not impose too much burden on the server as FTP users do, but as usage grows, Web server performance degrades (there are at least two solutions to this problem)
The first: the reuse process instead of creating a new process, the server starts, creates a fixed number of processes (such as 300) to process the request, the incoming stack request is placed in a queue, and each process removes a request from the queue and serves the request. This benefit avoids all the overhead of building and destroying the process.
The second is to use a lightweight thread to handle the link, although each individual process has its own piece of memory, but the thread is easier to use on the resource because they share memory. Use thread pool to increase request processing;
(thread substitution method) when one of our application colleagues needs thousands of long-lasting links, consider the asynchronous I/O instead of the thread, and the option allows a thread to query a set of sockets to find out which sockety are ready to read and write data, which is based on the channel and buffer design i/ o rather than stream. However, the decomposition will give the corresponding design problems, the special preparation is in the consistency. Added to the complexity of the program, different threads must be very careful about the resources that were used at the time. In general, each thread will only be able to use a resource if it is ensured that the resource does not change or he has exclusive access, but two threads are too careful, and each thread waits for exclusive access to the resource, but never, which results in a deadlock.
Java Network Programming (reading notes)