Avoid performance issue with JsonSerializer by reusing the same instance

.NET Core 3.0 introduced a json serializer in the System.Text.Json namespace to replace Newtonsoft.Json in high performance scenario. You’ll find many benchmark on other website showing the performance gains when switching to S.T.Json.

However, you can find some issue on GitHub that shows that the JsonSerializer is less performant or leads to memory leaks. This can be the case when not used as expected. In this post, I’ll show you why it is important to reuse the JsonSerializerOptions instance whenever it’s possible to avoid a performance penalty.

// The following code reuse the default options instance which is automatically cached
public void Serialize_DefaultOptions()
{
    for (var i = 0; i < 10_000; i++)
    {
        JsonSerializer.Serialize(_data);
    }
}

// The following code reuse the same options instance
public void Serialize_CachedOptions()
{
    var options = new JsonSerializerOptions { WriteIndented = false };
    for (var i = 0; i < 10_000; i++)
    {
        JsonSerializer.Serialize(_data, options);
    }
}

// ❌ Do not use the following code
// The following code doesn't reuse the options
public void Serialize_NewOptions()
{
    for (var i = 0; i < 10_000; i++)
    {
        JsonSerializer.Serialize(_data, new JsonSerializerOptions { WriteIndented = false });
    }
}

#.net #security

What is GEEK

Buddha Community

Avoid performance issue with JsonSerializer by reusing the same instance

Avoid performance issue with JsonSerializer by reusing the same instance

.NET Core 3.0 introduced a json serializer in the System.Text.Json namespace to replace Newtonsoft.Json in high performance scenario. You’ll find many benchmark on other website showing the performance gains when switching to S.T.Json.

However, you can find some issue on GitHub that shows that the JsonSerializer is less performant or leads to memory leaks. This can be the case when not used as expected. In this post, I’ll show you why it is important to reuse the JsonSerializerOptions instance whenever it’s possible to avoid a performance penalty.

// The following code reuse the default options instance which is automatically cached
public void Serialize_DefaultOptions()
{
    for (var i = 0; i < 10_000; i++)
    {
        JsonSerializer.Serialize(_data);
    }
}

// The following code reuse the same options instance
public void Serialize_CachedOptions()
{
    var options = new JsonSerializerOptions { WriteIndented = false };
    for (var i = 0; i < 10_000; i++)
    {
        JsonSerializer.Serialize(_data, options);
    }
}

// ❌ Do not use the following code
// The following code doesn't reuse the options
public void Serialize_NewOptions()
{
    for (var i = 0; i < 10_000; i++)
    {
        JsonSerializer.Serialize(_data, new JsonSerializerOptions { WriteIndented = false });
    }
}

#.net #security

Carmen  Grimes

Carmen Grimes

1595505720

How to Test Mobile App Performance: 3 Key Components - DZone Performance

You’ve probably interacted with an app on your phone or tablet that’s slow, takes a long time to load, freezes, or even crashes on you altogether.

Frustrating, right?

On the flip side, you can probably think of an app that you love to use because from day one, it’s never given you any trouble.

Or maybe you never paid any mind to an app that works quickly, because isn’t that how it’s supposed to be?

So, what causes one app to be crash-prone and another, fast, and reliable?

Whether an app has good or bad performance depends on three factors: the backend, the network, and the app itself running on the device.

A developer or mobile tester can measure the performance of an application in different scenarios.

For example, they can test for when there’s a concurrency of users on the app at the same time, on different devices (which vary in hardware resources and screen sizes), and multiple networks such as 3G, 4G, Wifi, and more.

The reality is that many variables affect the performance of a mobile application. Moreover, a user may have a very bad experience with your app and the cause might not even have anything to do with the code or its implementation.

But, by running performance tests for each of these three factors, you’ll be able to identify problems and optimize your app for the best user experience possible.

Keep reading as we’ll cover the different types of tests for each factor, what to measure, and what tools are available to help you along the way.

1st Mobile Performance Factor: The Backend

A mobile app’s backend architecture is generally based on an application server, a web server, and a database.

**When it comes to the backend, the things related to performance that are important to know when an app is under load are the server’s response times, database queries times, and the server’s resource usage. **

Using this information, it’s easier to detect issues such as:

  • High server response times
  • Bottlenecks or breakpoints in the database and application server resources
  • Poor implementation of escalation policies

So what kind of tests are normally run to check the app’s backend performance? Load tests.

This is when you simulate load on the backend in different ways, whether it be through stress testing, peak testing, endurance testing, load testing, etc.

In general, the objective of these tests is to understand how the backend systems of an app behave and handle a certain volume of concurrent users.

Several tools allow you to load test your mobile app. The most commonly used ones include:

Apache JMeter – the number one open-source load testing tool

Gatling– a developer-friendly, open-source load testing tool with scripts written in Scala

BlazeMeter – a cloud performance testing platform that scales your JMeter or Gatling tests for a greater amount of concurrent users

2nd Mobile Performance Factor: The Network

With regards to the network that the device is connected to, there are two key things to measure: latency and bandwidth.

  • Latency is the time that elapses when information is sent on the network (measured in milliseconds).
  • Bandwidth is the maximum capacity (the amount of data) that can be transmitted through the network (measured in bits per second).

For mobile performance, the lower the latency and the higher the bandwidth, the better.

An app’s performance can vary depending on, for example, whether it’s connected to a 3G network or a 4G network, and unfortunately, this is beyond an app developer or tester’s control.

But, it is possible to incorporate the network during the mobile app performance testing process, simulating the different types of networks and measuring their impact on the response times, both on the server-side and the client-side.

