One of our services recently started to perform multiple inserts and deletes in MySQL database. To the point of a noticeable response time increase. Batching of SQL queries is nothing new, but I decided to wander around this topic a bit in Internet, and stumbled upon something I never heard before (or blissfully forgot). A rewriteBatchedStatements property of MySQL JDBC driver. Here I am, benchmarking this thing and checking other options…

Disclaimer 1. To be honest, this post doesn’t contain anything new or special in it. I’ve just discovered something interesting and would like to share it.

Disclaimer 2. This…


Part 3: Threading Model

Weaving machine, craftsman
Weaving machine, craftsman
Image by Pexels from Pixabay.

Part 1. Coding.
Part 2. Exception Handling.
Part 3. Threading Model.

In previous parts we avoided the question of which ExecutionContext we should use. Finally, we got to it! In this part I’m going to cover a lot of different topics around multi-threading. Let’s start right away!

How many threads should we use?

One interesting thing that async programming provides to us is an ability to use a small number of threads, close to the number of available CPUs. Why is it cool?

  1. Smaller memory consumption: by default thread allocates 1 megabyte of memory for stack; minimum is different on different platforms, for example, on 64-bit…


Part 2: Exception Handling

Image by Pexels from Pixabay.

In this part we will cover the exception handling for async programming in Scala with Futures.
Part 1. Coding.
Part 2. Exception Handling.
Part 3. Threading Model.

I deliberately named this part as “Exception Handling” and not “Error Handling”. There are different error handling models: exceptions, error codes, returning Either of business result or some kind of error etc. I’m not going to describe all possible options here, I decided to use exceptions (or, to better put it, Future.failed with exception inside) as a error propagation mechanism, mainly because:

  1. Familiarity. We all use exceptions in pre-async non-functional world.
  2. It’s impossible…


Part 1. Coding

Image by Daniel Agrelo from Pixabay.

In this part we will cover the most basic part of async programming in Scala with Futures.
Part 1. Coding.
Part 2. Exception Handling.
Part 3. Threading Model.

Today asynchronous programming gets some traction. Some may argue even some hype. However, there are cases when it’s really necessary (or, let’s put it mildly, favorably). In this blog post I’d like to put aside reasons behind writing an application in an async fashion, it’s a separate topic. Here I want to focus on the practical side of this topic — how it looks like, what we have to do in order…


UPD: Apparently, in top 5 results from Google, there are no correct examples, changed text accordingly.

Resource management is a very important topic in software development. Also, it is hard to add something new to it. The topic is covered pretty well in all kinds of blog posts, articles, and tech papers. Nevertheless, I have something to say, not new, but I believe it’s worth repeating.

Intro

A usual pattern for working with files (or other resources), for example, is following:

val file: InputStream = _
try {
// read from stream
} finally {
file.close()
}

But this is not…


Repost of my blog post in Wix Engineering Blog with some extra information.

Though the question of “How to query data from a database?” is quite an old one, we still have a reason to investigate it nowadays. True, it is common to query a list of rows from a database since that usually means less code and configuration and it’s also the default approach. However, in certain scenarios, this method is just not optimal. In these cases, we don’t need all rows in memory right away, and sometimes we just can’t afford it.

When addressing the issue of querying…


Performance comparison between different kinds of string concatenation/formatting in Java/Scala

UPD: Here is the Pull Request to scala-compiler with changes inspired by this post.

String concatenation is a basic building block in every modern programming language. Many different projects, especially in Web, produce a lot of strings. And it’s interesting, how this problem is solved in different languages. In our case, in Java and Scala (because it’s much easier to compare, and these I use day-to-day).

There are a lot of posts on Internet about this topic. But still, there are something interesting to say about it (I hope you won’t be bored). …


Yet another post about performance and microbenchmarks. Yes, I know.

Very small JMH benchmark:

@BenchmarkMode(Array(Mode.AverageTime))
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(value = 2, jvmArgs = Array("-Xmx2G"))
@Measurement(iterations = 7, time = 3, timeUnit = TimeUnit.SECONDS)
@Warmup(iterations = 3, time = 3, timeUnit = TimeUnit.SECONDS)
class StringBuilderBenchmark {

@Benchmark
def javaStringBuilder: String = {
new java.lang.StringBuilder().append("abc").append("def")
.toString
}

@Benchmark
def javaStringBuilder2: String = {
new java.lang.StringBuilder().append(495-char-length-string).append(495-char-length-string).toString
}
@Benchmark
def scalaStringBuilder: String = {
new scala.collection.mutable.StringBuilder().append("abc")
.append("def").toString
}
@Benchmark
def scalaStringBuilder: String = {
new scala.collection.mutable.StringBuilder().append(495-char-length-string).append(495-char-length-string).toString
}
}

And the…


I’ve just created a site on GitHub Pages: https://dkomanov.github.io/scala-serialization/. There I’ve put my recent benchmark results from the Scala Serialization article.

Things changed:

  1. Results gathered via JMH.
  2. Added benchmark for two-way action: serialization and deserialization.
  3. In JMH I use 2 threads instead of 1 (so, I check libraries in multi-threaded environment).
  4. Chill doesn’t behave well (sometimes deserialization fails with “Buffer underflow” exception, it is related to multi-threading, but I didn’t have enough time to investigate).
  5. Libraries versions are updated (boopickle, pickling, scalapb). Scala Pickling improved significantly.

Thanks to everyone for comments, pull requests and shares.


UPD: Recent benchmark charts are at https://dkomanov.github.io/scala-serialization/.

It’s common to use JSON [1] as the main format of serialized data. It’s very convenient to use it both on client and server. Obviously, it’s not the best choice in terms of both data size and performance.

This article mainly focused on data size/performance of binary serialization libraries for Scala [2]. Java versions are used just to compare with.

TL;DR

Protobuf is small and fast. Scala’s implementation — ScalaPB — is robust and convenient. Both for many small and big messages.

Use cases

Many performance tests suffers from a synthetical nature of data. This test…

Dmitry Komanov

Software developer, moved to Israel from Russia, trying to be aware of things.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store