Adventures in Web Cache
Had a very interesting Saturday night resulting in a somewhat tummultuous Sunday morning.I got a wild hair thinking that all the cache modules I had enabled were unnecessary so I disabled them all. Initially all remained copacetic, and I believe this was due to that necessary marination which transpires between configuration changes.
 |
Well now, this was simply not satisfactory and I decided to do a run down of Saturday evening's festivities to see precisely where I went astray.
After perusing the shell history I determined that my initial thoughts regarding cache were pure folly and set about the task of making things right.
I re-enabled all the cache modules in the reverse order that I disabled them. There was no improvement in performance immediately.
Thinking that I'd really screwed up I did a reboot of the server and tried again. Continued lack of improvement.
Finally I recalled my thoughts regarding the need to marinate between configuration changes and I set about the task of requesting various pages through the blog.
Finally, I noticed improvement with everything returning to it's original performance shortly thereafter. This same scenario was to be repeated later upon my visit to Mom where I discovered pretty much the same issues which were tested repeatedly. Two reboots later and everything is again up to snuff.
The moral of the story is "if it ain't broke, you may not want to try and fix it". Also, "it is far better to retain something you may not need than it is to delete something required in the mix". Things in the background like caching are not line of site nor assets which may be switched on and off on a whim. There are interrelationships between components which must establish pathways after the fact. I obviously removed components which were decidedly performance related resulting in detrimental effects on the web server.
This was quite the valuable lesson as I will be very cautious regarding configuration changes on the fly in the future.