Improving performance–a Full stack problem

Improving performance–a Full stack problem

March 6 by Ronald 4 Comments

Improving the performance of a web system involves knowledge of how the entire technology stack operates and interacts. There is many simple and common tips which can provide immediate improvements for a website. Some examples include:

• Using a CDN for assets
• Compressing content
• Making fewer requests (web, cache, database)
• Asynchronous management
• Optimizing Your SQL statements
• has more memory
• Using SSD ' s for database servers
• Updating Your software versions
• Adding More Servers
• Configuring your software correctly
• ... And the General checklist goes on

Understanding where to invest your energy first, knowing "what the return" on investment can, and most importantly the Measurement and verification of every change made is the difference between blind trial and error and a solid plan and PR Ocess. Here are a great example for the varied range of outcome to the point about "Updating your software versions".

On one project the MySQL database is reaching saturation, both the maximum number of database connections and maximum Number of concurrent InnoDB transactions. The first is a configurable limit, the second were a hard limit of the very old version of the software. Changing the first configurable limit can have dire consequences, there are a tipping point, however that is a different di Scussion. A simple software upgrade of MySQL which had many possible improvement benefits, combined with corrected configuration spe Cific for the new version made an immediate improvement. The result moved a production system from crashing consistently under load, to at least barely surviving under load. This is a important first step in improving the customer experience.

In the PHP application stack for the same project the upgrading of several commonly used frameworks including Slim and TWI G by the engineering department seemed like a good idea. However applicable load testing and profiling (after it is deployed, yet another discussion point) found the impact was a 30-40% increase in response time for the application layer. This made the system worse, and cancelled out prior work to improve the system.

How to tune a system to support 100x load increase with no impact in performance takes knowledge, experience, planning, TE Sting and verification.

The following summarized graphs; Using New Relic monitoring as a means of representative comparison; Shows three snapshots of the average response time during various stages of full stack tuning and optimization. This was a very simplified graphical view that's supported by more detailed instrumentation using different products, spec Ifically with much finer granularity of hundreds of metrics.

These graphs represent the work undertaken for a system under peak load showing an average 2,000ms response time, to the S AME workload under 50MS average response time. That's a 40x improvement!

If your organization can benefit from these types of improvements feel free to contact Me.

There is numerous steps to achieving. A few highlights to show the scope of work of your need to consider includes:

• Knowing server CPU saturation verses single core CPU saturation.
• Network Latency detection and mitigation.
• What is the virtualization mode options of Virtual cloud instances?
• Knowing the network stack benefits of different host operating systems.
• simulating production load is much harder than it sounds.
• Profiling, Profiling, Profiling.
• instrumentation can be misleading. Knowing how different monitoring works with sampling and averaging.
• Tuning The stack is an iterative process.
• the simple greatest knowledge are to know your code, your libraries, your dependencies and how to optimize each specifi C Area of your technology stack.
• Not everything works, some expected wins provided no overall or observed benefits.
The
• there is always more than that can being done. Knowing when to pause and prioritize process optimizations over system optimizations.

These graphs show the improvement work on the application tier (1500ms to 35ms to 25ms) and the database tier (500ms to 12 5ms to 10ms) at various stages. These graphs do not show for example improvements made in DNS resolution, different CDNs, managing static content, Differe NT types and ways of compression, remove unwanted software components and configuration, standardized and consistent stack Deployments using chef, and even a reduction in overall servers. All of these successes contributed to a better and more consistent user experience.

src:http://ronaldbradford.com/blog/improving-performance-a-full-stack-problem-2015-03-06/

Improving performance–a Full stack problem