#tutorial #performance #mobile apps #load testing #mobile testing #mobile app performance #client side performance

Samanta  Moore

Samanta Moore

1623417960

Avoid Method Chaining When Using Multiple AutoCloseable Instances

Keep API design in mind.

The try-with-resources statement introduced in Java 7 allows us to adopt an approach where certain objects could be opened, being visible in the try block, and immediately closed when the execution reaches the end of that scope. This was a huge improvement for managing scarce resources, in comparison with the old approach of overriding the finalize() method (which we never exactly know when will be executed.)

Over the years, I was repeatedly seeing the following approach on some applications, which motivated me to write this post. Consider this code snippet for executing an SQL statement using JDBC:

Java

1

import javax.sql.DataSource;

2

import java.sql.*;

3

...

4

  public BigDecimal getSum(long empId) throws SQLException {

5

    String sql = "select sum(salary) from payroll where empId=?";

6

    try(PreparedStatement stmt = myDataSource.getConnection().prepareStatement(sql)) {

7

      stmt.setLong(1, empId);

8

      try(ResultSet rs = stmt.executeQuery()) {

9

        if (rs.next())

10

          return rs.getBigDecimal(1);

11

        return BigDecimal.ZERO;

12

      }

13

    }

14

  }

15

...

What the code does is unimportant, but the connection handling is very important. The outer try-with-resources ensures that at the end of its block, the PreparedStatement will be closed. The same thing goes with the ResultSet in the inner try-with-resources.

Here is the catch: the Connection object returned from the DataSource will never be closed. Since it was not bound to any variable inside the try-with-resources, according to the JLS (see References), the resource in the outer try-with-resources is of type PreparedStatement. As a result, the Connection instance is not participating in the statement, and so its close() method is never called.

The solution is easy: declare a variable referencing the resource you want to be auto-closed.

#java #java resources #multiple autocloseable instances #avoid method chaining #using multiple autocloseable instances

Joe  Hoppe

Joe Hoppe

1595905879

Best MySQL DigitalOcean Performance – ScaleGrid vs. DigitalOcean Managed Databases

HTML to Markdown

MySQL is the all-time number one open source database in the world, and a staple in RDBMS space. DigitalOcean is quickly building its reputation as the developers cloud by providing an affordable, flexible and easy to use cloud platform for developers to work with. MySQL on DigitalOcean is a natural fit, but what’s the best way to deploy your cloud database? In this post, we are going to compare the top two providers, DigitalOcean Managed Databases for MySQL vs. ScaleGrid MySQL hosting on DigitalOcean.

At a glance – TLDR
ScaleGrid Blog - At a glance overview - 1st pointCompare Throughput
ScaleGrid averages almost 40% higher throughput over DigitalOcean for MySQL, with up to 46% higher throughput in write-intensive workloads. Read now

ScaleGrid Blog - At a glance overview - 2nd pointCompare Latency
On average, ScaleGrid achieves almost 30% lower latency over DigitalOcean for the same deployment configurations. Read now

ScaleGrid Blog - At a glance overview - 3rd pointCompare Pricing
ScaleGrid provides 30% more storage on average vs. DigitalOcean for MySQL at the same affordable price. Read now

MySQL DigitalOcean Performance Benchmark
In this benchmark, we compare equivalent plan sizes between ScaleGrid MySQL on DigitalOcean and DigitalOcean Managed Databases for MySQL. We are going to use a common, popular plan size using the below configurations for this performance benchmark:

Comparison Overview
ScaleGridDigitalOceanInstance TypeMedium: 4 vCPUsMedium: 4 vCPUsMySQL Version8.0.208.0.20RAM8GB8GBSSD140GB115GBDeployment TypeStandaloneStandaloneRegionSF03SF03SupportIncludedBusiness-level support included with account sizes over $500/monthMonthly Price$120$120

As you can see above, ScaleGrid and DigitalOcean offer the same plan configurations across this plan size, apart from SSD where ScaleGrid provides over 20% more storage for the same price.

To ensure the most accurate results in our performance tests, we run the benchmark four times for each comparison to find the average performance across throughput and latency over read-intensive workloads, balanced workloads, and write-intensive workloads.

Throughput
In this benchmark, we measure MySQL throughput in terms of queries per second (QPS) to measure our query efficiency. To quickly summarize the results, we display read-intensive, write-intensive and balanced workload averages below for 150 threads for ScaleGrid vs. DigitalOcean MySQL:

ScaleGrid MySQL vs DigitalOcean Managed Databases - Throughput Performance Graph

For the common 150 thread comparison, ScaleGrid averages almost 40% higher throughput over DigitalOcean for MySQL, with up to 46% higher throughput in write-intensive workloads.

#cloud #database #developer #digital ocean #mysql #performance #scalegrid #95th percentile latency #balanced workloads #developers cloud #digitalocean droplet #digitalocean managed databases #digitalocean performance #digitalocean pricing #higher throughput #latency benchmark #lower latency #mysql benchmark setup #mysql client threads #mysql configuration #mysql digitalocean #mysql latency #mysql on digitalocean #mysql throughput #performance benchmark #queries per second #read-intensive #scalegrid mysql #scalegrid vs. digitalocean #throughput benchmark #write-intensive

Verda  Conroy

Verda Conroy

1597713960

Avoid performance issues with JsonSerializer by reusing the same Json Serializer Options

In this post, I describe why you should cache JsonSerializerOptions when using System.Text.Json.JsonSerializer to get good performance.

#.net #options #serializer