Today the QA team told me they had selected a tool called TCPKali (but weren't wed to it). They wanted me to download it, compile it, and try it out, as they thought they would use this to test connection scaling from clients running our product.
So I did this yesterday evening. It requires a number of kernel parameters to be changed so you can actually scale. This took me down a deep road of TCP State Transition and TIME WAIT. Rather than just blindly change kernel parameters, I read a couple of good articles on this:
http://developerweb.net/viewtopic.php?id=2941
http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html
Okay...now I know why I am changing the reuse and recycle parms on TIME WAIT.
I actuallly tested this by setting up a Lighttpd web server and using the man page examples. I was thinking Lighttpd would be closing the socket connections down and going into TIME WAIT state but in my testing I saw that the client (TCPKali) was actually racking up sockets in this state until I set those kernel parms which kept that number down to a lower number.
Intelligence = Applied Curiosity with a coefficient of how fast that curiosity is applied and satisfied.
Thursday, April 12, 2018
Subscribe to:
Post Comments (Atom)
Fixing Clustering and Disk Issues on an N+1 Morpheus CMP Cluster
I had performed an upgrade on Morpheus which I thought was fairly successful. I had some issues doing this upgrade on CentOS 7 because it wa...
-
After finishing up my last project, I was asked to reverse engineer a bunch of work a departing developer had done on Kubernetes. Immediat...
-
Initially, I started to follow some instructions on installing Kubernetes that someone sent to me in an email. I had trouble with those, s...
-
I spent some time researching and using NetFlow this week (about a day). Basically, you download the nfdump package, which has the collect...
No comments:
Post a Comment