I ran two micro-benchmarks comparing web service endpoints implemented in Java (Sprint Boot and Spark) and Rust/Actix-web. In summary, performance were equal or not that different, but memory usage was extremely higher in Java. (disclaimer: micro-benchmarks don’t reflect more complex applications, the ease to face various specific cases, to find developers, to adapt the current infrastructure and dev ecosystem…).
Micro-benchmark 1: receive a JSON and return a subset
An overly simplistic benchmark: it does almost no computation excepted deserializing and serializing a JSON.
Java version performed between 0% and 25% slower (according to the number of concurrent calls, the more the better). But the memory consumption was 5Mo for Rust and larger than 300Mo for Java!
Micro-benchmark 2: query a Postgres DB to return the reading of a kanji
The service takes a kanji character (Japanese character of Chinese origin) as a query parameter, search in a Postgres DB all the readings associated to this kanji and return them as a JSON.
Both Java and Rust version had the same performance, the Rust one being less stable according to Apache Bench. But in term of memory… 10Mo for Rust vs 160-190 (Spark) and 258-370Mo (Spring) for Java.
If you are running an infrastructure based on Java « micro »-services, that will make quite an overhead on your hosting bill.
And it gives something like that:
I needed an XML parser for my tests with Rust (parsing a gigantic 2Go Wikivoyage XML dump) and there is no native one. So I would need a wrapper around a C implementation. At first, I used libxml2, because
it has a very appealing name it has a very convenient XmlTextReader API where you are controlling the parsing loop (no callback like in SAX).
I wondered how it compared to the StAX API of Java, and made a simplistic test printing (to /dev/null) the names of all the nodes. And surprise, StAX was way faster:
- the StAX (openjdk-7, Ubuntu 14.04, amd64)
- 35 seconds
- Memory usage: 30 Mo
- XmlTextReader API of libxml2 (2.9.1), g++ 4.8.2
Then I made tests with SAX, comparing the default Java implementation with libxml2 and finally also libexpat 2.1:
- Java: 30s (39Mo)
- libxml2: 34s (2Mo)
- libexpat: 21s (180ko)
- the Java implementation seems quite good (at least in this particular scenario)
- libexpat is quite fast, but it’s SAX and not pull-parsing (which is very convenient)
- if you are processing huge XML files, forget about libxml2
I met a performance issue with PipedInputStream/PipedOutputStream, and here is how I finally solved it.
Continuer la lecture →