🎃🎃🎃 Did your application performance haunt you this Halloween? 🎃🎃🎃

We design, architect, code, implement and deliver the robust solution to the most complex problems. The solutions get older, matured and… -

🎃🎃🎃 Did your application performance haunt you this Halloween? 🎃🎃🎃


picture credit: trendycovers.com

We design, architect, code, implement and deliver the robust solution to the most complex problems. The solutions get older, matured and more complex in the multi-tenant environment. And at some point, the solution in-turned application (web/mobile/native) struggles to achieve the peak performance and maintains it in its lifetime. When you hit the performance bottleneck, the first question comes to your mind-

> Where do we start from?

And it’s the question and should come to you because the performance is not related to the stacks as you can not say —

Stack 1 is more performative than Stack 2 or we optimized this stack and now the problem is with another stack.

Your job is not done until you hear the similar from your customer —

> It feels light (lighter)! or It’s fast (faster) ! or No more click and wait!

And let me tell you, it’s not that difficult to achieve. The performance only requires you to do what you are doing —

> but do it right!

Keeping it short this time and I want to discuss “Get Started” list in the process of optimizing the performance. I will refrain from providing steps to optimize your web-app as it is subjective to the deployment and you can not generalize it for all the kind of deployments other than “DOING IT RIGHT”

Start with your users, traffic and know more about your deployment and user’s behavior —

You can not solve an unknown problem, so start with removing as many unknowns as possible, start with a lot of data. The data can be sourced from customer’s feedback, geographical traffic stats, server stats, peak hours, database connections dump, server and client profiling data and your click thorough timings. One of the most important sources of data that I would RECOMMEND to find and rely on app server monitoring tools (see list below) and client-side profiling.

Steps by steps —

1. Client-side:


Start by collecting data from your client-side performance profiling, timeline, and auditing — I found Chrome [Performance](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference) and [Audit](https://developer.chrome.com/extensions/experimental_devtools_audits) as a great resource in analyzing client site DOM rendering, JS heap, scripting and Async calls.

> NEVER start optimizing your server side implementation until you have full faith in your client side implementation…

Few quickies that I recommend to be very helpful —

i. Minimize the traffic and reduce your http/https connections and calls.

ii. Parallelize the client side requests to different domains depending on your resource type (dynamic/static/assets etc — ).

iii. Implement HTTP caching — Cache Headers are your best friends here, know them well, they will treat you great!

iv. Evaluate client-side VS server-side page rendering, I recommend to have client side as your first choice (if you can) and you will see the difference. I would not say to go and blindly start using React (+/- Redux), Angular, Backbone, Ember or any UI side framework with an assumption of getting a great web-app performance BUT have a well-structured client-side framework (in-house or one of the above).

2\. Server-side: Start by collecting data from your server transnational traces (web/database) collected from app server monitoring tools like [New Relic,](https://newrelic.com/) [AppDynamics](https://www.appdynamics.com/), [Datadog](https://www.datadoghq.com/) or your in-house monitoring tool. These tools are of great help in providing you the real-time insights of your app behavioral as per your user interactions with the timelines.

i. Caching: Ignore me, I believe in you as you are already doing it! Listen to yourself, if you are not! I will not get into details on how to implement a caching infrastructure using [Redis](https://redis.io/), [Memcached](https://memcached.org/) or your homegrown. The one strategy, I recommend here is [Russian doll caching](https://signalvnoise.com/posts/3690-the-performance-impact-of-russian-doll-caching). The Russian doll caching gives you immediate performance visibility but it requires a well thought through architecture for the partials/views that you build as part of cache components. The recommendation, I make here is to have your cache components’ dependency injected during the part of your component creation and that you can easily warm-up the cache whenever there is a cache invalidation.

The cache invalidation strategy is the important one here, and now with, time to live (TTL; key expiration) values of the keys, you have more control over your keys. The TTL value helps to evict the key automatically when it expires and you hit the cache for the warm-up but if you want your keys not to expire, then Redis/Memcached will automatically evict the oldest key. Caching itself is an entire topic to write about but look, we are in 2017 and I believe, we just need to talk and share about it with the experience as the application frameworks are already doing a great job helping around the caching.

ii. Know your deployment: Very important, how many server-side resources, you are allocating to the application, check your server tuning. Depending on your deployment, it will vary but make sure, your server is spending a minimum time in swapping. If you are using Apache server, tune your [MaxRequestWorks](https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers) (for earlier versions, it was named as MaxClients).

The other strategy, I recommend being useful —

> Start with evaluating the latest stable version first!

It is to have your deployment components to the latest stable versions (server, database, broker, middle-wares etc-). Most of the times, the configuration that you investigate or plan for the deployment, they happen to be already optimized in the later versions.

iii. Understanding requests and the importance of the background/batch processing: Deal your web request with an SLA and adhere to that SLA for maintaining a better Quality of Service (QoS). What the hell, does it mean? Let’s pick up an example, your page is rendering few partials and each view is associated with the few workflows e.g. sending an email, taking back-up, tracing the request, crunching the bits for the other integrated modules etc — If you are completing this heavy lifting workflow in the active and current web requests, there will be a busy client wait. With the 2017 trend (it started much earlier), you need to record your client behavior and take some real-time actions. Which means you have to deal with a lot of data in the real time.

And if you are loading your partials with the multiple async requests, there will be clients’ resource consumption (heavy memory footprint on the client side) that will lead to the not-so-pleasant client experience.

Here we meet our new friends — the real-time computation frameworks, message brokers, threads, workers, job schedulers and pub-subs. For the starters, I recommend evaluating [Http/2](https://http2.github.io/) that has a great deal in saving the connections and assets loading of the round trips from the browser. - Divide and delegate the work from your request to the workers and batch processors. - Schedule jobs for the later run if the job is not time-critical and it can be honored. - Process in the batches while traversing the request in the app.

iv. Database layer: It is the soul of your web application and often overlooked in absence of experience database developers. The following points, I recommend here —

a). Avoid sub-queries in the select

b). Avoid full table/full table index scan

c). Avoid multiple round trips to the database

d). Evaluate your unions/joins for the complex queries

And above all, take time in designing your database tables, schema, and proper indexes. Often due to the rapid development and commitments, we rush to create columns and tables without properly deciding on the indexes and constraints.

#### I hope, you are not haunted this year and will not be haunted as you are —

> “DOING IT RIGHT!”

Originally published at [www.linkedin.com](https://www.linkedin.com/pulse/did-your-application-performance-haunt-you-halloween-gaurav-nigam/).