Voxxed Days is a series of tech events organised by local community groups and supported by the Voxxed team.
During this event NetworkedAssets served the Java coffee beans (aka lifeblood) for thirsty Java developers.
A spirit of openness, community, content and low priced tickets underpin the Voxxed Days philosophy. Sharing the Devoxx philosophy that content comes first, these events see both internationally renowned and local speakers. From the 27th-29th of January 2016 the event took place in Germany for the first time in the Kosmos in Berlin.
Topics covered at Voxxed Days include in general: Server Side Java, Java SE, Cloud and Big Data, Web & HTML, Mobile, JVM, Architecture & Security, Methodology, and Future Technologies. In Berlin a great blend of Java speakers and some of the top talents from Germany and around the globe delivered sessions on the latest and most important topics. There were 2 keynotes and 36 parallel sessions during the two days. (All sessions have been recorded and are available on Parleys.com).
The session of Adrian Cole from the Spring Cloud OSS team of Pivotal was about latency analysis and the way it is blaming components for causing user perceptible delay. In today’s world of microservices, this can be tricky as requests can fan out across polyglot components and even data-centers. In many cases, the root source of latency isn’t a component, but rather a link between components.
First Adrian explained how to understand that not all operations are on the critical path and not all of them are relevant.
He admitted that it is getting harder to draw architecture, because there is not only a simple client-server model anymore. But polyglott microserverices and data flow architecture are increasingly easy to write and deploy. The question that he pointed out was: can we make troubleshooting wizard-free, because we no longer need them for complex architectures? He explained that distributed tracing commoditizes knowledge. Its possible to collect end-to-end latency graphs in near real-time. We can compare traces to understand why certain requests take longer than others. But what is distributed tracing? A Span is an individual operation that took place. It contains timestamped events and tags. A Trace on the other hand is an end-to-end latency graph, composed of spans.
Tracing means logging important events. Tracers record time, duration and hosts. They cement shapes with IDs and send trace data out of the process. Tracers propagate IDs in-band, to tell the receiver there’s a trace in progress. Completed spans are reported out-of-band, to reduce overhead and allow for batching. Tracers usually live in your application in production, therefore you have to be careful not to collect too much data to not disturb the app in production. Tracing around an app is not recommended by him. Tracers are often layered, sensitive about data security and can capture spans in any language.
Then Adrian explained about Tracing systems. They are observability tools, which collect, process and present data reported by tracers. They aggregate spans into trace trees, provide query and visualization for latency analysis and have retention. Zipkin is a distributed tracing system which has a pluggable architecture.
The tracers of Zipkin collect timing data and transport it over HTTP or Kafka. The collectors store spans in Mysql or Cassandra. Users query for tracers via Zipkins Web UI or Api. Zipkin has a starter architecture, because tracing is new for a lot of folks. For many mysql is a good start, because they don’t know cassandra. It can be as simple as a single file. Zipkin lives in GitHub, was created by Twitter in 2012 and in 2015 OpenZipkin became the primary fork, which contains tracers and an OpenApi spec.
Last but not least Adrian started a demo on Docker. He explained that he was using Docker because you are more aware of the container and your app surroundings. He collected events, put them in a span and explained about the processes.
The session of Jens Deters, Senior IT Consultant at Codecentric, was about a complete MQTT-driven IoT stack with several sensors, remote-controlled switches, and different client platforms (desktop, embedded and mobile devices). In the demo part, he showed an example of a seamless replacement of a Raspberry Pi-driven sensor host by a low-energy Microcontroller-based solution without any needs for code changes.
First of all, Jens talked about the Internet of things and how microcomputers came up. The main question was, how to get the data to mobiles or other UIs. For this the IoT protocols were developed.
He explained about the Message Queue Telemetrie Transport (MQTT), which is a very lightweight protocol, TCP based, asynchronous and uses Client/Broker functionalities. He also talked about QoS, Last Will & Testament messages, Security and how the Publisher and Mosquitto broker on a raspberry pie works. Sensors and actors are used to control or subscribe to the services.
Jens showed a demo from his private home monitoring system and pointed out that the message flow itself was not secured in this example, because he is using it at home in a local network with a synology. He was using an Adafruit HUZAAH ESP8266, with breakout highlights, microcontroller, Wi-Fi direct, integrated TCP/IP protocol stack and wake up and transmit packets in < 2md.
In the JavaUI the MQTT client connects to the broker and certain mqtt topics and the panels are used to control the lights. He pointed out that these were fire and forgot switches without feedback, otherwise more expensive switches would be needed. But the app collects the energy consumption of his home successfully and presents it on every device.
As a last topic he explained about MQTT.fx, which is used for debugging and testing and is free available. You can enter a connection profile, test different setups for a broker, connect with the synology at home via public url, receive all messages that are sent by the sensors at home and display the room temperature, humidity, daylight in lumen, temp outside and inside on the UI of your device.
More information can also be found on Jens website.
The session of Simon Maple, Head of Developer Advocacy at ZeroTurnaround, was about how profilers might prove useful to pinpoint the performance issues in your Java applications. By using profilers, developers are fortunate to find the root cause of an issue at hand. However, it requires effort to actually comprehend the data collected by the profiler. Due to the inherent complexity of the data, one has to understand how this data is collected. And thus understand how the profiler actually works.
To start Simon pointed out that it is not a good idea, if your app doesn’t work in a presentation, to always blame the database. To understand what is actually happening, you have to change about how you test. Understanding the performance pipeline. It matters for example at what time we do performance tests The main performance problems are slow database queries, inefficient application code and too many database queries. But there can be others. We have to decide if we test reactive or proactive, wait until an issue occurs or proactively prevent potential issues. Then we can choose between CPU or memory profiling. Simon is concentrating on CPU tracing and sampling in his examples.
A Sample is a snapshot in time, a thread dump (kill -3 PID on Unix). By comparing samples, you can see, if on samples a method is hit 50% of the time, this takes also 50% in an interval of time. In bigger intervals this is more precise, but in the snapshots mistakes appear, for example if a method is never hit in these points. If you choose specific Safepoints, the samples are not entirely random anymore.
Simon also introduces Java Mission Control, which is free tool included in JDK since 7 u40. In production you have to pay for it, but its free for development. For example you can see, that java.util is used a lot of course, but you have to look into detail to see which methods exactly are called. The problem is to understand where to start looking, for what pattern to look. It is easy to get little or too much information, but difficult to get just the right amount. Mostly it is too much, so we can’t find the bug.
Next he explains about the importance of timing and how it matters if you use system.nanotime, system.currenttimemillis or a parallel thread. A parallel thread will for example grab the time in a loop and then sleep. Nanotime works better, because reading memory is not free and each layer is not free (JVM, JNI,OS, HW).
But one has to keep in mind that to get the nanotime takes time also, on Linux less than on windows, so its difficult to get an accurate value.
A Sleep Timer is used for time-slicing and scheduling. The minimum sleep time takes a lot longer on windows as well and a Windows scheduler skips yielded threads completely.
In tracing we hit every single point in time when methods are hit. It is much more expensive, but much more accurate.
Profiling in production has to be extremely lightweight. For example, the Lightweight Profiler is showing potential problems.
XRebel is a tool which runs as a java agent in your application. It measures how long requests are taking and is rendered as a toolbar in the app. A notification shows us a problem (f.e. 37 queries for one request = too much). It gives us the possibility to fix these potential problems for performance. You can see the stacktrace and the time spent in methods, which is enough information to find the problem. You can also share a link to your XRebel profiling with others and they can have a look.
There were great speakers and prices were low, there were not as many participants joining the event. Maybe the event needs more publicity in the future. It can be highly recommended to every Java developer from our side.