[support] Improving performance

Sat Jan 4 04:25:38 UTC 2014

Wow that's almost scary. With the following settings my server leaves burnt rubber on the road.

Tweaked the my.cnf on my devel server to test, and then my production server per following from  https://drupal.org/node/85768

[mysqld]
max_connections = 150
max_user_connections = 150
key_buffer = 96M
myisam_sort_buffer_size = 128M
join_buffer_size = 8M
read_buffer_size = 8M
sort_buffer_size = 12M
table_cache = 1024
thread_cache_size = 286
table_definition_cache = 1000
interactive_timeout = 25
wait_timeout = 1800
connect_timeout = 10
max_allowed_packet = 4M
max_connect_errors =  2000
query_cache_limit = 4M
query_cache_size = 64M
query_cache_type = 1
tmp_table_size =  64M
innodb-flush-log-at-trx-commit = 2 

Don't profess to understand most of them, although did a stint as an IDMS/IMS DBA thirty years ago. Above probably need some more tweaking as I go along BUT......

Thanks for tips

Alison

At 02:09 PM 04-01-14, you wrote:
>Your problem isn't really caching, but regeneration. If you have items 
>on the page taking a few seconds to generate, from queries that aren't 
>optimized, huge processing, etc., then whenever that cache is 
>invalidated, either through expiration, content change or a cache clear 
>call, then you're going to get hit with the same problem. Put another 
>way, the hangup isn't getting the data from cache, but rather Drupal 
>generating the data to put into the cache.
>
>The best thing to do is run a development setup and enable the devel 
>module and enable query output in there. Then clear your cache and look 
>on your slow pages to see what queries are holding things up.
>
>Another very common issue is negligence in tuning the actual server. 
>What happens here is that you are throwing performance enhancements like 
>caching into the mix and that is nothing more than a band-aid covering a 
>much larger problem. A key place to start is always with the database. 
>Installing MySQL is very easy, but the configuration it ships with is in 
>no way meant for production (simply because configuration depends upon 
>usage and usage is different between applications and even between 
>Drupal sites). You need to monitor some key MySQL metrics to make sure 
>they are within appropriate ranges. A good tool for the is tuning-primer:
>
>https://launchpad.net/mysql-tuning-primer
>
>Run that after the server has been running a day or two and it will 
>check existing status variables and make recommendations on what to change.
>
>Jamie Holly
>http://hollyit.net
>
>On 1/3/2014 8:21 PM, Alison wrote:
>> Hi Jamie, Phil,
>>
>> thanks for the info Jamie, much appreciated. As to sharing Phil, happy to do so. A little bit about  my  setup.
>>
>> I am retired and run a Centos 6.5, Apache, MySQL webserver in my lounge room. The server is home built - Gigabyte mobo, Intel processor, Kingston RAM, etc. I have a second similar server as a backup and development machine.  I get 1.5Mb upload speed which is adequate to support half a dozen low traffic Drupal based sites. When I say low traffic, we are looking at 30-50 hits a day for each site
>>
>> The sites tend to be more personal interest sites rather than commercial ie. personal Blogs etc.  The hits tend to be clustered based on chronology and demographic. Typically might get 20-30 hits over a couple of hours on a site and then nothing for 20 hours. During the quiet period had problems with Drupal cache's timing out, so first hit was then incredibly slow.
>>
>> I installed memcache via Drupal.org and memcache status using their instructions. This seemed to help, but still getting very slow first responses. I then did following:
>>
>> [root at webserver ~] yum install  php-pear  php-devel  httpd-devel  pcre-devel  gcc  make
>> [root at webserver ~] pecl install apc
>> [root at webserver ~] service httpd restart
>>
>> This being suggested by a google search. The pecl install seems to have included an initial setup as many questions were asked.
>>
>> As I have massive amounts of RAM available, I increased all resources in  /etc/php.d/apc.ini     apc.shm_size = 128M  apc.num_files = 4096  apc.user-entries = 4096  apc.ttl - 21600   apc.user_ttl - 21600   apc.gc_ttl = 14400  apc.max_file_size = 5M.  Then did a [root at webserver ~] service httpd restart.
>>
>> There is a really neat tool to see what's happening. Copy apc.php from docs directory to site root, and the run example.com/apc.php.
>>
>> Now I need to wait a few days to see what happens.
>>
>> Alison
>> PS. Latest site just built is at http://www.trans-aspie.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> At 01:57 AM 04-01-14, you wrote:
>> >Hi Alison,
>> >Please share what you find.   I have been intending to look into this
>> >myself.
>> >I'm concerned about the initial page load time on my site.  It seems pretty
>> >slow.
>> >Regards,
>> >Phil
>> >
>> >
>> >
>> >From:   Jamie Holly <hovercrafter at earthlink.net>
>> >To:     support at drupal.org,
>> >Date:   01/03/2014 09:31 AM
>> >Subject:        Re: [support] Improving performance
>> >Sent by:        support-bounces at drupal.org
>> >
>> >
>> >
>> >The high performance group on drupal.org is really good:
>> >
>> >https://groups.drupal.org/high-performance
>> >
>> >The most common recipe is APC for opcode caching, memcache for object
>> >caching and Drupal's database to cache the form table.
>> >
>> >APC also offers object/user caching, but you do have to spend sometime
>> >getting it tuned right so the memory does fragment. In one high
>> >performance site I manage I use the same recipe as above, but I use APC
>> >to handle page caching.
>> >
>> >Of course all this varies greatly by site. Some sites are mostly
>> >anonymous users, meaning page caching is the key, while others have a
>> >heavy logged-in user base, so object caching becomes the big factor.
>> >
>> >Also depending on how the site is built, there's other cache modules out
>> >there that really help, like views cache, authcache and panels cache.
>> >
>> >Jamie Holly
>> >http://hollyit.net
>> >
>> >On 1/3/2014 5:08 AM, Alison wrote:
>> >> Hi Guys and Girls,
>> >>
>> >> can anyone recommend a good general discussion site or place where I can
>> >read about Drupal caching. Currently running Memcache and APC -  the PHP
>> >accelerator, but not sure whether there would be anything to gain by
>> >implementing Drupals caching as well. Wouldn't mind finding some way of
>> >measuring the effects of the various performance enhancements. Are there
>> >any downsides to Memcache and APC?
>> >>
>> >> Hugs
>> >>
>> >> Alison
>> >>
>> >
>> >--
>> >[ Drupal support list | http://lists.drupal.org/ ]
>> >
>> >
>> >--
>> >[ Drupal support list | http://lists.drupal.org/ ]
>>
>
>-- 
>[ Drupal support list | http://lists.drupal.org/ ]