Application Performance, A Never Ending Journey
Category : Development
Application performance has always been a concern even as hardware and memory got cheaper over the past decades. Does it really matter when you can containerize pretty much everything and even run a container per user when they are online? The answer to that is yes. Dynatrace, Newrelic and other Application Performance Monitoring providers all have those markets covered as well. So, where do we start?
As the saying goes, a good craftsman never blames his tool. You could look at this in a couple of different ways. You make it work with what you have leveraging your expertise. You choose the right tool for the work when you have the option. Once the tool is chosen, complaining about it without the proper course or change of course of action only reveals the poor craftsmanship.
If all that you have is a rock, you could still make a spear out of it. It does not mean you ignore all the inventions and discoveries that came afterwards and get stuck between a rock and a hard place.
No one has unlimited access to resources. Even if you have, it does not guarantee the performance. As explained by Amdahl’s law, the lowest performing link would limit your ability to achieve the output you want by merely scaling. It is just like trying to use a flour sieve to fill a container with water. Design your application for the task it is intended for.
As an example, if your application needs to process a lot of documents, parse them and index them, it may be better to scale that aspect of it without affecting the performance of the system. If you are buying a platform, see if the platform can easily support the scaling as shown below. If not, you need to plan for it with the tool that you have. Search engines themselves are capable of parsing, indexing and storing the documents.
Quite often a system may support an external search engine but may not support externalization of document parsing. Depending on your use case, this may or may not be an issue.
Session vs Cache vs In memory Systems
Session was a great thing once upon a time. Everyone was excited about storing user interactions, data etc on a per user basis and replicating that across servers to provide a seamless failover. This architecture requires that you scale your servers vertically. Just like air fills the container, work expands to fill the time, the objects soon filled the memory. The advent of stateless architecture changed the way we viewed user interactions.
I have seen implementations where developers stored common datasets in a per user session. The data that was stored quickly filled the memory as more users logged in. A cache that can be shared across user sessions is a better option since most of that data was a read-only data. A lot of the systems are optimized at various levels. A database has its own caching mechanism. A second-level cache is supported by various systems. Some frameworks offer a third-level caching of complex objects. So, where do you start and stop? A one-size fits all may not be the option where the problems are unique.
I used the term In-memory systems to include a wide range of systems out there. It could be an in-memory database, search engine or any system that can be used to easily store and access data and has a persistent store from which you can rebuild the memory. This could be a very good alternative to the other two means.
Upfront vs Continuous Process
Sometimes you have the luxury to continuously improve your system. If you have that luxury, that works very well with the Return On Investment (ROI). You could measure every optimization that you perform and keep improving.
You may not have that luxury sometimes. Your application needs to support certain use cases and a certain number of people. If it fails to do so on day one, it may fail to gain the trust of the users.
Design diligently. Perform the benchmark via load testing. The benchmark is a little trickier because you cannot expect the users to follow your load test use cases.
What about all the performance tuning, properties tweaking, environment settings adjustments etc? All these are useful but never substitute for a poorly designed system. You use the performance tuning as a checklist for the system that you are running. If your system was designed for a certain altitude, a mere tuning may not take you to the next height.
Don’t blame the tool. Use the right tool if you can find one. Don’t blame the design of a framework. Understand how it is designed and see if that is the one for you. If you are a team of experts and you know what you are getting into, you could make it work. If you are not a team of experts, find an expert.. Do the due diligence. If you would be happy to claim the success, don’t be afraid to take the blame and make it right.