90 likes | 190 Views
CSE 434: Computer Networks Project. Single vs. Per Connection vs. Pooling Threading Techniques. Dominic Hilsbos, Dorothy Johnson, Chris Volpe, Andy Wong, Jack Zhao. What’s the Problem?. Under what circumstances is a single-threaded server more appropriate than a multi-threaded server?
E N D
CSE 434: Computer Networks Project Single vs. Per Connection vs. Pooling Threading Techniques Dominic Hilsbos, Dorothy Johnson, Chris Volpe, Andy Wong, Jack Zhao
What’s the Problem? • Under what circumstances is a single-threaded server more appropriate than a multi-threaded server? • Under what circumstances is thread-per-connection preferable to thread-pooling in a multi-threaded server? • What are the limitations of a thread-pooled server?
Motivation • Thread pooling is the most scalable of the three connection paradigms, and therefore would be ideal for most projects • We are interested in if and how to increase server efficiency • The motivation to comparing all three is that under specific requirements where scalabity isn’t an issue, single-threaded or thread-per-connection could be ideal
What's the difference? • Single Threading • one thread handles requests from multiple clients • Processing one connection must be completed before another connection can be considered • Ease of implementation • Single requests can be processed faster
What's the difference? • Multi Threading: Per Connection • Assigns one thread to listen to the port, then when a connection comes in a new thread is spawned to handle the connection for its entire lifespan • dedicates a new thread to each incoming and outgoing connection • Threads destroyed when the connection is closed • good if you need to serialize requests from a client, processing request must finish running before another request is taken from the connection
What’s the Difference • Multi Threading: Pooling • Like Per Connection, pooling dedicates a thread to listen to the port and marshal new connections • Thread-pooled connection handler places the new connection into a queue for a thread ‘pool’ • The size of the thread pool is configurable by user, able to set pool maximum and minimum • If the thread maximum has been reached then the connection must continue waiting on the queue • Once a threads is finished executing their activities, they are then returned to the thread pool
Our Test • For each server implementation we will test the following scenarios: • 5, 50, 500, 5,000 and 25,000 simulated clients • 1, 5, and 10 requests per connection • 100, 500 and 1,000 iterations of the busy loop.
The Results • We are still in the process of running all the test and have yet to come up with a solid conclusion