Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By felixsmile on
Hello everyone,
this might seem an old question, but for the moment, I haven't been able to find any REAL, practical answer on the forum.
I'm running my Drupal site on my personal PC (Windows XP, EasyPHP with PHP 4), and Drupal is becoming slower and slower. I have a RAID 0 and 2 GB Ram and I am the only user for the moment. And still...
I tried using blockcache but it only makes the problem a tiny little bit better.
I'm using quite a lot of modules, but I can't really see any that is making Drupal SO slow. If you have any experience, I would be SO grateful.
Here is one typical devel report; already the first command is taking ages...
55.86 0 drupal_lookup_path SELECT COUNT(pid) FROM url_alias
4.82 0 module_list SELECT name, filename, throttle, bootstrap FROM system WHERE type = 'module' AND status = 1 ORDER BY weight ASC, filename ASC
1.87 0 locale_supported_languages SELECT locale, name, formula, enabled FROM locales_meta ORDER BY isdefault DESC, enabled DESC, name ASC
1.77 0 masquerade_init SELECT uid_from FROM masquerade WHERE sid = 'e13c49929e6feaeaecc7b2cd71c9d142' AND uid_as = 1
24.41 0 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'menu:1:en'
2.63 0 list_themes SELECT * FROM system WHERE type = 'theme'
48.43 0 _watchdog_get_message_types SELECT DISTINCT(type) FROM watchdog ORDER BY type
1.82 0 user_load SELECT * FROM users u WHERE uid = 0
0.82 0 user_load SELECT r.rid, r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE ur.uid = 0
12.56 0 profile_load_profile SELECT f.name, f.type, v.value FROM profile_fields f INNER JOIN profile_values v ON f.fid = v.fid WHERE uid = 0
6.42 0 pager_query SELECT COUNT(*) FROM watchdog w INNER JOIN users u ON w.uid = u.uid
54.96 0 pager_query SELECT w.*, u.name, u.uid FROM watchdog w INNER JOIN users u ON w.uid = u.uid ORDER BY w.wid DESC LIMIT 0, 50
14.68 0 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'content_type_info'
118.28 0 block_list SELECT * FROM blocks WHERE theme = 'niftyCorners' AND status = 1 ORDER BY region, weight, module
81.35 0 user_load SELECT * FROM users u WHERE uid = 0
44.93 0 user_load SELECT r.rid, r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE ur.uid = 0
30.49 0 profile_load_profile SELECT f.name, f.type, v.value FROM profile_fields f INNER JOIN profile_values v ON f.fid = v.fid WHERE uid = 0
29.76 0 tinymce_process_textarea SELECT s.name FROM tinymce_settings s INNER JOIN tinymce_role r ON r.name = s.name WHERE r.rid IN (2)
63.79 0 user_roles SELECT * FROM role ORDER BY name
30.19 0 tinymce_profile_load SELECT * FROM tinymce_settings
56.49 0 tinymce_profile_load SELECT rid FROM tinymce_role WHERE name = 'tinymceforall'
1.49 0 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'bc_16_en_http://localhost:12345'
1.19 0 user_load SELECT * FROM users u WHERE uid = 0
0.79 0 user_load SELECT r.rid, r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE ur.uid = 0
0.8 0 profile_load_profile SELECT f.name, f.type, v.value FROM profile_fields f INNER JOIN profile_values v ON f.fid = v.fid WHERE uid = 0
1.04 0 user_block SELECT COUNT(sid) AS count FROM sessions WHERE timestamp >= 1168524468 AND uid = 0
0.81 0 user_block SELECT uid, name, access FROM users WHERE access >= 1168524468 AND uid != 0 ORDER BY access DESC
1.06 0 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'bc_27_en_http://localhost:12345'
1.64 0 user_load SELECT * FROM users u WHERE uid = 0
0.78 0 user_load SELECT r.rid, r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE ur.uid = 0
2.84 0 profile_load_profile SELECT f.name, f.type, v.value FROM profile_fields f INNER JOIN profile_values v ON f.fid = v.fid WHERE uid = 0
1.85 0 system_region_list SELECT * FROM system WHERE type = 'theme' AND name = 'niftyCorners'
1.32 0 statistics_exit INSERT INTO accesslog (title, path, url, hostname, uid, sid, timer, timestamp) values('administer', 'admin', 'http://localhost:12345/?q=currency', '127.0.0.1', 1, 'e13c49929e6feaeaecc7b2cd71c9d142', 4861, 1168525368)The site will be accessed only by registered users, so Drupal's caching feature is nearly useless in my case (and I suppose this has not changed in Drupal 5, has it?).
Thank you very much in advance, I'm really stuck right now,
Felix.
Comments
You could always try
You could always try optimizing the database tables
Very good idea!
Thank you, that was a good idea, and, stupidly, I hadn't thought about it, as the database is "only" 3 MB big (without any content, thought, that's why I put the "").
The result is good:
Executed 27 queries in 66.66 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted.Page execution time was 6276.51 ms.
The execution time has sunk dramatically.
However, do you see the total execution time? Over 6 seconds! On a localhost! I don't get it. Maybe it's just my PC, but I don't see why.
Anyway, for those who want to know how to optimize their database, I write it here just in case: go to phpMyAdmin (that's the easiest way), select your database, then, in the bottom, select all the entries and in the dropdown menu, select optimize.
Thank you again, if you have another good idea like this, I'll be done more quickly than I thought.
Felix.
In my limited experience,
In my limited experience, the number of modules dramatically decreases the performance of a site. I had a test site which I had downloaded, installed, and tested fifty+ modules. The load times were reaching something like 3-8 seconds per page load. I uninstalled all the test modules and performance was restored to normal load times.
I'm not sure what the long term answer to this is except to suggest using only the modules which you need, and completely removing those which you do not need.
That would be sad
Hi Phil,
Thanks for your reply. Deactivating all the nice little modules I have assembled in countless hours... This would break my heart. I really fear you're right, but maybe there is a less radical solution?
Are there any modules known for putting an exceptional load on the processor?
Very often, the following commands take up a lot of time:
Thank you very much for your suggestions, I have already begun deactivating some modules, but some are just vital.
Felix.
Isn't that the truth! I
Isn't that the truth! I couldn't live without masquerade.
You should take a look at a php accelerator for your windows machine. This has become sort of a standard practice for webhosts to include some kind of php accelerator for their clients. Consequently, many Drupal users are probably utilizing php accelerators without even knowing it. This might increase the overall performance of php on your windows machine without having to sacrifice Drupal functionality.
tinymce
for tinymce you can by default select disabled. in addition to that http://tinymce.moxiecode.com/download.php here u can install the compressor to fasten it. moreover did you see these http://drupal.org/search/node/performance+tuning http://drupal.org/node/2601 http://drupal.org/node/51263. also on a production site i hope u dont just check uncheck modules, try them on the production site code. u should have a test install. i hope links help, u better have a faster site :)
Drupal to rule them all :) www.universideliyiz.biz
Thank you both of you
Your replies were really helpful.
To Phil: I thought about it, and it would probably be a good idea if I kept it on my PC. But I will migrate the site to a professional hoster these days, and I hope their Apache servers will be configured better than mine :)
To theholyking: tinymce is deactivated by default and is "gzipped", but I never had a performance problem with it anyway (on a localhost, there is no real bandwith problem =D). Thanks also for the links, this one http://drupal.org/node/51263 was quite precise. To your last question, I'll just pretend I haven't read it ;) (more seriously, I didn't install uninstall that many modules, I looked at them carefully before installing them, and generally used modules with only little or no database footprint, and, of course, the site is not yet online, so I had some more freedom; now that the site will be online, I'll take my offline installation as test install, of course...)
Finally, my decision was clear: I uninstalled quite a number of modules, especially the image modules, I guess I'll use an adapted system for the images, like Gallery 2 or so. And now it's far better (not perfect, but I can live with it):
Executed 26 queries in 97.83 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted.Page execution time was 818.63 ms.
The module list is still generally too slow, but well, I'll tweak around a bit more and I'll leave it like that.
Thanks so much again,
Felix.
"My" solution
It was the weather module.
Thanks for your help,
Felix.
Oops, I meant to thread this
Oops, I meant to thread this here, as a reply to your comment, felixsmile.
How did you find out which
How did you find out which module was slowing it down? I have tons of modules and my site is equally slow, but I don't know which one(s) could be causing it. Thanks!
Devel module and the database
Well, first of all, I had a look at the times it took every module to load using the devel module. Then, one day, I had quite a severe problem, the site wouldn't load. I had a look at the database, and there, it struck me that the weather module hadn't been updated for some time. And, after deactivating it, tada, my site was easily 2 to 3 times quicker than it was before.
I hope this helps, good luck,
Felix.
Thanks. I guess I can try
Thanks. I guess I can try that method. I've been meaning to go through and update all of my really outdated modules (I think I even still have some for 4.6 that are lying around and possibly still being used). Doing so will likely solve the problem for me.