Topics In Demand
Notification
New

No notification found.

“Performance Engineering Without Technology Stack Change”
“Performance Engineering Without Technology Stack Change”

September 5, 2022

135

0

The famous picture of ‘1 second happenings on Internet’ tells you the range of transactions happening on web and mobile applications per second. To achieve this, performance engineering of an application becomes an absolute need. Now there are different segments here why we see performance engineering is not considered at the initial development stage.

  1. A startup platform with very quick go to market strategy will worry volume after they create enough investor interest and hence plan the actual performance tuning as second half of the project.
     
  2. The application which is running successfully on legacy technology and facing performance challenges now since volume is doubled.

Considering both the above scenarios came out from a practical business reason, let’s explore how to address the performance challenges where revamping of technology stack is not an option.

  1. The no brainer which a tech lead or even a developer can check is the no. of occurrences of console level print statements. Even though everyone will initially claim that they have 0 console printing statements running on production, this is the first check point and with no surprise one will find plenty. The conversion of console statements into loggers with different logical levels will change the performance drastically.
  2. One can start with proper performance engineering process after step 1 where profiling of the code can be done. This will help in identifying bottlenecks.
  3. Now here there are following layers where one can find issues
    1. UI
    2. Middle layer
    3. Database layer
       
  4. Design: In all the above 3 layers there could be again 2 level problems. The first one is with ‘design’ and or second one could be the ‘standards’. Let us talk about the ‘design’ level issues within these 3 categories.


Database:

      • The database design involving too much of normalization can cause problems if the look up queries are traversing the entire nested structure. So possible de normalizations can be done studying the search queries applied
      • The usage of strings as primary keys should be avoided as far as possible.
      • Understanding the need of indexes and applying the same properly
      • Data storage strategy should be decided and heavy storage in single table should be avoided if possible. The possibility of summary tables can be explored.
      • Data types should be used properly considering performance aspect.
      • Usage of objects like stored procedures, functions can be done intelligently wherever needed.
      • The load on database should be designed in such a way that inserts and views are separated using replication databases.
         

Middle layer:

      • Effective caching : Here which caching tool or technique to be used is another subject to be explored and we can touch base on that in the discussion ahead but importantly separation of data using cache and real time updates , inserts and views have to be handled at design phase. While designing the cache it is important that cache update scenarios should be considered in depth. Also possibilities of cache fusion should be avoided as that is not a good long term approach. The possible Caching implementations could be hibernate cache , redis cache or simple collection classes in case the programming language used is Java or C #
         
      • CDN: Content Data networks are very popular and latest caching tool which can be used effectively where the data is non-textual like images or videos or audio formats.
         
      • Data chunking in case of bulk returns to UI: Wherever paginations are used on UI, data can be designed to send in chunks.
         
      • Connection pools: Connection pools to be used for database or any other data source connectivity. Typically application servers provide effective configurations for connection pooling which can be used or in case of customized pools effective design principles of the same should be used.
      • Looping, Iterations: This again should be as low as possible. While doing this best practices should be followed and there should be right choice of collections classes.

UI:

      • The availability of asynchronous java script calls via different frameworks helped the UI performance improvement to greater extent. However if the stack does not use Ajax calls and simply using server components at UI layer then again use of customized Java script within that can be evaluated .
      • Also data management on UI needs to be thought through where there are complex data representations like nested graphs, nested grids. Here effective data packaging with the help of right events is necessary.
      • There should be tradeoff between loading data once and making periodic server trips. This totally depends on data representation requirement on UI.
      • Pagination: This is a must where even simple grids fetch in large amount of data.
      • Image displays: The webp image format is the most compressed and effective format which is can be used in most of the applications. The real time conversions should be avoided here and pre converted image files can be placed on the server in case original images are of different formats.
         
  1. Standards: Compliance to best practices or standards while coding at all 3 levels play an important role in performance improvement. Common examples are minimum usage of String manipulations,’ like’ queries etc.

 

Author-
Sambprasad Kuvalekar
Managing Director, Prismatic Softwares Pvt. Ltd.


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.