Thoughts about this server ... (Experimental) Four Calorie HTTP Server


As of v3.0.7, the server is still a fairly low volume server, capable of only 20 pages per second or so. Future design changes should improve that figure considerably.


The initial aim of the project was to create as simple a server as possible and still maintain some reasonable level of functionality.


Once again, simple is not always fast, quick, or capable of scaling tall buildings in a single leap. But, initially, it is good because it helps one to find potential trouble spots more readily.





The simple design of the server at this point plugs the received queries directly into the pthread pool for processing. Since, the pthread pool is limited by memory (the thread stack plus dynamic allocations for each thread are not trivial), only a finite number of threads (currently 100) within it can be utilized at any particular instance in time. When the thread pool is exhausted, some requests have to wait until threads are available.


The direct-to-processing-thread-queue design means that "bursts" of traffic may not be well accommodated if a particular burst last long enough to exhaust the thread queue. As a means of creating higher throughput, a modification may be made that incorporates an input queue many times larger than the thread queue. Such an input queue could accommodate "burst" traffic of perhaps thousands of connections. The current code base would receive some minor performance benefit from such an arrangement due to the way the queue could be very speedily populated.





At some point, you have to admit that you just can't have your cake and eat it too. Higher simultaneous requests-processing-power just requires the addition of more simultaneously available threads. To this end, a future enhancement may be to make the thread pool dynamic, and create a dynamic pool size that is reasonable relative to the resources of the machine that it is running on. v3.07 already does this to some limited extent, in an indirect fashion.