21 avril 2007
You should not write Web application with Drupal 4.7
You should not write Web application with Drupal 4.7!
I didn't mean you should not *USE* Drupal 4.7.
Drupal is a good PHP CMS for little or medium websites, where performances are not crucial, and ease of setting and use is the main target. BTW that's exactly what I could install on my home page if I would like to extend it to add full featured blog, comments, forums, and so on. I am not charged for the PHP CPU or Memory I use, nor for the MySQL resources...
I will talk about Drupal performances another day...
The point is : you should not write web application with Drupal 4.7
That means you could use Drupal, use Drupal main modules, enjoy!
But don't take it to be the fundations of your web site. You will be terribly disappointed in many ways:
- Performances
- Modules code quality
- Drupal documentation
- Modules documentation
- Lack of Module debugging support
- Quality of DB Design and SQL Queries
- Drupal Model overloading your DB
- Inability to scale
Performances are the result of poor DB Design, lack of MySQL understanding from many module writers, poor code-quality, poor overall design requiring all module including at each http query (or almost), and even with mandatory PHP accelerator (Cache of compiled PHP code), performances fall behind anything I knew.
For example, the web site I am worked in, using Drupal 4.7, is able to send back 3.8 queries/s on a Pentium4 3.0Ghz with Hyperthreading and 1GB RAM. Our Web server could handle as high as 6 http queries/s but it's a much powerful server with PHP eaccelerator. You could be faster, but will have hard time to do it, because of the next points.
6 queries/s with our lightweight homepage translate of 49KB/s of throuput. Yes you read it!
It means that with a 8MB cable or ADSL connection, you could saturate up to 20 of our servers. From a simple home connection! That totally unsafe!
Module code quality is far from great, with functions having no documentation, no php doc, no comments, poor overall code quality, and even fake function names that could impair you if you assume the function do what it's name imply!
Drupal documentation is poor too. There's great documentation to setup Drupal, changes parameters, and so on, but there's almost no documentation and correct example on how-to write modules.
So the first modules you will wrote you will be on your own, blindly.
Naturally when there's a bug on your new module, Drupal will halt?
No, no bad performances doesn't means security or support with Drupal. You will often end-up with a 'connection reset' page, even using Zend Studio (as I do at work) on debug mode. So you will end up debugging at hand.
Sometimes an unset variable is enough to get you this white screen of deaf!
DB Design and queries are absolutely disastrous on Drupal Modules, and that the major performance problem, even considering huge CPU waste by the application. Lack of indexes, ORDER BY each and every time it's possible (even if it irrelevant), no LIMIT on queries, etc. Result is load increase exponentially with your user base! Sorry!
When queries are simple, there's another caveat, they are often using to retrieve ONE piece of information.
For example Users and Profiles. When you retrieve and User, you generate one SQL query. If you need it's Profile informations, you generate ANOTHER query. 2 Queries to have an user informations, yes!
And when you display a list of users, you need to generate these 2 queries for each users.
That translate to having a list of 50 users on a page causes 100 queries to be generated to MySQL.
I saw that on amateur's web site, Drupal use it as a Model.
On the PHP side, Drupal could scale well, just add a server box. Say 1 server box per 100 logged-in users (oups).
On the MySQL side, Drupal doesn't have any support for MySQL Clusters, where you have one Master (that mainly serve updates and inserts) and many Slaves (that only serves SELECT). So you could only "clusterize" your servers by using expensive MySQL NDB CLusters, that characterize themself as storing indexes in memory.
Means that you need at least (your index size+25%) in free memory on NDB Storage Nodes, and preferably (2.5x your index size) for redundancy. That could be expensive on a website having many messages/posts/comments indexed!
BTW you loose the fulltext index ability of MyISAM.
That's perfect for a blog, for a little or medium website, but if you are in serious business, any of these problem should make you rethink Drupal's choice for developing your own website. Considering them all, and the inability to scale (no specific support for mysql clusters), you shoudl avoid Drupal.
Commentaires
Joomla!, Mambo
Hi,
We are in the process of implementing a CMS for our service. Your comments are interesting. Have you thought on comparing (at the same level) Joomla or Mambo? From my experience, Joomla and Mambo have important performance issues as well - from a user point of view. Merci pour tes commentaires.
W11z
Hey Mac bidouilleurs!
I didn't consider them, as I didn't consider Drupal in term of flexibility, features nor ease-of-use.
My point-of-view is that of a back-end guy, taking performances, security and internal design in consideration.
I am interested in looking for Joomla or Mambo, but I won't be able to compare each one, as each project is different, and each product have different features and modules, it will be difficult to setup a real world site that is comparable with each CMS.
If you are interested, on the other hand, I have developped a free patch for Drupal to build correct Indexes that gives better performances.
Drupal 6.2 ???
Greetings, I just read your blog on Drupal 4.7. Have you had a chance to evaluate Drupal 6.2 yet and do you think it's a significant enough improvement to consider for more demanding web applications? I'm building a small personal site in 4.7 right now and even in config mode it's very slow. Was not sure if this was my hosting service or just Drupal.
Regards,
Gerard.
both :-(
It's probably both that gives you bad performances.
As I report, Drupal 6 consume much more resources than Drupal 5, or put it differently, is largely slower on the same configuration!!! It won't help!
Drupal is easy to setup and administer, really flexible, but still lack the ability to scale well while needing too much computing resources.
Poster un commentaire
Rétroliens
URL pour faire un rétrolien vers ce message :
http://www.canalblog.com/cf/fe/tb/?bid=96635&pid=4696863
Liens vers des weblogs qui référencent ce message :