6 ms·
I'm a MySQL DBA, I occasionally work on a database that hosts a few large Drupal sites. While I disagree that Drupal simply sucks and that you'd be better off
by spudlyo 17y ago
I'm a MySQL DBA, I occasionally work on a database that hosts a few large Drupal sites. While I disagree that Drupal simply sucks and that you'd be better off hacking your own homebrew CMS in rails, the author does make some valid points.
Drupal does indeed store logs in the database, in a table called 'watchdog'. One problem I've run into is that if a popular page generates a bunch of warnings, there ends up being a pretty heavy write load on this table. It doesn't help matters that it's usually a MyISAM table, which means that all these writes stack up when the table gets locked, say when Drupal wants to do prune old entries. I've seen this nearly exhaust all the available MySQL threads. I think there is a module that you can use to stop this behavior. Alternately you can alter the table to use the BLACKHOLE engine.
One thing the author didn't mention, is that Drupal's content search is really bad. In order to perform multiple keyword searches it ends up generating these massive queries that join tens of search index tables. These queries can kill the MySQL join optimizer which can ultimately bring your MySQL server down.
http://drupal.org/node/514366 http://drupal.org/node/514366
While this bug has been fixed, the search queries are still gnarly and slow. If you're planning on running a Drupal site with a lot of content you'll definitely want to investigate an alternate search system, perhaps using something like Sphinx or Lucene.
- ten7 17y agoIt boggles my mind that NO ONE has mentioned that a CORE module of Drupal that is simply not switched on by default is Syslog. So what if the CMS logs to the database by default? If you know better, switch that off (you have been able to do this since V6 started using dblog and NOT Watchdog) and log using Syslog. Come on people, wake up! Check these: * http://drupal.org/handbook/modules/syslog http://drupal.org/handbook/modules/syslog * http://drupal.org/handbook/modules/dblog http://drupal.org/handbook/modules/dblog
- jacquesm 17y agoThe majority of the drupal sites out there are stuck on 5.x and can't upgrade because of the lack of a simple upgrade path. Upgrading should not be an order of magnitude more work than installing and building the site in the first place.
- ten7 17y agoMajority? Where's your proof? I think "majority" is just conjecture... show me some numbers and I'll believe you.
- jacquesm 17y agoOk, you're right, it's just conjecture, but that conjecture is based on looking in to a whole bunch of sites using drupal. Let me go do my homework and get back to you on that to see if it is the same across a larger sample.
- ten7 17y agoAwesome. I tried finding some numbers myself, but was disappointed in the lack of data. Would be glad to see what you find...
- aasarava 17y agoDrupal.org tracks download statistics for contributed modules. So one way to get a sense of how many Drupal 5 sites are out there in comparison to Drupal 6 sites is to look at the versions of popular modules that are getting downloaded. In particular, see CCK and Views.
- jacquesm 17y agoNo, that won't work. You need to know what version someone started on. That's the bigger problem in finding migration data, to find out when someone joined up. If someone started at version 4 and they've kept current all the way through to version 7 then that would be the kind of stuff we're looking for. After all, the point I was trying to make was that it is very hard for people to upgrade across major versions, so plenty of them are stuck with whatever was 'hot' when they first started out. The knowledge required for migrating drupal to a higher level version is a lot more involved than for building the website in the first place.
- gaius 17y agoOr perhaps not using MySQL. Table locks indeed, this is 2009!
- mjgoins 17y agoUnfortunately, while drupal ostensibly supports other database backends, the reality is that it doesn't support other database backends.
- CitizenKane 17y agoThis is something that is being rectified with the upcoming Drupal 7. This is a rather tough nut to crack because different database servers don't actually have compatible SQL syntax even among some basic queries. A lot has been done to improve this, including an API to declare database tables in a way which is SQL server neutral. And Drupal 7 will also have query builders to deal with differences in syntax among some of the more basic queries.
- gaius 17y agoIt's not even a matter of SQL syntax. Oracle, for example, uses cursors implicitly and declaring a cursor just gives you a handle to it. In SQL Server, using a cursor is an expensive operation. So if you are trying to be database-neutral, do you use cursors or not? How does that affect the likelihood of deadlocking? Etc etc etc. In practice if you try to be database agnostic you end up with something like SAP which runs like molasses in Winter equally on all databases...
- jrockway 17y agoThe problem is not enough abstraction. If your application code sees things like cursors or SQL statements, your design is broken.
- gaius 17y agoI'm talking about inside Drupal itself. Locking strategy is another one: it's impossible to optimize for one database without sucking on another. Lots of developers with experience only on one don't even know they're doing it, they think this is just how databases work. Being database agnostic makes as much sense as trying to write code that compiles in both C and Java.
- mcantelon 17y agoSolr seems to have emerged as the new Drupal search standard.