willhines

Hello. My firm made that theme based on a designer’s layout from Wenner Media. We took the stripped-down classic WP theme and hacked it to bits! I don’t think the resulting themes was completely CSS/XHTML compliant although we tried to get close. We mostly just wanted a way to get the blog in the left column and have two other columns of non-WP content. When building it, I remember not being totally confident that we had styled every element necessary or done it in the most efficient way, but it had all of the elements we needed and loaded relatively fast.

I think MySQL is usually where the RAM bottlenecks occur, but not everyone has access to configuring their my.cnf file. If you do, here’s some tips from someone who’s site was linked on slashdot:
https://error.wordpress.com/2006/06/03/i-got-slashdotted/

The WP-Cache plugin is pretty easy to install and will cut down on how much database activity your site needs.
https://mnm.uib.es/gallir/wp-cache-2/

1 gig RAM sounds fine to me.

I am not a sys admin, but I’ve poked around with apache configs now and then. What’s MaxClients set to in your httpd.conf?

I forgot I was only at 2.0.1 – I have to upgrade that.

But that is correct, akc. We upgraded servers and that solved a lot of our problems. We went to a dedicated server (actual physically dedicated server, not a virtually dedicated one) with 2 gig of RAM. Even that was getting slammed so we went to 3 gig of RAM, and now we’re working on putting a load-balanced solution into place (2 web servers with MySQL on its own box).

In short: WP-Cache, getting a ton of RAM, and letting MySQL have huge chunks of RAM were the main things that saved us. Also, the authors like the clean interface so I got some others to help me lobby to keep WP in place.

The site is probably going to be featured on Good Morning America tomorrow (8/3/2006), so we’re bracing for a spike. Cross your fingers for me.

You don’t have to worry. WP-Cache clears its cache every time you update/publish a post or add/update/delete any of the comments. Basically, anything that would require your feed to be refreshed would also refresh WP-Cache.

All good changes for the query. The trick is making them in a portable way so you don’t mess with WP’s WP_Query object, which builds these queries. I tried hacking WP_QUERY so it dropped the GROUP BY totally when it got posts in the loop, but that broke pagination (which re-uses the SQL string and substitutes in new SQL where the GROUP BY had been).

I guess what I’m trying to do is optimize WP_Query via a plugin that would benefit someone who had put indexes in their posts and comments table.

I have 700 categories and 40,000 comments. The things I’m working on might be worth it at this scale. Maybe not though!

I agree WP-Cache makes a bigger difference than query optimizing. But I think whatever improvments I can make might be worth it anyway!

Maybe underneath

// maybe do more things

try

print_r($custom)

to see what’s getting put in there.

We might have saved WordPress for usmagazine.com. We’ve moved to a beefy dedicated physical server. 2 gig of RAM and only the one site on the box. We don’t run any email on this guy (we didn’t run any on the last one, but we weren’t the only site on the box).

The IT rep is still in favor of MT, but I’ve argued that the simpler interface is a reason to stay with WP. Plus I kinda begged, because it’s so much easier to tweak and develop in PHP and with WordPress’ plugin system. We’re staying WP for now.

He says he’s enabled query caching — a built in feature of MySQL 4.x? He made these changes to the my.cnf file:

old_passwords=1
set-variable = max_connections=250
query-cache-type = 1
query-cache-size = 256M

Plus we still have WP-Cache running.

I’m staying on the blog authors about keeping posted images down to size, and I’m redoing the front page to get the Flash files off of it.

And we have that 2 gig of RAM.

I guess the next step would be some kinda low-level PHP caching component.

We discussed lighttpd — and we’re trying to avoid setting up a custom-installed box. The out-of-the-box setups here have Plesk control panels managing everything and he’s hesitant to give that up for lighttpd and the work of installing/maintaining a custom config.

Earlier, I cited 36,000 to 72,000 sessions a day. I found out that on the day we crashed, we recorded 230,000 sessions. That spike is what killed us. Pray for me if Jessica Simpson kisses someone in public and we get a picture.

Thanks again for all the great advice. I’ve said it a bunch, but obviously having such a caring community is a priceless asset. I hope to pay it back — maybe with a slick, powerful site running WP.

Thanks to everyone for the suggestions.

I’ve tried to talk to the blog authors about reducing image sizes, David, so I hope I can get that to happen. They’re not too savvy, but hopefully I can make it happen.

I think the main lesson I’ve learned is that you can only go where your server admin (be it yourself or an ISP) wants to go.

