• Like
  • Save
Lamp Stack Optimization
Upcoming SlideShare
Loading in...5
×
 

Lamp Stack Optimization

on

  • 5,870 views

Mike Creuzer's presentation on LAMP optimization for the October, 2009 meeting of the Suburban Chicago PHP & Web Development Meetup

Mike Creuzer's presentation on LAMP optimization for the October, 2009 meeting of the Suburban Chicago PHP & Web Development Meetup

Statistics

Views

Total Views
5,870
Views on SlideShare
5,841
Embed Views
29

Actions

Likes
2
Downloads
56
Comments
1

2 Embeds 29

http://www.slideshare.net 18
http://suburbanchicagophp.org 11

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Quick question on this - is there a way or does anyone have any experience with integration with Salesforce? Company using Lamp Stack as part of content management system and would like it to talk to Salesforce. Thanks
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • http://news.netcraft.com/archives/2009/09/23/september_2009_web_server_survey.html
  • Optimization definition: http://en.wikipedia.org/wiki/Optimization
  • Source http://dev.mysql.com/doc/refman/5.1/en/optimize-overview.html
  • ext3 can be optomized, but the latest versions of linux have many of the optimizations in place. http://lwn.net/Articles/328363/ old ext3 instructions & file access time turn off instructions. http://ubuntuforums.org/showthread.php?t=107856 Use buffered logging when ever apropriate.
  • file access time turn off instructions. http://ubuntuforums.org/showthread.php?t=107856
  • http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
  • http://eloquence.marxmeier.com/sdb/html/linux_limits.html http://www.cs.wisc.edu/condor/condorg/linux_scalability.html
  • Easy optimizations are things you can do without modifying the CMS. We pay the premium for RAID disk drives and extra RAM. 
  • http://httpd.apache.org/docs/2.2/misc/perf-tuning.html Unix apache uses prefork MPM 
  • http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
  • http://httpd.apache.org/docs/2.0/mod/mod_expires.html http://httpd.apache.org/docs/2.0/mod/core.html#fileetag
  • http://www.serverwatch.com/tutorials/article.php/3353701/Apache-Maintenance-Basics.htm
  • These are discussed in detail at the end of  http://docs.google.com/a/creuzer.com/present/view?id=dcm4hz7s_38csb5dzgm

