Comcast – simulating crappy network connections
I am staring at the t2.micro (the smallest available instance type) server running MySQL 5.5.40 (using the my-huge.cnf example configuration shipped with MySQL, which ironically matches t2.micro specs). Here’s why (as reported by Nagios for the last few hours):
Queries per second avg: 12888.839
The number is fluctuating between about 12,500 and 13,500. Server load is moving between 0.05 and 0.08.
I think this answers the question of whether or not I am happy with the Amazon EC2 instance performance with a “hell yeah!” bang.
I had a last work session last night, troubleshooting one of the project’s database performance issues. Without giving more details (at least for now), I want to save the link to MySQL view processing algorithms for future me.
UNDEFINED, MySQL chooses which algorithm to use. It prefers
TEMPTABLEif possible, because
MERGEis usually more efficient and because a view cannot be updatable if a temporary table is used.
A reason to choose
TEMPTABLEexplicitly is that locks can be released on underlying tables after the temporary table has been created and before it is used to finish processing the statement. This might result in quicker lock release than the
MERGEalgorithm so that other clients that use the view are not blocked as long.
A particular heavy query, using views, kept going into “Copying to tmp table” state, locking up the server and slowing everything to a crawl. Upon closer examination, the view was created without specifying the algorithm (UNDEFINED). Changing the view to use TEMPTABLE made everything so much faster.
I knew there were reasons for me being against using views in MySQL, but I could never remember them. This is one. Views not supporting indexes is another.
Over the last six years, I’ve become better at using Git for version control. But my conceptions of the index, the working copy, the object graph and remotes have just grown fuzzier.
Sometimes, I can only understand something by implementing it. So, I wrote Gitlet, my own version of Git. I pored over tutorials. I read articles about internals. I tried to understand how API commands work by reading the docs, then gave up and ran hundreds of experiments on repositories and rummaged throught the
.gitdirectory to figure out the results.
I discovered that, if approached from the inside out, Git is easy to understand. It is the product of simple ideas that, when combined, produce something very deep and beautiful.
Spoken like a true hacker. My hat is off to you, sir.