The Performance Engineering Blog

A curious case of continuous Full GC’s with G1GC Introduction Continuing on the previous articles where I had explained about tuning a JVM and the parameters involved, this article specifically deals with a curious case of the same JVM dumping out some unexpected messages in the logs during internal tests, the investigation and the final outcome.  Readers are expected to browse through the previous articles to get a better context of what is being discussed here.  The performance test environment consists of a replica of the entire setup in an exact similar architecture to what is deployed in production.  The test engineers do extensive tests in different conditions to simulate production conditions and to understand the behavior of the application in various conditions.  For first time readers let me (re)introduce the application under discussion -  This particular application is responsible for Indexing and Search for the entire data that lives in the system.  The design

  Introduction After all the comments and the feedback from the community which has been much encouraging, this is the second article in the engineering series also aimed at tuning the JVM.  In the first one we had delved deep in to tuning G1GC which can get complex at times depending on the application design and its intended usage.   Background In this article today, we will try to look at simple case of an application running Parallel GC which is primarily used for UI navigation of a complex micro service based system.   Here we are using the terms simple and complex which might sound contradicting, but just to give a birds eye view, this application is primarily used for UI side navigation with internal API based communication with all the supporting micro services.   So, this design is light weight and the heavy lifting is done by the services themselves, so the throughput is quite high and responsiveness is very important. In this context, the immediate thought that would cro

Introduction This series of articles will introduce the reader to explore more about Performance Engineering, specifically how to deal with actual issues of the product in a production deployment scenario.   This is the most discussed area and most of the people I have interacted with look forward to getting in to this role and deal with actual issues and make their contribution.   This work requires knowledge and understanding from a multitude of aspects like –        The product design         Usage profile of the product         CPU and Memory and Disk configuration of the platform         Software configuration – Memory settings         Connected software components and their impact The reader is expected to look at the problem holistically to make the best use of the resources being deployed and then tune the application to obtain the required performance.   As this spans a multitude of areas, extensive knowledge of all the areas is necessary and this comes mostly by experie

Introduction This series of articles will introduce the reader to the arena of Performance Engineering.   After my first two blog articles which provided a 35000 feet of what is Performance Engineering is all about, I am sure most of you would be intrigued to understand more about it.   This series of articles should help you get started (in case you would want to take a dive) or would act as a refresher to many who are already in to this domain.   This series aims to discuss the testing aspect of Performance Engineering, how it is done, why it is done and what are the key take away points. Let’s race away by trying to answer the relevant questions What is a load test and why is it needed? After the advent of the internet and specifically the dotcom revolution bought the entire world close to being online.   Applications which were erstwhile desktop started getting connected via the internet.   With extensive development and advancements in the connection technologies, the idea of

  Introduction Performance engineering (erstwhile Performance Tests, Load tests) and Site Reliability Engineering are the two most commonly interchangeable terms currently being used in the current software industry.  Although the gap between them is quite narrowed down but if looked at a microscopic level, these two are totally different fields in their own sense. Let’s try to look at each one of them in some detail today in this blog.   This will be an extension to my previous blog post and might sound repetitive a bit from a Performance Engineering standpoint, but for keeping this post complete, some of the information is reused here.   Performance Engineering From the dotcom revolution in the early 2000’s the requirement to ‘test’ websites became a need of the hour and lot of dedicated commercial / proprietary tools took the world by storm.  There was a time when the terms Load Runner / Silk Performer were synonymous to Load tests.  Due to the presence of dedicated teams, the test

  Introduction This post will help you understand what performance engineering is all about, its basics is and how it goes about in the industry. Let’s get started! This is how Wikipedia defines performance engineering Performance engineering  encompasses the techniques applied during a  systems development life cycle  to ensure the  non-functional requirements  for performance (such as  throughput ,  latency , or  memory  usage) will be met. It may be alternatively referred to as  systems performance engineering  within  systems engineering , and  software performance engineering  or  application performance engineering  within  software engineering . The Basics We all in the IT / Computer Engineering / Software industry have seen how the applications evolved over the years and the way in which their usage has changed. The first phase of evolution of an application after development is ‘Testing’ or QA.   This usually means testing the application for defined functionalities whic