Informative articles on various technologies ...
We discussed the topic of the open buffet binge syndrome, where web sites "gorge" on contributed modules, and cause site performance to be slow and memory utilization to be high.
We encountered an interesting case recently while doing work for a client. The main symptom was page execution time that is high (800 to 1200 ms), but database query time that is low.
Drupal has long supported both MySQL and PostgreSQL as database backends. The vast majority of Drupal users run it on MySQL though. Support for PostgreSQL in Drupal has suffered from non-contiguous maintainership, with someone taking it for a year, then disappearing, then someone else comes by and takes it up, ...etc.
There has even been concerns among core developers about PostgreSQL holding back patches that work fine in MySQL.
The XML Sitemap (formerly gsitemap) module provides good SEO features that allows Google and other search engines to know what content a site has.
The module does however have had some scalability issues if you are using an old version, or if you have the options set incorrectly.
On October 17, a new security release of Drupal 5.3 came out to fix some potential issues with Drupal 5.2.
Sometimes, you have a Drupal installation with a few customizations in core. Or you simply do not want to perform a full upgrade by wiping existing files and replacing them from the tarball.
So, you can opt to apply the patches listed here, but there are too many of them, and if you have many Drupal installations, this will add to the amount of work.
Slashdot is a popular news site for nerds, covering technology, open source, politics and more.
While they do not run Drupal, nor PHP for that matter, they still run on a version of LAMP (Linux Apache MySQL and Perl as in mod_perl).
I presented at the 2007 Ontario Linux Fest, held at the Toronto Congress Centre yesterday, October 13.
It was a very busy afternoon: from 13:30 to 14:30 together with Angela Byron (webchick) and Derek LaVenture, I hosted a Drupal expert Q&A session, where lots of good points were raised.
Often times, when you are monitoring the performance of a Drupal site, you need to see what queries are running, and how long they take.
There are several tools to monitor MySQL queries, including mtop and mytop, as well as running SHOW PROCESSLIST from the command line.
A client site that is growing fast recently complained that the site is slow when creating nodes or when commenting.
The slowness was very noticable, taking up to 30 seconds from the time "Submit" button is clicked, until the site comes back with a new page.
The site has approximately 14,000 nodes, 109,000 comments and 22,000 users.
A client site that is growing fast uses the similar entries module. During the course of a performance tuning exercise, we found a few scalability issues with the module, and some workarounds to them.
This site has more than 41,000 term ids in its categories. This is because it is a user generated content web site and has free tagging enabled, so there are lots of tags.
We get asked a lot how to make a Drupal site faster. Therefore, we list here some tips on how to achieve such a goal.
These guidelines apply for sites that start to pick up traffic (e.g. more than a few thousand page views a day).
If you have tips to share, please add them as a comment below.
Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting
List of recent content on this site.
Do you use any of our Drupal modules?
Did you find our Drupal, Backdrop CMS and LAMP performance articles informative?
Contact us for Drupal and Backdrop CMS Performance Optimization and Tuning Consulting
Most Comments