Hi,

My question is not really specific but i need opinions from the mosts experienced :) (again)

I start enjoing drupal there is one or two years now and i join a big drupal 6 project there is some few month.

There are thinking of upgrading it now, but it's a hudge beast, it will take a loooooong time, so we have to continue to maintain this one until the new fork is ready.

The best reason for upgrade, more than security, is because it's heavy. VERY heavy: 5 or 8s load pages on the production optimized server, up to 24s on my developpement local machin !

It's okay with boost: this static cache drops response time to 50/100ms, but we almost kill the server every time we need to flush boost, after update, and repsonse time is awfull during 24h or 48h depending of trafic.

So here is my question:

Some say that it's heavy because it's old: old drupal, old php, old mysql, and there is too many custom code. It will be faster to upgrade to D7 or D8 than investigate what make it heavy, and make the page generation time acceptable.
So untill the new version is ready, the only thing to do is to space the update to 1 per month.

I think that 10s for loading a page could not be only because it's to old... but i'm realy not D6 experienced.

What is you opinion about D6 performance ? could it be because of bad coding practice, or is this a classic case for big old D6 project?

Comments

John_B’s picture

Drupal 6 is not slower than 7. The question with 8 is more complex.

Cannot diagnose reasons for slowness by reading the post and guessing! It could be that the server is not up to the job for the size of site. It could be that the server has tons of RAM and nice fast SSDs, but that it is not configured to utilise the RAM well, or at all. It could be that there is some problem code. It could be that there is some problem database query / View, or some database tables which need indexes added.

You do not say whether the slowness is for logged in users or anonymous users. Presumably if Boost helps, the main concern is for anonymous users.

Personally I would put the site behind Varnish. Varnish does not work well with Drupal 6 unless you use the Pressflow distribution. Switching from standard Drupal 6 to Pressflow is pretty easy. Also your PHP should have some Opcode caching: enable Opcache, unless it is an older version of PHP were you have to install APC.

Having said that, the 'professional' answer is that you need a more precise diagnosis before it makes sense to start throwing solutions at the problem.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Cawet’s picture

Thank you very mutch for helping !

here is more information:

when boost is enable, it's ok for anonymous user, but slow when connected: boost is disable for connected user, i think.

Bigest problem is when we clear boost cache after templates update : all "boosted" page need to be rebuild at the same time and the server is suffering during 24 - 48h : 48 000 page to rebuild, with something like 80 request / second.

I'm pretty confident about the system administrator's configuration for the server : with a "default " configuration like on my developpement computer, some page need like 20s to be build, against 5/6s on the server (and he said that he can't do better).

It's a old php version (5.3), and the cache system used is Redis (2.6).

At the end, i totaly rebuild the front recently and the last problem now is with the server response time when there is no boost cache (devlopping), with boost cache for connected user, and when we flush the cache.

Multiple developper work on it since 5 or 6 year, without any documentation written =D . I start learning drupal with the 8 and a bit of 7.

The system administrator tel me that there is to mush request to MySql (he can give me the biggest and most used - but it's some request from core so i don't know if it could help ) and some time, there is some 40MO backoffice POST request (this is udge, even with some images).

Starting with that, where can we start investigation ?

John_B’s picture

I would look at the slowest Mysql requests, check how slow they are, and decide whether they could be better designed. If you think they are well designed, maybe you just need a separate server for the database. You can also consider whether there are queries where the table would benefit from being indexed and is not yet indexed: see https://www.drupal.org/docs/7/guidelines-for-sql/the-benefits-of-indexin....

I would also seriously think about replacing Boost with Varnish, at least if your main webserver is Apache, since Varnish does a similar job to Boost but is far faster and more lightweight, and handles cache invalidation automatically. Varnish is software you install and configure on the server, not Drupal software. However it does have implications for Drupal software: remember that on D6 you will need Pressflow if you use Varnish. You do not need the Varnish module, though it is useful because it integrates Drupal cache invalidation with Varnish, thus preventing Varnish from serving stale content.

The more recent versions of php and mysql are a bit faster. However that is not first place I would be looking for gains, especially as upgrading the server might break things on the site.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Cawet’s picture

I didn't expect a answer like that, thanks!

I will talk to the admin Sys. about the mysql dedicated server i think he could estimate the benefite .

About Warnish, when you say "and handles cache invalidation automatically", do you mean invalidation with code update to ? does that mean that it's not needed to flush all cache but it rebuild only visited page and only if needed? oO
What about connected user?

I already try pressflow but don't see many change and got some fiew problem. At this time it wasn't look like a solution to spend time, but now yes may be!

John_B’s picture

When a page is called Varnish will check whether it has a cached copy and check whether it is a stale copy. If it is stale it will call the page from the backend and store a fresh copy.

In addition Varnish will clear a page from the cache after a time limit set in its configuration. This happens oustide Drupal.

In terms of actively clearing the cache, when happens when any Drupal page is updated or when you hit cache clear or run cron. Everything is cleared at once which is inefficient. (Drupal 8 has overcome this problem.). If the Varnish module is installed on the Drupal site, the Drupal cache clear will also clear the Varnish cache, otherwise not.

Varnish does nothing for logged in users in Drupal 6 or Drupal 7. There are some workarounds, but not publicly available workarounds which work well for Drupal 6 or 7 (they work badly, often). It is better to discount any benefit from Varnish for logged in users on D6 and D7 at least when you first install it. Caching is more granular in Drupal 8, so with Drupal 8 you get a much heavier piece of software, mitigated by much more sophisticated caching mechanisms.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors