Here's some of what went down:
- Tim told us about the fundamentals of measurement based on his previous experience in the construction industry. Each worker's tape measure has to be calibrated with the foreman's tape measure. "Mine is bigger than yours" doesn't apply when real men build real buildings. This great example helped everyone understand that all measured numbers are wrong, by definition. Performance instrumentation is just a bunch of "tape measures" in software.
- Kevin and Tad talked about a distributed framework they're developing based on an asynchronous programming paradigm due to Tony Hoare. Nodes in this framework have buffers. Since all computer systems can be abstracted as a network of queues and a buffer is a queue, predicting the performance and capacity requirements of their architecture is a natural for analysis with PDQ.
- Manju showed us some of his JMeter load-test data and we discussed how to parameterize it for scalability analysis with the USL regression model.
- Joshua grappled with how to apply the available metrics in an SQL Server database to capacity planning. We discussed an initial PDQ model involving four concurrent streams: select, insert, update and delete, to get him comfortable writing PDQ in python (his preferred language). I also concluded that there might be some misconfigured parameters in the RDBMS that are artificially throttling the observed performance. Function first is the watchword here. Once functionality is established, then we can examine performance.
- Tad discovered an interesting problem with a couple of the homework problems. He found that his manual calculations did not agree with his PDQ models in R. After breaking out in a mild sweat, I eventually realized that PDQ is correct, afterall. The paradox arose because the input parameters for those exercises (which I stole wholesale from Arnold Allen's otherwise excellent book) do not correspond to the steady-state solution, which PDQ calculates automatically.
No comments:
Post a Comment