Improve Tuning page; add ToC.

TUNING.md

@@ -1,4 +1,4 @@
-## TUNING
+# PERFORMANCE TUNING
 
 This guide is intended for system administrators to optimize Construct and
 maximize its performance for their environment. This does not cover [BUILD](BUILD.md)
@@ -20,13 +20,19 @@ ERRORS MAY ALSO PREVENT STARTUP. Please see the
 [TROUBLESHOOTING](TROUBLESHOOTING.md#recovering-from-broken-configurations)
 guide for how to recover from configuration errors.
 
+##### Table of Contents
+
+- [Event Cache Memory Locking](#Event-Cache-Memory-Locking)
+- [Event Cache Size](#Event-Cache-Size)
+- [Client Pool Size](#Client-Pool-Size)
+
 ### Event Cache Memory Locking
 
 On Linux systems (or systems which support `mlock2(2)`) Construct has a feature which can prevent swapping of event caches by locking them into RAM. To enable this feature, the resource limit for locked memory must be set to `unlimited`. This can be achieved by running `ulimit -l unlimited` before executing. Note that _any_ limit on locked memory (even if larger than the cache sizes) will disable this feature.
 
 > A page-fault for swapped data will block the entire server until the data is read back into RAM. This is inferior to Construct's normal operation which reads data from the disk asynchronously without blocking. There is never a good reason to swap cache data; it is always better to simply drop it. In the future, Construct will support trimming caches under high memory pressure as reported by Linux Pressure-Stall-Information.
 
-### Event Cache Size Tuning
+### Event Cache Size
 
 Most of Construct's runtime footprint in RAM consists of a cache of Matrix
 events read from the database. The data in many of these events may be
@@ -97,6 +103,6 @@ value is several times higher than the cache size and growing, consider
 increasing that cache's size.
 
 
-### Client Pool Tuning
+### Client Pool Size
 
 (TODO)