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)
Zabbix to BigPanda Webhook Integration
Background BigPanda has made its way into the organization. I wasn't sure at first why, given that there's no shortage of Network Mo...
-
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...
-
On this post, I wanted to remark about a package called etcd. In most installation documents for Kubernetes, these documents tend to abstr...
No comments:
Post a Comment