#performance engineering
9 posts

Simple Java performance tuning tips

Use primitive types rather than wrapper classes wherever possible to minimize overheads as they are stored to the stack and not the heap.
Read more

Simple Java performance tuning tips

  • To start optimizing your app, use a profiler to find the real bottlenecks in the code and then create a performance test suite for the whole application based on that information. Run your tests before and after every attempt at optimization.
  • Use primitive types rather than wrapper classes wherever possible to minimize overheads as they are stored to the stack and not the heap. Avoid BigInteger and BigDecimal as they dramatically slow down calculations and use a lot of memory.
  • If your app uses a lot of replace operations and you aren’t updated to the latest version of Java, consider the Apache Commons StringUtils.replace method rather than String.replace. You can make the change easily by adding a Maven dependency for Apache’s Commons Lang to your app’s pom.xml to replace all instances.
  • Cache especially your more expensive resources or most-used snippets of code, such as database connections or the valueOf method for the Integer class. However, you are creating an overhead and you may need to manage the cache to keep it accessible and remove outdated information, so be sure the tradeoff is worthwhile.

Full post here, 9 mins read

How to optimize your website speed by improving the backend

Normalize relational databases at the design stage itself and ensure effective indexing so the indexes don’t slow down your website. In some cases, denormalization is more effective though - where there are many table joins, adding an extra field to one table may be better
Read more

How to optimize your website speed by improving the backend

  • The N+1 query problem slows down many apps when several queries are issued to linked fields in a database. You can use the ActiveRecord ORM tool in Rails that employs eager loading of all associated elements with a single query to help solve this problem.
  • Normalize relational databases at the design stage itself and ensure effective indexing so the indexes don’t slow down your website. In some cases, denormalization is more effective though - where there are many table joins, adding an extra field to one table may be better or adding calculated values you need often to a table can help if you frequently execute complicated calculations.
  • Cache carefully to speed up your site. For SQL caching in Rails, use low-level caching to store query results for a longer time. In general, prefer fragment caching of page blocks for dynamic web apps, use page caching in Rails with the actionpack-page_caching gem, but avoid it if your web has frequently updated content like news feeds. For authentication actions and error messages, use the actionpack-action_caching gem.
  • Use a content delivery network (CDN) of edge servers to cache static content like images, JavaScript, and CSS files for reduced latency across geographies, reduced operational costs compared to handling your own servers, stability and scalability.

Full post here, 11 mins read

Embracing the chaos of chaos engineering

You start with a hypothesis and you make an educated guess of what will happen in various scenarios, including deciding on your steady-state. Then you introduce real-world events to test your guesswork.
Read more

Embracing the chaos of chaos engineering

  • You start with a hypothesis and you make an educated guess of what will happen in various scenarios, including deciding on your steady-state.
  • Then you introduce real-world events to test your guesswork for hardware/VM failure, state inconsistency, running out of processing power or memory or time, dependency issues, rare conditions, traffic spikes, and service unavailability.
  • After that comes doing test runs in production on the properly pretested codebase (though be cautious of doing this to safety-critical systems such as banking) and then complete your hypothesis based on how real-world events affect your steady-state.
  • You should communicate your results not only to engineers but also to support staff and community managers who face the public.
  • Use different tools to run your experiments and ensure you have alerts & reporting systems in place to minimize potential damage. Abort quickly if needed.
  • Once you have defined ideal metrics and potential effects, increase the scope of testing by changing the parameters or events you test each time, applying fixes as you go till you find the points where the system really starts to break down.

Full post here, 6 mins read

Want to debug latency?

Latency is a critical measure to determine whether our systems are running normally or not. There are many collections libraries available that help you collect latency metrics.
Read more

Want to debug latency?

  • Latency is a critical measure to determine whether our systems are running normally or not.
  • There are many collections libraries available that help you collect latency metrics.
  • Heat maps are useful as they help visualize latency distribution over time.
  • After narrowing down the source of the latency to a service or process, look at the host-specific and in-process reasons why latency occurred in the first place.
  • If the host is behaving normally and networking is not impacted, go and further analyze the in-process sources of latency.
  • Some language runtimes like Go allows us to internally trace runtime events in the lifetime of a request.

Full post here, 6 mins read

Four load testing mistakes developers love to make

Being too focused on what you set out to test and ignoring any other warning signs while testing is a common mistake developers make. Reusing test data is another common mistake.
Read more

Four load testing mistakes developers love to make

  • If you run a short load test and it works fine, it is no guarantee that your service can handle that load for a long time. You should run your performance tests for more time and understand your system’s performance characteristics.
  • Being too focused on what you set out to test and ignoring any other warning signs while testing is a common mistake developers make. It’s good to pay attention and investigate unusual results or changes in your application’s behaviour as you increase load.
  • Reusing test data is another common mistake. You should either generate new data or spin up a new environment for each test.
  • Assuming the production environment is perfectly healthy permanently. Deliberately make things to go wrong during your load test to find out how your service will perform if such failures happen.

Full post here, 7 mins read