-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The C10k Plan #9
Comments
instead of opening a file for each request... But : |
Hmm, that would be interesting for smaller files actually. Basically caching them in memory. Maybe with some sort of file access threshold being passed it would store it in memory ( assuming it's not huge ). Interesting Idea. Edit: Seems like the case of adding something to the cache will require synchronization ... my mutex lives!! xD |
Caching files is likely to be counter productive. The OS filesystem cache has better domain knowledge than you have available. Whatever nanoseconds gained in caching in ram would be wiped out in consistency checks and flushing operations. |
@arwyn Ah yeah, that's true. Well then, less work for me. :) |
@arwyn the only way to verify these assertions is to perform some benchmarks... Disk Access are VERY VERY costly... It will be very interesting to compare serving static content from RAM and compare the results with content serving from the filesystem. Maybe it's possible to develop a quick and dirty test by placing static data in the code (3 gifs and 3 html files). But you're true... It's difficult to have a good cache strategy... There is cache in so many levels (CPU, Disk controller, OS) An interesting reading about kernel cache strategies: @nemasu Have you identified where are the bottlenecks in the current code ? |
@smougel Thanks for the input and info. Yes, it's currently limited by I/O and thread count. Because it's a 1 to 1 relationship right now, 1 connection = 1 thread. The current plan looks really promising though, I'm looking forward to implementing it. :) I ditched select for poll, because select is ancient and terrible. Side note: I just did a benchmark with version 0.1, 10k successful transfers in 15 seconds using 10 concurrent connections with no failures. Also it was in a VM and I left thread count at 10 ( this ones tricky to tweak because it's on a VM at the moment ). Not too bad for a non async implementation. Even as it stands it might be useful with it being only a 5.5 KB library-less binary. |
@dariolah Thanks for that link, it was a very interesting read. I think the possibility is high I will try that at some point. That being said, c10k as a stepping stone needs to be accomplished anyways, but after that I will be thinking about implementing some of those designs. |
My current plan for handling 10k+ connections, will edit as it's improved.
Comments are welcome :)
Idea: Don't block on anything until it's ready. When waiting for I/O, accept more connections.
+Asynchronous I/O.
+Non-blocking sockets.
+Multi-threaded.
+Self contained threads.
+Single thread can handle multiple connections, more threads = more connections
+Only one thread design needed
+No synchronization of threads needed
+Self load balancing threads. ie. Threads with more free cycles will call accept more often.
-/+ One connection will use about 10 KB of memory.
-More complicated (but more awesome too).
-Will likely be a tad slower on many small requests.
struct Data = socket fd, file fd, send_offset, length, 8KB buf(recv, path, url) =
8 + 8 + 8 + 8 + 8192 + 104 + 2000 = 10328 bytes
Storing pointer to struct in epoll user data, no need for extra data structure.
worker-thread pseudocode
The text was updated successfully, but these errors were encountered: