Migrating from Mambo to Another CMS?
Pikoro asks: "I put up a website a while back for personal use and I have been using Mambo to keep the site in order. One problem though. It seems that Mambo is not all that scalable. The website I started in January now gets almost 20,000 unique users a day and Mambo is very SQL heavy. The database is running on a P4 2.4Ghz machine with 1Gb of RAM, and the database server is on it's knees. Do I need to just upgrade the database server, optimize the MySQL installation, or switch to another CMS system. I would prefer the latter since I have had issues with Mambo and wanted to move to more of a weblog style format. Was considering Slashcode as well. Any ideas would be greatly appreciated."
You're going to see the same problems with any CMS. *ALWAYS* tune your database first. Then decide if that's really your problem.
Not all CMS schemas are good. Not all come with indexing that makes sense for the usage. Most don't do any tuning of your database parameters, either.
Here's a subtle hint that will probably help:
set global query_cache_size = 1000000;
- billn
Why on Earth would his readership care what CMS engine is running behind his site?
They are reading articles and comments.
If he switched from MySQL to PostGreSQL would he lose readership as well?
I assume he's not going to be an idiot and bring his site down while he installs and configures his new CMS engine.
- For the complete works of Shakespeare: cat
"Wouldn't changing to another CMS possibly cause you to lose readership? Seems like just upgrading the server is the way to go."
I ASSume he'd import/export over the old entries/articles to the new CMS, and probably create some apache url rewrites to make sure links to the old content/link style redirect to the "new" version.
*shrug*
Build Your Own PVR/HTPC news, reviews, &
Either install squid as a reverse cache, or use Apache's mod_cache. Unless Mambo is so broken as to make caching infeasible (some CMSes aren't exactly cache-friendly), this should take a load off the database.
Also, make sure you aren't screwing up public caches anyway. Things like serving CSS through PHP for compression etc aren't brilliant ideas, and you can get decent load reduction by setting expiry times in your HTTP headers. Mark Nottingham has written a good caching tutorial.
Er, just a thought, but you have actually profiled and made sure that it's the database, right? A lot of people will say stuff like that based on nothing more than guesswork. Measure before optimising, or you're just wasting your time.
Bogtha Bogtha Bogtha
OK I don't know much about CMS's but wouldn't it act differently? Possibly different feature sets and look and feel? How would /. readers feel if suddenly the site wasn't running slashcode? (OK, some might rejoice...) But it would look and act differently if it were running another CMS wouldn't it?
This sig kills fascists.
The last packaged CMS I used was PLOG, I've even recommended the thingie here on Slashdot, but the thing just was smashed with too many comment-SPAM, and my google ranking hit the bottom (watch the trackbacks!!!). Even worst: when I decided to upgrade to the last version, it doesn't work with the last version of PHP, so I make the change and it took me about 1 week to write my own CMS.
The first thing I realized was that I've to keep all the past URIs working (so all of the search results keep coming to my site, to the articles they mean). So all the scripts check the way they're called to render the appropiate content. This is a pretty serious matter: if you switch a CMS there's a BIG chance your site it's going to plummet in search-site rankings, unless you can "emulate" the previous CMS behaviour.
Next: there's no-way to beat static VS dynamic performance, so unless you have the bucks, your CMS must render static content if you have too many hits (not an issue for me, but I'm working on it, and expect to have this feature ready in this week).
I think the CMS wars are a little out of hand when it comes to "easyness" - "features" - "performance". There are not simple CMS available anymore. And that's a shame.
I really doubt you can switch your CMS to another without loosing all hits stored in current search engines DBs without emulation, and I know no-one emulate other CMSs.
Your road looks pretty bad if you can't write programs, mess with URI rewriting and MySQL/HTTPd tweaking. Either you assume the losses in switching, or get your hands dirty plotting the best way to go.
Carlos Niebla
I set that parameter on a vanilla install of MySQL 4.0.20, and website load times decreased by 80%. This site was doing about 5,000 hits a day.
More than enough BS
We tried using slashcode for a very simple site (www.cyberlodge.org). Let me come out and say this:
SLASHCODE IS THE SHITTIEST PIECE OF SHIT I HAVE EVER WORKED WITH.
Now that I've said that... Slashcode looks like it was written by first year high school computer science students. Simply trying to change the look of the slashcode site is an exercise in futility, requiring messing with the ugly code with its interspersed look. If there are Design Patterns and Best Practices, then Slashcode would be the antithesis of them.
The little known Roxen webserver (http://www.roxen.com/) has an excellent CMS. It uses CVS to manage workflow and content revision, showing only the trunk-head to regular site visitors. It uses server-side XSLT and Roxen's 10 year mature caching systems. Roxen has had built-in browser-based "GUI" administration and configuration since it was called Spinner back in the early days of the web. It's only downfall has been that it was written in "uLPC", the language of MUDs, rather than pure "C".
The webserver (platform) is free/OpenSource (http://download.roxen.com/ and includes one of the easiest web-scripting languages around, RXML. The CMS is freely available but costs for commercial use.
-- A change is as good as a reboot.