Expat-IT Tech Bits

Home

Contact

Links

Search this site:

Categories:

/ (287)
  Admin/ (122)
    Apache/ (10)
      HTTPS-SSL/ (4)
      PHP/ (3)
      performance/ (2)
    Cherokee/ (1)
    LAN/ (4)
    LVM/ (6)
    Monitoring/ (2)
      munin/ (2)
    SSH/ (6)
    SSL/ (1)
    Samba/ (1)
    VPN-options/ (6)
      OpenVPN/ (1)
      SSH-Proxy/ (3)
      Tinc/ (1)
      sshuttle/ (1)
    backups/ (17)
      SpiderOak/ (1)
      backuppc/ (5)
      dirvish/ (1)
      misc/ (6)
      rdiff-backup/ (1)
      rsync/ (1)
      unison/ (2)
    commandLine/ (24)
      files/ (8)
      misc/ (10)
      network/ (6)
    crontab/ (1)
    databases/ (15)
      MSSQL/ (2)
      MySQL/ (8)
      Oracle/ (3)
      PostgreSQL/ (1)
    dynamicDNS/ (2)
    email/ (11)
      Dovecot/ (1)
      deliverability/ (1)
      misc/ (1)
      postfix/ (7)
      puppet/ (1)
    iptables/ (3)
    tripwire/ (1)
    virtualization/ (9)
      VMware/ (1)
      virtualBox/ (8)
  Coding/ (14)
    bash/ (1)
    gdb/ (1)
    git/ (3)
    php/ (5)
    python/ (4)
      Django/ (2)
  Education/ (1)
  Hosting/ (27)
    Amazon/ (18)
      EBS/ (3)
      EC2/ (10)
      S3/ (1)
      commandline/ (4)
    Godaddy/ (2)
    NearlyFreeSpeech/ (3)
    Rackspace/ (1)
    vpslink/ (3)
  Linux/ (30)
    Android/ (1)
    Awesome/ (3)
    CPUfreq/ (1)
    China/ (2)
    Debian/ (8)
      APT/ (3)
      WPA/ (1)
    audio/ (1)
    encryption/ (3)
    fonts/ (1)
    misc/ (6)
    remoteDesktop/ (1)
    router-bridge/ (3)
  SW/ (45)
    Micro$soft/ (1)
    browser/ (2)
      Chrome/ (1)
      Firefox/ (1)
    business/ (28)
      Drupal/ (9)
      KnowledgeTree/ (6)
      Redmine/ (2)
      SugarCRM/ (7)
      WebERP/ (2)
      WordPress/ (1)
      eGroupware/ (1)
    chat/ (1)
    email/ (1)
    fileSharing/ (2)
      btsync/ (1)
      mldonkey/ (1)
    graphics/ (2)
    research/ (2)
    website/ (6)
      blog/ (6)
        blosxom/ (3)
        rss2email/ (1)
        webgen/ (1)
  Security/ (15)
    IMchat/ (2)
    circumvention/ (2)
    cryptoCurrency/ (1)
    e-mail/ (4)
    greatFirewall/ (1)
    hacking/ (1)
    password/ (1)
    privacy/ (2)
    skype/ (1)
  Services/ (1)
    fileSharing/ (1)
  TechWriting/ (1)
  xHW/ (14)
    Lenovo/ (1)
    Motorola_A1200/ (2)
    Thinkpad_600e/ (1)
    Thinkpad_a21m/ (3)
    Thinkpad_i1300/ (1)
    Thinkpad_x24/ (1)
    USB_audio/ (1)
    scanner/ (1)
    wirelessCards/ (2)
  xLife/ (17)
    China/ (9)
      Beijing/ (5)
        OpenSource/ (3)
    Expatriation/ (1)
    Vietnam/ (7)

