Yes, I’m aware that since I upgraded to MT 3.32, stuff here has been slooooow. Just like you, I’m getting comments that time out (System Error 500), or just take forever to happen. Typekey authentication may be part of it (it’s been kind of wonky — or it may be the other way around). Or it may be that there are template file problems I need to clean up (my templates are still largely coded from several MT releases back, and I know from having done work on BD’s blog that the template language
has been much cleaned up since then).
I know that BD’s page is running pretty well, so it’s not my MT installation per se, nor my host. I can (in the meantime) reduce the number of entries on the first page (bumped up considerably, from 30 to 60, when I was doing the Blogathon), to see if that helps (the front page has to be rebuilt when new comments are made, so there is at least some impact).
So, things to do, probably this weekend (ha).
- Upgrade to MT 3.33 (per yesterday’s announcement). That’s not oriented around performance issues, but it needs to be done anyway.
- Create new individual archive page templates, per current standards. See if that helps.
- Put in the text CAPTCHA stuff I’ve done on BoH and BD’s blog, so that folks can bypass that authentication here if desired.
And we’ll see how that does.
UPDATE: Well, reducing the post count on the front page didn’t speed up the comment process. Ah, well.
Here’s a question: Awhile back (with the release of 3.0 I believe) Six Apart added in the ability to have rebuilds run as a kind of background task which aided greatly in the reduction of the amount of time it took to post comments. Did you ever enable that feature?
I wasn’t sure, so I looked up the value to set (“LaunchBackgroundTasks 1” in mt-config.cgi).
Looked in the config file. Yup, it’s set right there. Though … obviously I inserted that line, since it’s not under a comment block. So …
Hmmm. It’s set to 0 again down in the “official” place below. Not sure if that would make a difference (i.e., which value was being read). But I’ve changed it, so let’s see how this comment does.
Well, that certainly felt a lot faster.
Of course, it’s then odd to reload the front page and find that the last commenter hasn’t been updated yet.
We’ll see how/if that helps.
Return to the page seems a lot faster. There is, as noted, a significant lag before the rebuild hits the front page (which slightly worries me, as this may be just masking an underlying problem).
Still need to do the things above, at least #1. We’ll see.
Yeppers, things are working much better. 🙂
…Or…it is getting to the system 500 error in mere seconds instead of minutes, so it is bit of an improvement. ;P
Hrm. Okay. Well … that’s a comfort. I … guess.
Though I haven’t gotten a 500 error yet, whereas yesterday I was getting them pretty regularly.
No 500 errors showing up in the MT activity log. I’ll look in the system log from home.
Test…
Okay, that worked fine.
I’m really wondering about Typekey. I’m seeing looooong pauses in refreshing the Typekey name when the page is loading, and as BD has noted, it seems to be forgetting about (or only timing out?) the logged in identity.
Definitely want to try turning it off. Meantime, I’ll do a bit of digging that direction.
The front page taking a bit of time to update the comment count shouldn’t be a big deal as it’s probably not taking any longer than it did before you corrected the background build option, you just didn’t notice it before because you had to sit through the rebuild process before you could check the main page. As I recall, the index is the last page to be updated by the build process when you submit a comment so it makes sense the comment count update would have a bit of a delay.
Haven’t had any 500 errors on your site yet, but then I don’t comment a whole lot here.