Hello everyone.
I have a website for ads.
This is the url: www.4sport.bg
It's hosted on Managed VPS with 4gb ram.
I'm not caching it with the standard procedure from here: admin/config/development/performance, because the website has registered users that will be able to create an ad, update their ads, view their profiles etc, it's very dynamic so I needed something better to cache.
The website is not fast as it should. It usually loads more than 1300ms.
I'm using PHP APC and you can see it from here: www.4sport.bg/apc.php
As I checked APC on some other websites, it seems the APC is not working well on my website, because I don't see any performance improvement. I've spoke with the hosting company and they're guessing that has some conflicts with APC, but they don't know from where does that problem comes.
I've tried with Memcache too, but still no difference...
I have about 40 modules, I've made lots of research, tests and I don't see any problem from the modules, but anyway this is list of the modules:
admin_menu
always_visible
better_messages
colorbox
content_access
crumbs
custom_alter (custom module for altering forms and other tweaks)
ctools
date
devel (deactivated)
disablepwstrength
field_display_label
field_permissions
field_slideshow
flexslider
fontyourface
google_analytics
hierarchical_select
imce
imce_wysiwyg
jquery_update
libraries
link
mailsystem
menu_attributes
metatag
mimemail
module_filter
pathauto
remember_values
rules
superfish
taxonomy_menu
token
transliteration
views
views_slideshow
webform
webform_ajax
wysiwyg
xmlsitemap
Any advice to improve the performance of the website will be very useful. Thanks
Comments
What is your RAM usage?
Here are a few "low hanging fruit" to get you started:
Check your RAM usage using the 'free -m' and 'top' commands. Let us know what you are seeing.
Check your automated cron jobs. Your site can slow to a crawl when cron is running.
Install a php script display interface to check your APC & memcached performance. I have linked to a couple of scripts in other group posts, you should be able to find them here somewhere.
Admin Menu
I removed the admin menu module a few months ago to improve performance. It takes a while, but before long you start to remember the various urls such as admin/config.
You should give this a look
You should give this a look as well.
http://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2F...
Enable gzip, optimize images before diving into the other stuff.
Hi, trainingcity.How can I
Hi, trainingcity.
How can I check RAM usage with these 'free -m' and 'top' commands?
I'm using cron jobs that works from the cPanel, not the Drupal interface and it's working with no problem.
The php script is installed and I've already mention that is available from here: www.4sport.bg/apc.php
There is a php script for memcache/memcached
Hi @satvision83. There is another php script you can use to take a quick look at your memcache or memcached performance. I linked to it somewhere in this group, sorry I can't remember the post but you might be able to find it.
To use Linux commands such as 'top' you will need command line access to your vps using SSL and if you are using Windows, probably a desktop SSL tool like "putty". It is very important that you have command line access to your VPS.
"To use Linux commands such
"To use Linux commands such as 'top' you will need command line access to your vps using SSL and if you are using Windows, probably a desktop SSL tool like "putty". "
it's SSH not SSL.
You absolutely should
You absolutely should activate Drupals performance features at "admin/config/development/performance". The Drupal page cache is only for anonymous users, logged in users will get all the dynamic stuff still.
Aggregate JS and CSS is a must, it will make so users need to download fewer and smaller CSS and JS files.
I also agree with drupaledmonk, take a look at optimising your images. You have a lot of them, 1,3 MB total on the front page alone.
Just put you landing page
Just put you landing page through http://validator.w3.org/
32 errors, 12 warnings
look in admin_menu settings
look in admin_menu settings for a "cache client side" I've actually found that this decreases performance (oddly enough).
This folder has (broken out by file) my standard performance optimization techniques for the backend / linux layer: https://github.com/btopro/elmsln/tree/master/docs
Cache bin optimization is another area you can really help increase scale and speed. You'll need to modify the paths to things according to your setup but this is the standard bin management I use with drupal's APC and filecache modules: https://github.com/btopro/elmsln-config-example/blob/master/shared/drupa...
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
First off, you really need to
First off, you really need to turn caching on, particularly aggregate CSS and JS. Without it, you are forcing the browser to load 28 CSS and 31 JS files. That's 59 extra requests you are making to the server.
APC is working according to your dashboard. If you aren't seeing performance improvements, that means your biggest delay is most likely coming from MySQL or some actual PHP code execution. The best thing to do is to download and install the devel module and enable query output in the settings. Then go to your pages and look at the bottom to see if any queries are slow. If so, then you need to fix those. Also check to make sure the query cache is enabled in MySQL and it's tuned for InnoDB.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
The MySQL query cache is not
The MySQL query cache is not always an improvement. Some sites perform better when it's off. The reason being that oftentimes the most expensive queries involve the users table, but
users.accessedgets updated for every logged in user every couple page requests. Thus causing MySQL to do a lot of work to continually clear the query cache.--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
This is a screenshot of the
This is a screenshot of the copy website with devel.
It's a frontpage:
http://postimg.org/image/sm33hfoyz/
I hope is helpful.
EDIT: Here's another:
http://postimg.org/image/6p19rmmef/
I'm not sure that this is slow.
I'm not using the Drupal caching for anonymous user for a good reasons:
If anonymous user caching is on, after every creating or updating a node, the anonymous wont see the changes in a real time, and that's important for me. Every ad has view count and after refreshing the page it has to show the changes. If Drupal caching is on, the changes wont be displayed in real time.
If I use caching on CSS and jQuery the field_slideshow module that is on every node full content for the ads is stop working.
The server of the website now has mod_deflate enabled, so teh gzip is caching, but the performance it's still the same.
MySQL Query Cache is enabled.
You only enabled the query
You only enabled the query timing, not the page generation timing, so it's difficult to know how much these queries contribute to the entire page load. But if we were just to focus on the queries it looks like the majority of the slow queries are cache queries. By moving to a alternative cache back-end like memcache
https://drupal.org/project/memcache
or redis
https://drupal.org/project/redis
you can improve performance there.
However this also indicates that this is a fully cached page. i.e. not one of the slow ones. Clear all caches to find the truly slow queries.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
This is how it looks when I
This is how it looks when I flush the caches. I've activated the other devel functions.
http://postimg.org/image/jpmy1m6mp/
And this is when I enter some node full content.
http://postimg.org/image/vj3jkryl7/
I've tried with memcache previously and the page loading was stayed the same. I'll try redis module.
Advice
Looks like cache_set slows down when you have a lot of them to do. Other than that it's the volume of cache ops; it appears to not be consistently slow. You might see some small gains by switching over to memcache/redis but the cache database layer is not causing major slowdowns at this point. 1265 queries in 315ms is not slow; that's 4 queries per ms. If it was causing a slowdown the advice on this page would be helpful https://groups.drupal.org/node/415883
What is slow is the PHP side; 2902ms to generate the page. There is a bottle neck in your code. Getting a cachegrind of the PHP execution would be ideal but if you can't do that you should try and find the slow part.
My guess is some of your blocks are slow. Going to http://www.4sport.bg/filter/tips takes over 1.5 seconds; on d.o https://drupal.org/filter/tips takes around 0.3 seconds. A quick way to disable all blocks can be found here
http://drupal.stackexchange.com/questions/25036/disabling-core-block-sys...
<?php// Disable all blocks.
$blocks = &drupal_static('block_list');
$blocks = array();
?>
Using this you can try out each block and time each one as a way to narrow it down. Again getting a cachegrind of the page is ideal, this is here just in case you can't do that.
Cache queries are still the
Cache queries are still the worst of the lot. So I would recommend:
1) Setup Memcache or Redis.
2) Tune the database. Start with a good mysql configuration:
https://tools.percona.com/wizard
After which you can do additional tuning:
http://mysqltuner.com/
But do not disregard the strong warning there. Be sure to monitor performance/scalability before/after.
3) There's more slow stuff on these pages. On the uncached page the DB queries are half of the total page load time. Use xhprof or xdebug to do some profiling of PHP. Here's a decent resource (or there's many more out there too):
http://techportal.inviqa.com/2009/12/01/profiling-with-xhprof/
then fix the problems, and/or add more caching.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
It was a long way battle, but
It was a long way battle, but finally I've found the problem.
It's the Superfish blocks.
They are two of them, one is main menu and the other is displaying after scrolling couple of pixels. It's heavy coded, because it has lot's of menus, children1 and children2. The categories are big and there are lot's of custom css there.
On my test website when I'm logged as an admin the firebug net GET # shows 2s, sometimes about 3s. When I disable the superfish menu the loading firebug net shows less than 600ms and the loading page it's clearly lot more faster.
So, I guess I have to find a way how to fix this jQuery module.
You don't need to disable Drupal caching to achieve your goal.
Hi satvision83,
If you were in the US, I'd suggest you take a step back, and calculate just how much your time is worth.
At the 4GB level, I'm pretty sure we beat the snot out of your hosting company's prices, and we provide full Drupal and server management. http://inet-design.com/managed-drupal-hosting.html
But, we don't have a European server at the moment to put clients on, so, here's some additional thoughts:
http://www.webpagetest.org/result/140502_0M_M7G/ [1]
2,033 KB total front page size is a bit excessive. (Ignore the First Byte Time, it seems broken atm.)
The two biggest issues were Compress Images and use Progressive JPEGs, fixing either will shorten your load time.
That's reasonably easy to solve at the block level. You don't need to disable Drupal caching to achieve this.
I'd also suggest:
Use a CDN (Content Delivery Network)
And, I agree wholeheartedly with:
Best,
Michael
[1] Page load testers aren't perfect, as sometimes they say things like Google fails first byte time:
http://www.webpagetest.org/result/140502_H4_K17/
Drupal Managed Hosting includes Quarterly Updates, Data Migration, ...
The saga continues...After
The saga continues...After lot's of testing even when Superfish is disabled and when I enable the menu block with this big menu three, the website is still slow.
When this block is disabled the website is 4-5 times faster, so I don't have any performance problem even when I'm not caching the website.
I've tried to cache this menu block with hook_block_info_alter(), but because of Content access module, the menu block is not caching even it's altered with the custom module.
Content access module is very important in this website and I cannot remove it.
Mod_deflate on the apache is enabled.
@Michael-Inet
"If you were in the US, I'd suggest you take a step back, and calculate just how much your time is worth."
Sorry, I didn't catch that.
Actually the prices here are lot more cheaper and the servers are really good.
All my other projects are working very fast and stable and they are not small websites.
Core Patch
https://drupal.org/node/1930960
Finally I've solved the
Finally I've solved the problem and I'll share with you!
As I wrote before, the Content Access breaks the block caching and that big menu, that has more than 120 items slows the website.
I've removed the Content Access module and wrote a custom that restrict access on specific pages, used hook_block_info_alter() and set cache = DRUPAL_CACHE_GLOBAL to that block.
Now the website is loading very fast and stable like never before! :)
Thank you all for your great support and advices. I wish you all the best!
Mikey, thank you very much for your good advice, it helped me a lot!