Lamp Stack Optimization Lamp Stack Optimization Presentation Transcript

  • LAMP Stack Optimization for websites using a CMS
  • What's the LAMP Stack?
    • LAMP stands for:
      • Linux
      • Apache
      • MySQL
      • PHP
    • These 4 elements are makes up the bulk of website environments today.
  • What is Optimization?
    • Improving a system to reduce runtime, bandwidth, memory requirements, or other properties of a system.
    • In other words...
    • To make it faster!
  • Metrics
    • The key to optimization is getting a handle on what's going on so you know if what you are doing is making things better or making them worse.
    • Metrics are key.
  • Linux Optimization Overview
    • The other three pieces relay on Linux in order to share resources, so you would think that optimizing Linux would be the best place to start.
    • However, Linux is 'pretty darn good' (TM) out of the box.
    • By selecting the 'server' edition for your hardware platform, you can't go wrong.
    • There are many 'tweaks' you can make to speed the system up and get incremental performance boosts.
    • There are many 'tweaks' you can make to horribly destroy any semblence of performance.
    • Often they are the same tweaks....
  • Linux Optmization Basics
    • Linux just controls application's access to the CPU, RAM, Disk Drives, and network. By giving Linux faster hardware, you will get more performance out of it.
    • In my experience, webservers and CMS websites tend to be I/O bound. So by providing faster disks and more RAM so it needs to access the disk less, you will improve performance.
    • Virtualization is freaking awesome! But it can come at a performance penalty as one virtual server has no control over what the other virtual servers are doing on the hardware.
    • Many linux level optimizations are irrelevant in virtual servers as the 'real' OS could have totally different optimizations.
  • Linux and the Disk Drives
    • Disk seeks. It takes time for the disk to find a piece of data. With modern disks, the mean time for this is usually lower than 10ms, so we can in theory do about 100 seeks a second. This time improves slowly with new disks and is very hard to optimize for a single table. The way to optimize seek time is to distribute the data onto more than one disk.
    • Disk reading and writing. When the disk is at the correct position, we need to read the data. With modern disks, one disk delivers at least 10–20MB/s throughput. This is easier to optimize than seeks because you can read in parallel from multiple disks.
  • Linux and ways it slows Disk I/O
    • Linux ext3 is a journeled file system. That is, it keeps a 'journal' of all the writes it's about to do, so if the system crashes, it can check just those files, and not the entire disk. There is an overhead to doing these extra disk writes.
    • Linux by default maintains File Access Stamps. Yep, every time somebody loads a page, Linux marks the last access date and time. 
    • RAID is good, software RAID is slow! Software raid means that every write to disk is done to each disk separately, in sequence. This can slow the system down dramatically.
    • System & server logging can be very detrimental to I/O speeds.
  • Ways to speed Disk I/O up
    • Use the latest stable version of Linux available . The latest kernel builds have many ext3 optimizations turned on by default
    • Turn off Disk Access Times. For the most part this isn't used on production web servers.
    • Hardware RAID using fast drives.  By talking to more then 1 drive at a time the RAID controller card can mitigate the speed differences between the system bus speeds and disk drive cable speeds.
    • Use buffered logging & increase the size of the buffers. This allows many log updates to occur in a single write. The risk is loss of the last log entries on system crash.
  • Linux and RAM
    • I have yet to meet a Linux server that will not use almost all available RAM given enough time.
    • Linux Loves RAM and will put it to good use in buffers and caching. Also, A Linux server should never have to swap.
    • Let it have lots of RAM. Yes, it will boot into a small memory footprint, but after 30-90 days it will use much more.
    • Your other server software Love RAM too, so get more RAM.
    • Really. More is always better!
    • Really Really!
  • Intermediate Linux Optimizations
    • There are many other Linux optimization techniques. These too advanced to discuss here, as they can have negative performance impacts as well. But here some are so you know what to research.
      • Custom compile the kernel & applications for your specific CPU with all relevant code optimizations turned on.
      • Adjusting open inode limits (number of open files at a time)
      • Adjusting per-process file descriptor limits
      • Local Port Range - Limits number of simultaneous network connections.
  • Linux Metrics Tools
    • top - Shows current cpu usage, memory usage, running processes and 'load average'. A great tool to get a 'feel' for how the server is running.
    • Load average is kinda a fuzzy metric to what it REALLY means, but the best answer I found is that it's the total resource Que time. The time it would take for all queued process/threads to finish executing their current tasks.
    • iptraf - Networking monitoring tool showing current traffic rates.
    • netstat & iostat - More tools to monitor network and disk activity.
  • Easy Linux Optimizations for a CMS
      • Prefer 'real' dedicated hosting over virtual hosting over shared hosting. The less you have to worry about "other peoples' stuff", the better. 
      • Use a server with specifications that are 'good enough'. More RAM is a much better investment than a 0.2ghz faster CPU (1.6->1.8, 2.6->2.8) that many plans offer for their 'better' hosting packages.
      • Use a current version of the operating system. Many speed performance increases are added to newer versions of the OS.
  • Apache Optimization Overview
    • Apache 2.x has many pre-enabled speed optimizations over the 1.x series. So running the latest version will often give you better performance.
    • Apache running in Linux has a 'parent' or 'root' process that creates 'child' processes that do the actual work. Each of these child processes has it's own memory allotment, creates connections to resources, etc.
    • Each child process can handle 1 'request' at a time.
    • Each child handles a finite number of requests before it's 'recycled' - ended and started new.
  • Apache Optimization Basics
    • The trick to optimizing apache is understanding how many simultaneous connections the server is handling and have enough child processes to handle them all. Yet, you don't want TOO many child processes or you can use up all the available memory & other resources.
    • PHP memory allotments are assigned inside each apache child process. So, if you set PHP to use 128mb of RAM, you can potentially have dozens/hundreds of apache threads that can grow to over 128MBs of RAM usage each!
  • Potential Apache Bottlenecks
    • AllowOveride - lets you use .htaccess to change stuff. Apache will look for a .htaccess file in EACH directory working it's way form the root directory to the current directory. 
    • Logging - will always have a performance impact. However, the penalties are often outweighed by the insights gained by the logging.
    • Apache modules - any extra code that's loaded that's not needed just uses RAM and compute cycles. Also, modules such as PHP can really chew up performance.
    • Each of these are likely useful enough to warrant their use.
  • Apache Performance Tips
    • Enable client side caching. This could be the single biggest apache-level performance tip out there. PHP pages CAN and often SHOULD issue cacheing instructions in the headers.
    • Adding expires headers using mod_expires for static content like css, javascript files and images can greatly reduce server load.
    • Configuring the ETag allows quick-lookups of last modified dates allowing very fast 304 responses back to the client. An ETag on apache is a hash of the file info and modification date of static files. It can reduce server traffic even without explicit cache controls.
  • Apache Metrics
    • mod_status - Configure this correctly to have a secure look at what the server is currently doing including simultaneous connections.
    • top - This linux tool will show you what apache is using for RAM and cpu usage.
    • access & error logs. Allow insight into how apache is being used by the users. Tools like AWstats and Webalizer can make analysis on the aggregate easier.
  • Easy Apache optimizations for a CMS
    • Enable caching in the CMS application everywhere that you can.
    • Configure the cache expiration for files that are outside of the CMS, such as images, css files & javascript files.
    • Configure ETags to allow faster file changed lookups for files that are outside of the CMS, such as images, css files & javascript files.
  • MySQL Optimization Overview
    • The database is the heart and soul of a CMS web application.
    • On some CMSes out there, you can have dozens of DB requests per page load, so optimizing the database can be the single most effective optimization you can do.
    • You may be able to configure your CMS so it won't access the DB at all in many circumstances by turning on cacheing.
      • Page Caching - save the whole page for use again later
      • Module Caching - save individual modules and blocks for reuse on subsequent page loads
      • Data Caching - save the data from a query for reuse
    • Optimizing MySQL Query Caching is the next best step.
  • MySQL Basic Optimization Tips
    • MySQL can use memory to cache various aspects of the data.
    • Query Cache
    • The results of a query are saved for later. So if you do that same query again, the results are right there at the server's 'finger tips'
    • Key Cache
    • This is the cache for the indexes. This is probably even more important the the Query Cache as it can be used for many queries.
  • MySQL Memory allocation
    • Total RAM installed
    • - Normal OS memory requirements w/ system caches & buffers
    • - Max # Apache instances * (apache + max PHP)
    • - Other website stuff
    • Memcached?
    • APC?
    • Persistant Connections?
    • - Other services memory requirements
    • email & spam filtering
    • ftp
    • dns
    • - Transient Services
    • Backups?
    • = Available memory to give to MySQL
  • MySQL Metrics
    • Slow Query log - Buy turning on this log, you can see what queries are taking a long time to perform. You can also set this to log queries that aren't using any index to run.
    • MySQL status command -  See the current query rate and other useful statistics.
    • Many 3rd party tools like PHPmyAdmin, SQLYog & MonYog have built in statistics displays/analysis.
    • MonYog can give valid optimization suggestions.
  • MySQL Example CMS Configuration 
    • Seems to work for ~20 Joomla websites and a vBullitin forum on a 2GB RAM dedicated host.
    • [mysqld]
    • log-long-format
    • log-slow-queries = /var/log/mysql/mysql-slow.log
    • long_query_time = 5
    • log_queries_not_using_indexes
    • set-variable    = open_files_limit=6144
    • set-variable    = key_buffer=384M
    • set-variable    = max_allowed_packet=16M
    • set-variable    = table_cache=3072
    • set-variable    = sort_buffer=8M
    • set-variable    = read_buffer_size=2M
    • set-variable    = read_rnd_buffer_size=8M
    • set-variable    = record_buffer=1M
    • set-variable    = myisam_sort_buffer_size=64M
    • set-variable    = thread_cache=16
    • set-variable    = query_cache_size=256M
    • set-variable    = query_cache_limit=2M
    • set-variable    = tmp_table_size=64M
    • set-variable    = join_buffer_size=1M
    • set-variable    = query_prealloc_size=16k
  • PHP Optimization Overview
    • PHP is a scripting language - meaning it's compiled 'just in time'. It's compiled every time the script is run.
    • This is great when you make lots of frequent small changes. Not so good when you have a great many lines of code that get run over and over again.
    • PHP is run inside of apache, so each apache thread will contain all the memory allocated to php. Many CMSs will suggest a 32mb memory limit because dynamic image resizing takes that much RAM. Each apache instance can potentially increase it's memory footprint by that much, so watch apache instances and PHP RAM max allocations.
  • PHP Optimization Basics
    • The more code that is loaded, the slower the code will run.
    • Limit the amount of memory used by PHP and scripts.
    • Utilize the available op-code cacheing.
  • PHP opcode Cacheing
    • Opcode Cacheing is a way to dynamically save the compiled machine code for reuse the next time the code is ran without needed to recompile every time.
    • Available tools
        • Zend Platform
        • APC  ( APC GUI )
        • XCache
        • eAccelerator
        • ionCube Encoder
        • PHP Accelerator
  • PHP optimizations for a CMS
    • Use the suggested RAM requirements by the CMS.
    • Install and use an opcode caching tool.