My ISP (or the people my boss talked to), for reasons I do not know, thinks that WP is not worth the trouble and that MT is easier. The only real diffrence will be that MT was THEIR idea and I assume they will put the legwork into making it work.

Most frustrating: I laid out my plan for the site with my ISP before we launched at the start of March, including WordPress. The guy I talked to then approved of the choices.

But once the traffic slammed us — it got bumped to a higher manager, who blamed the one component that the ISP did not specifically install, WordPress. Classic “not my problem” problem solving. WordPress? I didn’t install that — so it must be the problem.

To be fair, they took SOME steps: increased clients in apache, and shortened the session time. One guy suggested WP-Cache, which I installed. But how about isolating some SQL queries? Increasing RAM? Moving to a dedicated box? Checking that we’d maximized the use of the caching plugin? Nope. Suddenly, flat HTML was the only solution.

Know your ISP. Get them on board with your plan. Or be your own sys admin.

I can’t find a useful spec. It (was/is) a mediatemple DV-Extreme plan. Can’t find the specs you need. Here’s what their site has about the hardware:

HP ProLiant DL360 G4s, featuring dual 3.0 GHz Xeon Processors and RAID-1 SCSI drives.
1 gig ram, 18 gig hard drive storage, 500 gig bandwidth (we had purchased an addition 500 gig on top of that).
Red Hat Enterprise Linux 3 with PHP 4.3.2

Not the numbers you’re looking for, I know.

Thanks for all the advice, everyone. I will be better prepared the next time I try to install WP on a highly-trafficked site, and I’m sure I will try again.

I think the front page was not caching because of comment counts changing. I’ve turned comments off and the front page seems to cache.

For many of these changes — trying lightttpd, more RAM, analyzing queries, determining if big images are a factor — you need your ISP to be on board. I wasn’t successful in getting them on board.

[edited to add]: angsuman, that’s a handy change for wp-cache to prevent regeneration with every new comment. Very cool. If someone does that, they should probably add a message telling the person posting that their comment won’t show up right away, or else people will post repeatedly.

Thanks again for all the advice. It will be a big help on my next attempt.

You’re right — the commnent rate is not as bad as a few a minute (it was a few a minute on the Britney pregnant post, but that was just for a short burst).

I hate it when people use this forum as tech support, but I’ll put this here in case I can save someone else headaches:

I see this in the source on a single post page:
<!– Dynamic Page Served (once) in 13.895 seconds –>
<!– Cached page served by WP-Cache –>

And I see files being created in the wp-content/cache directory. So I think I have wp-cache working.

I did confirm it, and it was a huge help. Brought the server load down from 8 to about 1 — thwarting our first burst of traffic.

But we had two more bursts since then which overwhelmed despite WP-Cache.

It’s when a post is heavily commented that seemed to kill us. The Us readers, when they latch onto a post, comment several times a minute. That, combined with the crush of traffic going to the post (“Secret dinner for Nick and Jessica”) — would do it. I had just pinpointed that as a stress point when I got the word that we had to switch. It’s still just a hunch, but by disabling comments on popular posts I’m keeping the site up.

I said “Ok. It’s $200.”
“It’s not free.”
“Nope.”
(hands over credit card).

I’m SURE WordPress could have worked. But the ISP, or whoever controls the server, is not on board — well, then it can’t work. I’m sure MT will have trouble, but since it was their suggestion I assume they’ll battle through whatever problems surface.

It’s infuriating.

Lists of optimizations are good. Even better would be a handy list of highly-trafficked, high-profile sites that use www.remarpro.com. One mention of “huge-site-you-have-heard-of.com uses this” is more powerful than a page of statistics.

I’ve gotten a mandate: we’re moving to Movable Type. Sucks! I first discovered WordPress two years ago when I got sick of waiting for MT to publish pages. But now the allure of flat HTML has won out. Not my decision. I guess if the ISP will support this, then it’ll be better for me, and I can keep using WP for other projects.

Thanks, everyone.

Yeah, I’m not interested in Lightpress if only because its support community is not as evolved. And I’ve never heard of it before today. WordPress is great and FEELS right — I’m going to keep pushing to have it be our main tool, though if I can’t enable comments I will lose that battle.

Thanks, Matt and Owen and everyone for the fast response. I’ll look into getting more memory. I’m totally fine with getting a bigger box if I can convince mediatemple to let me(?). I’ll also ask them about installing a PHP opcode cache.