Archives:

  • 2016/07
  • 2016/05
  • 2016/02
  • 2016/01
  • 2015/12
  • 2015/11
  • 2015/06
  • 2015/01
  • 2014/12
  • 2014/11
  • 2014/10
  • 2014/09
  • 2014/07
  • 2014/04
  • 2014/02
  • 2014/01
  • 2013/12
  • 2013/10
  • 2013/08
  • 2013/07
  • 2013/06
  • 2013/05
  • 2013/04
  • 2013/02
  • 2013/01
  • 2012/12
  • 2012/10
  • 2012/09
  • 2012/08
  • 2012/07
  • 2012/06
  • 2012/05
  • 2012/04
  • 2012/03
  • 2012/01
  • 2011/12
  • 2011/11
  • 2011/10
  • 2011/09
  • 2011/08
  • 2011/07
  • 2011/06
  • 2011/05
  • 2011/04
  • 2011/02
  • 2010/12
  • 2010/11
  • 2010/10
  • 2010/09
  • 2010/08
  • 2010/07
  • 2010/06
  • 2010/05
  • 2010/04
  • 2010/03
  • 2010/02
  • 2010/01
  • 2009/12
  • 2009/11
  • 2009/10
  • 2009/09
  • 2009/08
  • 2009/07
  • 2009/06
  • 2009/05
  • 2009/04
  • 2009/03
  • 2009/02
  • 2009/01
  • 2008/12
  • 2008/11
  • 2008/10
  • 2008/09
  • Subscribe XML RSS Feed

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
    PyBlosxom

    This site has no ads. To help with hosting, crypto donations are accepted:
    Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
    Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs

    Sat, 11 May 2013


    /Admin/Apache/performance: Apache/PHP Modules to Increase Performance

    Note that one can monitor progress with these changes using Google's analysis page at https://developers.google.com/speed/pagespeed/insights

    mod_expires:

    One of the cheapest things you can do server-side is leverage browser caching with mod_expires[1]. Apparently[2], even if a file is already in the browser cache, the browser will still query the server on every hit to see if the file has changed. No, the file is not transferred if it has not changed, but yes, there is still a demand made of the server. Unless you turn on mod_expires, which tells the browser in advance how long the file is good for. And thereafter, until the file expires, the browser will not bother the server to check if it has changed. Other then turning it on, there is little to configure with mod_expires except possibly to specify the expiry times in your VirtualHost or in global config file in the conf.d directory, for example:

            ExpiresActive on
            ExpiresDefault "access plus 1 hour"
            ExpiresByType image/jpg "access 1 week"
            ExpiresByType image/jpeg "access 1 week"
            ExpiresByType image/gif "access 1 week"
            ExpiresByType image/png "access 1 week"
            ExpiresByType text/css "access 1 week"
            ExpiresByType application/pdf "access 1 week"
            ExpiresByType text/x-javascript "access 1 week"
    

    Caching: mod_cache / mod_disk_cache:

    Here my reading[4] would seem to indicate that if the server is not proxying, ie. all content is already in the local file system, the kernel can be expected to do a fine job of memory-caching of files without any need for help from Apache. So in the absence of proxying, I have NOT turned on mod_mem_cache, just mod_disk_cache[3]. Debian/Ubuntu, as usual, comes fitted with sane defaults which include turning on the htcacheclean[5] daemon to prune cache content. The only configuration required is, again, to turn on caching for specific VirtualHosts by adding:
    CacheEnable disk /

    PHP Opcode Caching: APC:

    There are three commonly mentioned possibilities for PHP opcode caching: eAccelerator, APC[6], and XCache. I do not see much to choose from between them performance-wise, but APC seems to be a very native PHP project, so I will go with that:

    apt-get install php-apc

    The first thing you will want to do is copy apc.php into some web root and have a look. There, apparently the most important thing to check[7] is "Cache full count" which you want to keep pretty close to zero. To get there, I increased my cache size in /etc/php5/conf.d/apc.ini to:

    apc.shm_size=50

    Google Page Speed Module:

    Get and install your preferred version of the module from [8], ie.

    wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_amd64.deb
    dpkg -i mod-pagespeed-stable_current_amd64.deb
    /etc/init.d/apache2 restart

    [1] https://httpd.apache.org/docs/2.0/mod/mod_expires.html
    [2] http://bytes.com/topic/apache/insights/740981-advanced-caching-mod_expires
    [3] https://httpd.apache.org/docs/2.2/mod/mod_cache.html
    [4] https://httpd.apache.org/docs/2.2/caching.html
    [5] https://httpd.apache.org/docs/2.2/programs/htcacheclean.html
    [6] http://php.net/apc
    [7] http://php.net/manual/en/apc.configuration.php
    [8] https://developers.google.com/speed/docs/mod_pagespeed/download

    posted at: 05:28 | path: /Admin/Apache/performance | permanent link to this entry

    Sun, 12 Dec 2010


    /Admin/Apache/performance: Apache Performance Tuning

    I am running my personal server on a rather small Rackspace Cloud machine with 256M of memory. A default LAMP (plus a couple Python web apps) install seems to occasionally (my websites are usually not THAT busy) choke and force a reboot. Let's try and avoid that:

    First thing I did was install a PHP op code cache called php5-xcache that I have used before. It is a zero configuration slam-dunk, and my spidy sense suggests that it produces a tangible speed improvement.

    All of the reading I am doing (see references below) prominently mention unloading unused Apache modules so as to reduce the memory footprint of Apache processes, so this seems like the first place to start. This is a minimal (not requiring hacking my default Ubuntu server Apache configuration too much) list of Apache modules I can get by on at the moment:

    alias.conf cgi.load dir.conf mime.conf php5.load ssl.load wsgi.conf alias.load deflate.conf dir.load mime.load rewrite.load status.conf wsgi.load authz_host.load deflate.load headers.load php5.conf ssl.conf status.load

    Now into the murky world of Apache MPM (Multi-Processing Modules). Reading the "Compile-Time Configuration Issues" section in [4], one is left with the definite impression that the worker MPM would be a better choice then the prefork MPM in a limited memory situation. So why does prefork always seem to be installed? A little experiment tells all:

    apt-get install apache2-mpm-worker

    will result in the removal not only of apache2-mpm-prefork, but also all PHP modules! [5] has the answer:

    "Apache PHP module is reputed to be unstable in multi-threaded environments"

    [5] goes on to describe a somewhat complicated procedure for making the multi-threaded apache2-mpm-worker module work with PHP. Maybe later, if all else fails. Or maybe switch to lighttpd as a web server. Now back to the stodgy old Apache prefork MPM....

    [6] gives some nice details on how one might go about optimizing the prefork MPM configuration. top is telling me that my Apache processes are currently consuming roughly 30+M per process. My current default configuration is this:

    <IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 </IfModule>
    which I am going to crank WAY down to this:
    <IfModule mpm_prefork_module> StartServers 1 MinSpareServers 1 MaxSpareServers 2 MaxClients 5 MaxRequestsPerChild 200 </IfModule>

    Interesting that the default value of MaxRequestsPerChild was zero. Apparently the point of setting this value to non-zero is to periodically force Apache processes to be killed and recreated, to combat memory bloat (aparently they do not release memory?). It is also worth noting that my server's CPU usage tends to hangout near zero, while memory is always maxed out and swapping is a regular cause of problems. In top I have seen a single Apache process top out at as high as 50% of memory. I think killing processes frequently to reduce memory overhead is probably the way to go.

    And finally, [6] recommends setting a really small KeepAliveTimeout of 2. And [7] recommends keeping "Timeout" small, since I have so few processes and do not want them all to be waiting for a timeout at the same time. So I went for a Timeout of only 10 seconds.

    [1] http://wiki.vpslink.com/Low_memory_MySQL_/_Apache_configurations
    [2] http://docs.quantact.com/tuning-mysql-apache-for-low-memory
    [3] http://groups.drupal.org/node/27174
    [4] http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
    [5] http://blog.fosketts.net/2010/07/30/high-performance-memory-apache-php-virtual-private-server/
    [6] http://www.devside.net/articles/apache-performance-tuning
    [7] http://www.360doc.com/content/07/1210/14/15540_883932.shtml

    posted at: 22:05 | path: /Admin/Apache/performance | permanent link to this entry