Top 30 Scalability Mistakes


Published on

An extended version of my famed Top 10 Scalability Mistakes talk given at various conferences around the world.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Top 30 Scalability Mistakes

  1. 1. Top 30 Scalability Mistakes John Coggeshall
  2. 2. Welcome! <ul><li>Who am I: John Coggeshall </li></ul><ul><ul><li>Team Lead for Pro Services, Zend Technologies </li></ul></ul><ul><ul><li>Author PHP 5 Unleashed </li></ul></ul><ul><ul><li>Zend Educational Advisory Board </li></ul></ul><ul><ul><li>Speaker on PHP-related topics worldwide </li></ul></ul><ul><ul><li>Geek </li></ul></ul>
  3. 3. What is Scalability? <ul><li>Define: Scalability </li></ul><ul><ul><li>The ability and flexibility of an application to meet growth requirements of an organization </li></ul></ul><ul><ul><li>More then making a site go fast(er) </li></ul></ul><ul><ul><ul><li>Scalability in human resources, for example </li></ul></ul></ul><ul><li>The “fastest” approach isn’t always the most scalable </li></ul><ul><ul><li>OO is slower, but more scalable from a code maintenance and reuse standpoint </li></ul></ul><ul><ul><li>Failure to consider future needs during architectural stages leading to failure of the application’s API to scale </li></ul></ul>
  4. 4. The secret to scalability is the ability to design, code, and maintain your applications using the same process again and again regardless of size
  5. 5. Foundation “ Scalability marginally impacts procedure, procedure grossly impacts scalability” - Theo Schlossnagle
  6. 6. You have to plan <ul><li>Performance and resource scalability requires forethought and process </li></ul><ul><ul><li>Version Control </li></ul></ul><ul><ul><li>Performance Goals </li></ul></ul><ul><ul><ul><li>Metric measuring </li></ul></ul></ul><ul><ul><li>Development Mailing Lists </li></ul></ul><ul><ul><li>API documentation </li></ul></ul><ul><li>Awareness is key </li></ul><ul><ul><li>Think about these problems and how you will solve them as your project gets off the ground </li></ul></ul>
  7. 7. Development Infrastructure <ul><li>Every time a client has been in real trouble, they consistently fail to have a development infrastructure </li></ul><ul><ul><li>More then just CVS (although that’s a good start) </li></ul></ul><ul><ul><li>Establishing a development release process early-on is critical to the overall stability of your apps </li></ul></ul><ul><ul><ul><li>Things will go wrong at 3am in production </li></ul></ul></ul><ul><ul><ul><li>You need a process to release code to prevent the very-tempting cowboy-coding </li></ul></ul></ul>
  8. 8. Development Infrastructure <ul><li>Maintaining an existing code base is often the most costly endeavor of any application </li></ul><ul><ul><li>As an application grows, the complexity of it’s release process must scale </li></ul></ul><ul><ul><li>Testing becomes more and more important </li></ul></ul><ul><ul><li>Your release process must be able to scale with your application! </li></ul></ul><ul><ul><ul><li>Staging environments </li></ul></ul></ul><ul><ul><ul><li>Coding Standards </li></ul></ul></ul>
  9. 9. Release Process <ul><li>The Cornerstone of a manageable application is a real release process </li></ul><ul><ul><li>Version Control Tagging of releases </li></ul></ul><ul><ul><li>Atomic File Synchronization </li></ul></ul><ul><ul><ul><li>KISS: Rsync is your friend </li></ul></ul></ul><ul><li>Find a Release Manager </li></ul><ul><ul><li>Only one entity should be able to put code in production </li></ul></ul><ul><ul><ul><li>The PHP Project has one release manager per version </li></ul></ul></ul>
  10. 10. Designing without Scalability <ul><li>If your application does not perform it will likely not succeed </li></ul><ul><ul><li>What does it mean to perform? </li></ul></ul><ul><ul><ul><li>10 requests/sec? </li></ul></ul></ul><ul><ul><ul><li>100 requests/sec? </li></ul></ul></ul><ul><ul><ul><li>1000 requests/sec? </li></ul></ul></ul><ul><li>If you don’t know what it will take to meet your performance requirements, you probably won’t meet them. </li></ul><ul><li>“ If you're very lucky, performance problems can be fixed after the fact. But, as often as not, it will take a great deal of effort to get your code to where it needs to be for acceptable performance. This is a very bad trap to fall into. At its worst, you'll be faced with a memorable and sometimes job-ending quote: 'This will never work. You're going to have to start all over.'&quot; </li></ul><ul><li>Rico Mariani, Architect, Microsoft </li></ul>
  11. 11. Performance Metrics <ul><li>Response Time </li></ul><ul><ul><li>How long does it take for the server to respond to the request? </li></ul></ul><ul><li>Resource usage </li></ul><ul><ul><li>CPU, memory, disk I/O, Network I/O </li></ul></ul><ul><li>Throughput </li></ul><ul><ul><li>Requests / second </li></ul></ul><ul><ul><li>Probably the most useful number to keep track of </li></ul></ul>
  12. 12. Proactive vs. Reactive <ul><li>Common Scenario: Reactive </li></ul><ul><ul><li>Write your app </li></ul></ul><ul><ul><li>Deploy it </li></ul></ul><ul><ul><li>Watch it blow up </li></ul></ul><ul><ul><li>Try to fix it </li></ul></ul><ul><ul><li>If you’re lucky, you might succeed “enough” </li></ul></ul><ul><ul><li>If you’re unlucky….. </li></ul></ul><ul><li>Correct Approach: Proactive </li></ul><ul><ul><li>Know your performance goals up front and make sure your application is living up to them as part of the development process </li></ul></ul>
  13. 13. Everyone has a role in Performance <ul><li>Architects: Balance performance against other application needs </li></ul><ul><ul><ul><li>Interoperability </li></ul></ul></ul><ul><ul><ul><li>Security </li></ul></ul></ul><ul><ul><ul><li>Maintainability </li></ul></ul></ul><ul><li>Developers: You need to know how to measure and how to optimize to meet the goals </li></ul><ul><ul><ul><li>Web-stress tools, profilers, etc. </li></ul></ul></ul><ul><li>Testers: You must be able to validate the application will perform to specification </li></ul>
  14. 14. Designing with Scalability <ul><li>When designing your application, you should assume it needs to scale </li></ul><ul><ul><li>Quick and dirty prototypes often are exactly what gets to production </li></ul></ul><ul><li>It’s easy to make sure your applications have a decent chance of scaling </li></ul><ul><ul><li>MySQL: Design assuming someday you’ll need master/server replication, for example </li></ul></ul><ul><li>Don’t write an application you’ll need three years from now, write an application you need today </li></ul><ul><ul><li>Just think about what you might need in three years </li></ul></ul>
  15. 15. System Scalability
  16. 16. Network file systems <ul><li>Problem: We have a server farm of 10 servers and we need to deploy our code base </li></ul><ul><ul><li>Very common problem </li></ul></ul><ul><ul><li>Many people look to a technology like NFS </li></ul></ul><ul><ul><ul><li>Share one code base </li></ul></ul></ul><ul><li>At least 90% of the time, this is a bad idea </li></ul><ul><ul><li>NFS/GFS is really slow </li></ul></ul><ul><ul><li>NFS/GFS has tons of locking issues </li></ul></ul>
  17. 17. Network file systems <ul><li>So how do we deploy our code base? </li></ul><ul><ul><li>You should always deploy your code base locally on the machine serving it </li></ul></ul><ul><ul><li>Rsync is your friend </li></ul></ul><ul><li>What about run-time updates? </li></ul><ul><ul><li>Accepting File uploads </li></ul></ul><ul><ul><ul><li>Need to be available to all servers simultaneously </li></ul></ul></ul><ul><ul><li>Solutions vary depending on needs </li></ul></ul><ul><ul><ul><li>NFS may be an option for this small portion of the site </li></ul></ul></ul><ul><ul><ul><li>Database is also an option </li></ul></ul></ul>
  18. 18. I/O Buffers <ul><li>I/O Buffers are there for a reason, to make things faster </li></ul><ul><li>Sending 4098 bytes of data to the user when your system write blocks are 4096 bytes is stupid </li></ul><ul><li>In PHP you can solve this using output buffering </li></ul><ul><li>At the system level you can also boost up your TCP buffer size </li></ul><ul><ul><li>Almost always a good idea, most distributions are very conservative here </li></ul></ul><ul><ul><li>Just be mindful of the amount of RAM you actually have </li></ul></ul>
  19. 19. Ram Disks <ul><li>Ram Disks are a very nice way to improve performance of an application, as long as you have a lot of memory laying around </li></ul><ul><ul><li>Use Ramdisks to store any sort of data you wouldn’t care if you lost when the 16 year old trips over the power cable </li></ul></ul><ul><ul><li>A reasonable alternative to shared memory </li></ul></ul>
  20. 20. Bandwidth Optimization <ul><li>You can optimize bandwidth in a few ways </li></ul><ul><li>Compression </li></ul><ul><ul><li>mod_deflate </li></ul></ul><ul><ul><li>Zlib.output_compression=1 (PHP) </li></ul></ul><ul><li>Content Reduction via Tidy </li></ul><?php $o = array(&quot;clean&quot; => true, &quot;drop-proprietary-attributes&quot; => true, &quot;drop-font-tags&quot; => true, &quot;drop-empty-paras&quot; => true, &quot;hide-comments&quot; => true, &quot;join-classes&quot; => true, &quot;join-styles&quot; => true ); $tidy = tidy_parse_file(&quot;php.html&quot;, $o); tidy_clean_repair($tidy); echo $tidy; ?> <?php ini_set(&quot;tidy.default_config&quot;, /path/to/compact_tidy.cfg&quot;); ini_set(&quot;tidy.clean_output&quot;, 1); ?> clean=1 drop-proprietary-attributes=1 drop-font-tags=1 drop-empty-paras=1 hide-comments=1 join-classes=1 join-styles=1
  21. 21. PHP Scalability
  22. 22. Configuring PHP for Speed <ul><li>register_globals = off </li></ul><ul><li>auto_globals_jit = on </li></ul><ul><li>magic_quotes_gpc = off </li></ul><ul><li>expose_php = off </li></ul><ul><li>register_argc_argv = off </li></ul><ul><li>always_populate_raw_post_data = off </li></ul><ul><li>session.use_trans_sid = off </li></ul><ul><li>session.auto_start = off </li></ul><ul><li>session.gc_divisor = 10000 </li></ul><ul><li>output_buffering = 4096 </li></ul>
  23. 23. Blocking calls <ul><li>Blocking I/O can always be a problem in an application </li></ul><ul><ul><li>I.e. attempting to open a remote URL from within your PHP scripts </li></ul></ul><ul><li>If the resource is locked / slow / unavailable your script hangs while we wait for a timeout </li></ul><ul><ul><li>Might as well try to scale an application that has a sleep(30) in it </li></ul></ul><ul><ul><li>Very bad </li></ul></ul>
  24. 24. Blocking calls <ul><li>Solutions </li></ul><ul><ul><li>Don’t use blocking calls in your application </li></ul></ul><ul><ul><li>Don’t use blocking calls in the heavy-load aspects of your application </li></ul></ul><ul><ul><li>Have out-of-process scripts responsible for pulling down data </li></ul></ul>
  25. 25. Failing to Cache <ul><li>Caching is one of the most important things you can do when writing a scalable application </li></ul><ul><ul><li>A lot of people don’t realize how much they can cache </li></ul></ul><ul><ul><li>Rarely is a 5 second cache of any data going to affect user experience </li></ul></ul><ul><ul><ul><li>Yet it will have significant performance impact </li></ul></ul></ul><ul><ul><ul><li>1 data / 2 queries per request </li></ul></ul></ul><ul><ul><ul><li>2 queries * 200 request / sec = 400 queries / second </li></ul></ul></ul><ul><ul><ul><li>400 queries * 5 seconds = 2000 queries you didn’t do </li></ul></ul></ul>
  26. 26. Failing to Cache <ul><li>Improving the speed of PHP can be done very easily using an op-code cache </li></ul><ul><li>PHP 6 will have this ability built-in to the engine </li></ul>
  27. 27. Semi-Static Caching <ul><li>If you're web application has a lot of semi-static content </li></ul><ul><ul><li>Content that could change so it has to be stored in the DB, but almost never does </li></ul></ul><ul><li>.. And you're running on Apache </li></ul><ul><li>This Design Pattern is killer! </li></ul>
  28. 28. Semi-Static Caching <ul><li>Most people in PHP would implement a page like this: </li></ul><ul><ul><li> </li></ul></ul><ul><li>This would be responsible for generating the semi-static page HTML for the browser </li></ul>
  29. 29. Semi-Static Caching <ul><li>Instead of generating the HTML for the browser, make this script generate another PHP script that contains mostly static content </li></ul><ul><ul><li>Keep things like personalization code, but make the actual article itself static in the file </li></ul></ul><ul><ul><li>Write the file to disk in a public folder under document root </li></ul></ul>
  30. 30. Semi-Static Caching <ul><li>If you put them in this directory </li></ul><ul><ul><li> </li></ul></ul><ul><li>You can create a mod_rewrite rule such that </li></ul><ul><ul><li> maps to </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>Since show_article.php writes articles to files, once it's been generated no more DB reads! </li></ul>
  31. 31. Semi-Static Caching <ul><li>Simple and Elegant Solution </li></ul><ul><li>Allows you to keep pages “personalized” </li></ul><ul><li>Very easy to Maintain </li></ul>
  32. 32. Database Scalability
  33. 33. Poor database design <ul><li>Database design is almost always the most important thing in your application </li></ul><ul><ul><li>PHP can be used completely properly, but if you mess up the database you’re hosed anyway </li></ul></ul><ul><li>Take the time to really think about your design </li></ul><ul><ul><li>Read books on designing relational databases </li></ul></ul><ul><ul><li>Understand how Indexes work, and use them </li></ul></ul>
  34. 34. Poor database design <ul><li>For example.. </li></ul><ul><ul><li>Using MySQL MyISAM tables all the time </li></ul></ul><ul><ul><ul><li>Use InnoDB instead if you can </li></ul></ul></ul><ul><ul><li>Use MyISAM tables only if you plan on doing fulltext searching </li></ul></ul><ul><ul><ul><li>Even then, they shouldn’t be primary tables </li></ul></ul></ul>
  35. 35. Improperly dealing with database connections <ul><li>Improperly using persistent database connections </li></ul><ul><ul><li>Know your database, MySQL has a relatively light handshake process compared to Oracle </li></ul></ul><ul><li>Using PHP to deal with database fail over </li></ul><ul><ul><li>It’s not PHP’s Job, don’t do it. </li></ul></ul><ul><ul><li>Design your PHP applications to work with hostname aliases instead of real addresses </li></ul></ul><ul><ul><ul><li>i.e. mysql-r, mysql-w </li></ul></ul></ul><ul><ul><li>Have external processes responsible for switching the /etc/hosts file in the event something blows up </li></ul></ul>
  37. 37. Database connections <ul><li>Bad: </li></ul><ul><ul><li>Code to determine if it is the dev environment or not and a different database is selected in each case </li></ul></ul><ul><li>Suicidal: </li></ul><ul><ul><li>Code to determine if the primary master in a MySQL database is down, and instead attempt to seamlessly roll-over to a hot swap MySQL slave you bless as master </li></ul></ul><ul><li>These don’t work </li></ul><ul><li>These aren’t PHP’s Job what so ever </li></ul><ul><li>These will someday land you on CNN for incompetence </li></ul>
  38. 38. Having your Cake and Eating it too <ul><li>For those of us using MySQL, here’s a great replication trick from our friends at flickr </li></ul><ul><ul><li>InnoDB is under most circumstances considerably faster then MyISAM </li></ul></ul><ul><ul><li>MyISAM is considerably better suited for full-text searches </li></ul></ul><ul><ul><li>Trick: During a master/slave replication, the slave table type can change </li></ul></ul><ul><ul><ul><li>Set up a separate MyISAM fulltext search farm </li></ul></ul></ul><ul><ul><ul><li>Connect to those servers when performing full-text searches </li></ul></ul></ul>
  39. 40. SQLite, Huh? <ul><li>SQLite is a great database package for PHP that can really speed certain things up </li></ul><ul><li>Requires you understanding when and how to use it. </li></ul><ul><li>SQLite is basically a flat-file embedded database </li></ul><ul><li>Crazy-fast reads, horrible writes (full database locks) </li></ul><ul><li>Answer: SQLite is a *great* lookup database </li></ul>
  40. 41. SQL Security <ul><li>Those who do not use Prepared statements should be flogged with a rubber hose </li></ul><ul><li>They are </li></ul><ul><ul><li>Faster </li></ul></ul><ul><ul><li>Easier to maintain </li></ul></ul><ul><ul><li>Considerably more secure </li></ul></ul><ul><li>ALL database write operations should be done through prepared statements, Period. </li></ul>
  41. 42. Web Server Scalability
  42. 43. Know your Web Server <ul><li>When designing an application, it’s very important that you understand how PHP works in the bigger picture </li></ul><ul><ul><li>Know how PHP interacts and responds to your web server </li></ul></ul><ul><ul><li>For instance – How’s PHP really work with Apache 1.3.x? 2.2.x? </li></ul></ul>
  43. 44. Know your Web server <ul><li>Apache 1.3.x works on a pre-fork model </li></ul><ul><ul><li>One parent process spawns a whole lot of child processes </li></ul></ul><ul><ul><li>Each process handles a single HTTP request at a time </li></ul></ul><ul><ul><ul><li>May handle a finite or infinite number of requests before being destroyed </li></ul></ul></ul><ul><ul><li>PHP exists in the context of an Apache Child process </li></ul></ul><ul><ul><ul><li>This means this like “persistent” resources are only persistent to the individual child process </li></ul></ul></ul><ul><ul><ul><li>Database connections total = Process total </li></ul></ul></ul>
  44. 45. Hanging up Apache <ul><li>When scaling an application, requests per second is key </li></ul><ul><ul><li>You should have an idea how long a single request will take </li></ul></ul><ul><ul><li>You should know how many of those requests your server farm can handle at once without dying </li></ul></ul><ul><ul><li>You should know you’re requests-per-second figures </li></ul></ul><ul><li>Too often, people let Apache handle things that it really shouldn’t </li></ul><ul><ul><li>I.e. Large file downloads, etc. </li></ul></ul>
  45. 46. Dynamic vs Static serving <ul><li>When Apache is sending a 10 megabyte file, that means that one of your HTTP children is wasting it’s time shuffling data down the pipe </li></ul><ul><ul><li>This is definitely something that can be handled by something else </li></ul></ul><ul><ul><ul><li>A different HTTP server (tHttpd) </li></ul></ul></ul><ul><ul><ul><li>Zend Download Server </li></ul></ul></ul><ul><ul><li>At any given point in time, you should try to design thing so that your primary server function (serving PHP scripts) is the only thing being done by Apache </li></ul></ul>
  46. 47. Dynamic vs Static serving <ul><li>On the same note, you can use something like thttpd to serve all static content </li></ul><ul><ul><li>Set up a subdomain </li></ul></ul><ul><ul><li>Put all of your images, flash files, javascript libs, stylesheets, etc. on that server </li></ul></ul>
  47. 48. Apache Configuration <ul><li>AllowOverride None </li></ul><ul><li>FollowSymLinks No </li></ul><ul><li>ExtendedStatus No </li></ul><ul><li>Use IPs instead of Hostnames for allow,deny </li></ul><ul><li>Disable HostnameLookups </li></ul>
  48. 49. Keepalive Requests <ul><li>Keepalive sounds great on paper </li></ul><ul><ul><li>It can actually totally hose you if you aren’t careful </li></ul></ul><ul><li>Use Keepalive if: </li></ul><ul><ul><li>You use the same server for static/dynamic content </li></ul></ul><ul><ul><li>You intelligently know how to set the timeout </li></ul></ul><ul><li>No Keepalive request should last more then 10 seconds </li></ul><ul><ul><li>Configure your server appropriately </li></ul></ul><ul><li>If Apache is 100% Dynamic TURN IT OFF </li></ul>
  49. 50. Optimizing Your Application The Art of making it faster without screwing it up
  50. 51. Knowing where to Not optimize <ul><li>Sooner or later, you will worry about scalability </li></ul><ul><li>Hopefully, you didn’t start after your application started blowing up </li></ul><ul><li>When trying to make scalability decisions knowledge is the most important thing you can have </li></ul><ul><li>PHP has both closed source and open source profilers which do an excellent job of identifying the bottlenecks in your application </li></ul><ul><ul><li>Optimize where it counts </li></ul></ul>
  51. 52. <ul><li>Instrumentation of your applications is key to determining what matters most when optimizing </li></ul><ul><ul><li>If you’re not logging, you’re shooting in the dark </li></ul></ul><ul><ul><li>White-box monitoring of your applications via tools like Zend Platform are enormously helpful in understanding what is going on </li></ul></ul><ul><ul><li>You can’t make good process (or business) decisions unless you understand how your web site is being used and by whom. </li></ul></ul>Knowing where to Not optimize
  52. 53. <ul><li>Amdahl’s Law: </li></ul><ul><ul><li>Improving code execution time by 50% when the code executes only 2% of the time will result in a 1% overall improvement </li></ul></ul><ul><ul><li>Improving code execution time by 10% when the code executes 80% of the time will result in a 8% overall improvement </li></ul></ul>Knowing where to Not optimize
  53. 54. Use Profilers <ul><li>Profilers are easy to use </li></ul><ul><li>Profilers draw pretty pictures </li></ul><ul><li>Profilers are good, use profilers </li></ul>
  54. 55. How a Profiler/Debugger works in PHP <ul><li>Profiler / Debuggers in PHP work remotely against the web server </li></ul>
  55. 56. Tips on using a profiler <ul><li>When doing real performance analysis, here are a few tips to help you out: </li></ul><ul><ul><li>Copy the raw data (function execution times) into a spreadsheet and do analysis from there </li></ul></ul><ul><ul><li>Most profilers provide at least two execution figures per function call </li></ul></ul><ul><ul><ul><li>The amount of time spent executing PHP code </li></ul></ul></ul><ul><ul><ul><li>The amount of time PHP spent internally </li></ul></ul></ul><ul><ul><li>That means total = A + B </li></ul></ul><ul><ul><li>If you are spending a lot more time inside of PHP, you’ve got a blocking issue somewhere </li></ul></ul>
  56. 57. Something More.. <ul><li>Do not mistake something more for something better </li></ul><ul><ul><li>Dev: “Hey, let’s build this great ORM that automatically generates it’s views like Ruby!” </li></ul></ul><ul><ul><li>Manager: “Sounds great, go to it” </li></ul></ul><ul><ul><li><4 months pass> </li></ul></ul><ul><ul><li>Dev: “Here’s my two weeks notice, I quit” </li></ul></ul><ul><ul><li>Manager: “Okay John you write it” </li></ul></ul><ul><ul><li>John: “Um, I have no idea what this guy did” </li></ul></ul><ul><ul><li><2 months pass to re-write the module in a way that we can maintain it> </li></ul></ul>
  57. 58. Something More.. <ul><li>Don’t use a sledge hammer when a tack hammer will do </li></ul><ul><ul><li>Devs: Just because your boss doesn’t know the difference doesn’t make it a good idea </li></ul></ul><ul><ul><li>It might seem like great job security to write code only you can maintain, but in reality all it will do is get you fired faster when they figure it out </li></ul></ul><ul><ul><li>Managers: Know enough about the technologies to keep eager developers from leaving you holding the bag. </li></ul></ul>
  58. 59. Binary Optimization <ul><li>If you can, building architecture-specific builds of all of your technology stack is a good idea </li></ul><ul><ul><li>Build Options: -O3 –march, -mcpu, -msse, -mmmx </li></ul></ul><ul><ul><li>– mfpmath=sse, -funroll-loops </li></ul></ul><ul><li>Stripping binaries using the ‘strip’ utility can also significantly reduce the memory footprint of the application </li></ul><ul><li>Also, Most PHP extension aren’t used by PHP scripts </li></ul><ul><ul><li>Compile high-use ones statically into PHP and provide the rest as shared libs </li></ul></ul><ul><ul><li>Only load the shared extensions when they are needed </li></ul></ul>
  59. 60. Binary Optimization <ul><li>One drawback to Binary Optimization </li></ul><ul><ul><li>It’s optimized for that platform </li></ul></ul><ul><li>It’s significantly more annoying to try to manage different PHP versions all built on different hardware </li></ul><ul><ul><li>And then manage the underlying libraries which power PHP </li></ul></ul><ul><li>Don’t forget to optimize shared extensions too </li></ul>
  60. 61. Static compiling <ul><li>If running PHP in Apache you can increase the speed in some cases by 30% just by compiling PHP statically within Apache </li></ul><ul><ul><li>Of course, this increases the footprint of Apache, and each of it’s children (in prefork) </li></ul></ul>
  61. 62. <ul><li>AJAX - Just because I haven’t used many buzzwords in my slides yet </li></ul><ul><li>Let’s imagine that each request sent over the wire is like a car driving from point A (the client) to point B (the server) </li></ul><ul><li>Roads are Networks </li></ul>AJAX Latency
  62. 63. One of the biggest problems with AJAX
  63. 64. One of the biggest problems with AJAX <ul><li>Simple requests seem to work just fine… </li></ul>
  64. 65. One of the biggest problems with AJAX
  65. 66. One of the biggest problems with AJAX
  66. 67. One of the biggest problems with AJAX
  67. 68. One of the biggest problems with AJAX <ul><li>The problem with AJAX has to do with multiple dependent asynchronous requests </li></ul><ul><ul><li>You can’t rely on any order of operations in classical AJAX models </li></ul></ul>
  68. 69. One of the biggest problems with AJAX
  69. 70. One of the biggest problems with AJAX
  70. 71. One of the biggest problems with AJAX
  71. 72. One of the biggest problems with AJAX
  72. 73. Some requests will happen faster <ul><li>When working with AJAX, always know you cannot rely on one request finishing before the next is triggered </li></ul><ul><li>Requests can take different lengths of time based on a huge array of factors </li></ul><ul><ul><li>Server load and Network load come to mind </li></ul></ul><ul><li>Can really mess up your application </li></ul><ul><li>Bad news: None of the current AJAX toolkits account for this latency </li></ul>
  73. 74. Developing with Latency in mind <ul><li>A number of tools exist for developing AJAX applications with latency in mind </li></ul><ul><ul><li>AJAX Proxy is a good example </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul><ul><ul><ul><li>Allows you to simulate latency in your requests </li></ul></ul></ul><ul><ul><li>You can use it in conjunction with “SwitchProxy” to point your browser at a different proxy server to use it </li></ul></ul><ul><ul><ul><li> </li></ul></ul></ul><ul><li>Not a true solution, but at least let’s you test for the problem. </li></ul>
  74. 75. Final Thoughts Final Thoughts <ul><li>Ultimately the secret of scalability is developing applications and procedures which scale both UP AND DOWN </li></ul><ul><li>You have to be able to afford to make the application to begin with </li></ul><ul><li>You have to be able to afford to make the application ten times bigger then it is </li></ul><ul><li>Without process, you will fail. </li></ul><ul><li>REMEMBER: In ANY application, there is only ever one bottleneck </li></ul>Questions?