This piece of unwelcome information has made a big dent in CC’s user experience. And it’s even worse for us trying to work, write and edit in the back end, as the server actually favors the front page. But hopefully a solution is in sight.
First off: the problem is in our dedicated server (installed in 2013), which was a custom install to maximize its effectiveness in delivering a pretty demanding load: up to 30k page views per day, and content with huge amounts of large images (there’s over 100k images in our Media Library). This installation was done by our tech consultant, who also was available to make fixes. None had been required in the past couple of years, but there was no maintenance either.
When this current issue first came up, our consultant was not responding to my requests. So others have tried to dive in and fix the issue, including CC reader Warren, who spent quite a bit of time going though our WordPress site, to no avail, before realizing it was a deeper issue in the server.
But our tech consultant has finally responded to my entreaties; she’s extremely busy but has said she would oversee a migration to a new server, which is the necessary cure. And long-time CC contributor David Saunders wrote me to tell me he works in IT and has offered to assist. So the next step is making it happen, which may still be a bit of doing.
I offer my apologies for the unpleasant user experience. It’s like driving a car with two spark plug wires disconnected. I’m sick of it, and it has put me in a rather foul mood regarding the site. But we went through a similar period in 2013, and when we got on our new server, it was like getting a powerful new engine swap that ran perfectly. So we’re just going to have to limp along a bit longer.
Thanks for your patience and forbearance. And thank you to those that have made a donation to help offset the costs of the migration to a new server. It’s much appreciated. Update: I’m not begging for donations here, as we have a reserve from ad revenue to cover it, but I am expressing thanks to those that have/do chose to donate to the cause. And please, no donations from regular content contributors; you contribute plenty already. It’s what really keeps CC going.
SBC FTW!
I’m hitting the tip jar next…
SBC – so *that’s* why it’s shot in 5 years. 🙂
How does one donate? I’m not seeing it on the home page and don’t see CC on Patreon.
On the right side, just above the CC Archives. it may not be appear on the mobile reader version. You’d have to switch to regular view.
I’m not begging for donations, but that’s where it is if you feel so moved.
I used to spend $50+ annually, in 1970’s and ‘80’s money for printed car magazines. CC is worth a few bucks to me. It’s my pleasure.
Quietly and politely awaiting the much anticipated repair.
Thank you for not giving up on the problem and giving up on us Paul.
CC is a major part of my day!
+1. More compelling than Facebook. 🙂
+2!
What he said.
Ditto here!
Absolutely agree. Paul, this site is a huge part of my day, every day. I truly appreciate you and the other contributors for keeping it active. This site really has an impact on my life.
An enormous and heartfelt thank you to those whose knowledge is useful to helping this lovely place, especially those who’re doing it gratis on the technical front. Please know it’s time well-appreciated.
Paul, I’ve been a programmer for 35 years or so and architecting web-based systems for 20 years… and while I’d rather rub the back of my head with a cheese grater than deal with a WP site it seems to me that the traffic load you mention shouldn’t in any way strain a dedicated server (even one that is 10 years old, let alone something built in 2013). I suspect that you’re running a version of Apache that forks a process for every request so most likely you’re running low on memory as traffic increases (every incoming request causes the server to spin up a copy of itself to handle that request, then that copy goes away when the request is complete). Let’s say your Apache process is 100M and you have 5 images in a story and 20 comments. A single viewer hits the page and Apache forks to handle that request… you now have the master Apache process eating 100M and a fork also eating 100M (some is shared, but let’s ignore the intricacies of unix memory management for now). That fork serves the HTML and the client starts parsing the HTML and sees an IMG tag so it requests the image (while still getting the HTML)… spawn another Apache process to serve that image… 300M of memory in use. Rinse and repeat for the other 4 images, AND for all those avatars of commenters. For a single viewer loading a single page you could conceivably be eating 2.7G of memory (in reality it will be less because of max concurrent connections on the client, speed of transfer, etc). After serving all that the memory usage will return to 100M until the next request… except that you’re probably serving multiple viewers at any one time, so the Apache server is constantly cycling processes and you’ll average X processes at any one time. That X is too high for your hardware now.
Now what’s the easiest way to fix this? Stick an async HTTP server such as nginx in front of Apache that handles the serving of static files (like images) and only forwards dynamic content requests (your actual HTML pages generated by WP) to Apache, and preferably set that async server to cache such items for a reasonable amount of time.
That’s a bit over my pay grade, but I’ll make sure David Saunders sees this. He’s already diving into the server now.
We might end up down that road but I think there are a few “long hanging fruit” items to tweak first.