<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance on JAVAPRO Germany</title><link>https://javapro.svenruppert.com/categories/performance/</link><description>Recent content in Performance on JAVAPRO Germany</description><generator>Hugo</generator><language>de-DE</language><lastBuildDate>Mon, 26 Jan 2026 07:03:43 +0000</lastBuildDate><atom:link href="https://javapro.svenruppert.com/categories/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>1BRC - Die ersten 80% Performance</title><link>https://javapro.svenruppert.com/1brc-die-ersten-80-performance/</link><pubDate>Mon, 26 Jan 2026 07:03:43 +0000</pubDate><guid>https://javapro.svenruppert.com/1brc-die-ersten-80-performance/</guid><description>&lt;p&gt;Die &lt;a href="https://www.morling.dev/blog/one-billion-row-challenge/"&gt;One Billion Row Challenge (1BRC)&lt;/a&gt; startete als Projekt über den Jahreswechsel 2023/2024 und widmete sich einer vermeintlich einfachen Fragestellung: Wie schnell können Temperaturmesswerte aus einer Textdatei mittels Java verarbeitet werden, um Minimum-, Durchschnitts- und Maximumwerte pro Wetterstation zu berechnen? Die Herausforderung ergibt sich dabei aus dem Umfang des Datensatzes, der mit einer Milliarde Zeilen eine Gesamtgröße von etwa 13,8 GB umfasst.&lt;/p&gt;
&lt;p&gt;Thomas Wuerthinger, Quan Anh Mai und Alfonso Peterssen erzielten mit 1,5 Sekunden auf 8 Cores das Spitzenresultat. Diese Performance war in diesem Ausmaß unerwartet. Bei einer detaillierten Analyse des Quellcodes wird jedoch ersichtlich, dass die Implementierung weit über die übliche Java-Entwicklung hinausgeht. Es handelt sich um eine hochkomplexe, auf diesen spezifischen Use-Case zugeschnittene Lösung, deren Optimierungen größtenteils nicht ohne Weiteres auf andere Szenarien übertragbar sind.&lt;/p&gt;</description></item><item><title>Java 26 übernimmt HTTP/3 mit der Weiterentwicklung des HttpClient</title><link>https://javapro.svenruppert.com/java-26-uebernimmt-http-3-mit-der-weiterentwicklung-des-httpclient/</link><pubDate>Mon, 19 Jan 2026 07:00:49 +0000</pubDate><guid>https://javapro.svenruppert.com/java-26-uebernimmt-http-3-mit-der-weiterentwicklung-des-httpclient/</guid><description>&lt;h2 id="die-zukunft-der-kommunikation-zwischen-microservices"&gt;die Zukunft der Kommunikation zwischen Microservices&lt;/h2&gt;
&lt;p&gt;Moderne verteilte Architekturen, wie etwa Microservices, sind eng mit der Weiterentwicklung von Netzwerkprotokollen verknüpft. Da sich Microservice-Architekturen als der vorherrschende Ansatz für den Aufbau skalierbarer und resilienter Anwendungen etabliert haben, ist die Effizienz der Service-zu-Service-Kommunikation zu einem zentralen Anliegen geworden.&lt;/p&gt;
&lt;p&gt;Obwohl HTTP/1.1 und HTTP/2 bedeutende Verbesserungen brachten, wie etwa persistente Verbindungen und Request-Multiplexing, waren sie weiterhin grundsätzlich durch ihre Abhängigkeit von TCP eingeschränkt. In Netzwerken mit hoher Latenz oder Instabilität können diese Einschränkungen nach wie vor zu Leistungseinbußen, erhöhter Tail-Latenz und geringerer Resilienz unter Last führen. Mit JEP 517 führt Java 26 Unterstützung für HTTP/3 im HttpClient ein und ermöglicht damit QUIC-basierte Kommunikation. Sehen wir uns an, was sich mit HTTP/3 ändert.&lt;/p&gt;</description></item><item><title>So beschleunigen sie existierende Deployments mit den richtigen JVM-Features</title><link>https://javapro.svenruppert.com/so-beschleunigen-sie-existierende-deployments-mit-den-richtigen-jvm-features/</link><pubDate>Mon, 21 Apr 2025 07:00:11 +0000</pubDate><guid>https://javapro.svenruppert.com/so-beschleunigen-sie-existierende-deployments-mit-den-richtigen-jvm-features/</guid><description>&lt;p&gt;&lt;a href="https://www.youtube.com/watch?v=6628huqjF9s&amp;amp;list=PLFeSAZzYdUodZjQy6a3pCBl43UUem8_E3&amp;amp;index=14"&gt;&lt;figure class="post-figure"&gt;
 &lt;img src="https://javapro.svenruppert.com/uploads/sites/1/2025/04/Magazin-Artikel-Banner-2-1024x214.jpg" alt="" loading="lazy" decoding="async"&gt;
 
 
 
&lt;/figure&gt;
&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;In der heutigen Tech-Landschaft sehen sich Java-Anwendungen mit einer entscheidenden Herausforderung konfrontiert. Unternehmen müssen steigenden Performance-Anforderungen gerecht werden und gleichzeitig die Kosten für die Infrastruktur unter Kontrolle halten – und das ohne kostspielige Neuentwicklungen.&lt;/p&gt;
&lt;p&gt;Diese Herausforderung hat sich mit der Einführung von Cloud Computing noch weiter verschärft. Jede Millisekunde Latenz und jedes Megabyte an Speicher wirken sich nun direkt auf die laufenden Kosten aus. Die Zahlen sind beachtlich: Basierend auf meinen Erfahrungen können schlecht konfigurierte JVMs die Cloud-Kosten um 30–50 % erhöhen. Für große Unternehmen entspricht das Millionen an vermeidbaren Ausgaben.&lt;/p&gt;</description></item><item><title>Hitchhiker's Guide to Java Performance</title><link>https://javapro.svenruppert.com/hitchhikers-guide-to-java-performance/</link><pubDate>Wed, 02 Apr 2025 12:17:42 +0000</pubDate><guid>https://javapro.svenruppert.com/hitchhikers-guide-to-java-performance/</guid><description>&lt;h3 id="vergangenheit-gegenwart-und-zukunft"&gt;Vergangenheit, Gegenwart und Zukunft&lt;/h3&gt;
&lt;p&gt;In den letzten 30 Jahren hat sich Java von einer exotischen „write once, run anywhere“-Sprache zu einer der weltweit dominierenden Plattformen für die Softwareentwicklung entwickelt. In den Anfangsjahren galt Java im Vergleich zu Sprachen wie C/C++ zu Recht als langsam, was vor allem auf den anfänglichen Interpreter-Ansatz zurückzuführen war. Die letzten 30 Jahre haben bewiesen, dass das VM-Konzept mit der adaptiven Optimierung der HotSpot-Engine langfristig die effizientere Lösung ist.&lt;/p&gt;</description></item><item><title>Kostenminimierung durch Nutzung von Cloud-Speicher mit Spring-Data-Eclipse-Store</title><link>https://javapro.svenruppert.com/kostenminimierung-durch-nutzung-von-cloud-speicher-mit-spring-data-eclipse-store/</link><pubDate>Wed, 21 Feb 2024 14:59:47 +0000</pubDate><guid>https://javapro.svenruppert.com/kostenminimierung-durch-nutzung-von-cloud-speicher-mit-spring-data-eclipse-store/</guid><description>Mit Hilfe von Spring Data und EclipseStore können massive Kosten für Datenspeicherung in der Cloud eingespart werden. Wie das funktioniert, zeigt folgender Artikel durch die Spring-Data-Eclipse-Store-Bibliothek.</description></item><item><title>MicroStream High-Speed Persistence jetzt Open Source</title><link>https://javapro.svenruppert.com/microstream-high-speed-persistence-jetzt-open-source/</link><pubDate>Fri, 13 Aug 2021 16:14:42 +0000</pubDate><guid>https://javapro.svenruppert.com/microstream-high-speed-persistence-jetzt-open-source/</guid><description>&lt;p&gt;&lt;a href="https://microstream.one/"&gt;MicroStream&lt;/a&gt; ist im Kern eine von Grund auf neu entwickelte, hoch performante und ebenso hoch sichere Serialisierung für Java, mit einem darauf aufsetzendem Persistence-Framework für die persistente Speicherung beliebiger Java Objektgraphen (POJOs), die im schnellen Hauptspeicher gehalten werden. Das Ergebnis ist eine hoch performante In-Memory Datenbankanwendung oder ein Microservice mit eigener Persistence.&lt;/p&gt;
&lt;p&gt;Das 2013 gestartete Projekt ist nun in Version 5 als Open Source unter der Eclipse Public License auf &lt;a href="https://github.com/microstream-one/microstream"&gt;GitHub&lt;/a&gt; verfügbar. Mit MicroStream lassen sich beliebige Java Objekte (Plain-Old-Java-Objects), in der Praxis meist komplexe Objektgraphen bestehend aus Millionen von Objekten oder auch nur einzelne Subgraphen davon, persistent speichern und zu einem beliebigen Zeitpunkt ganz oder auch nur teilweise im Hauptspeicher wiederherstellen, z.B. nach einem Systemneustart. Anders als bei traditionellen Java Persistenz-Frameworks wie Hibernate in Verbindung mit relationalen Datenbanken oder bei NoSQL Systemen, werden Java Objekte mit MicroStream nicht mehr auf eine datenbankspezifische Datenstruktur abgebildet (Mapping), sondern serialisiert und direkt in Form von Bytecode persistent gespeichert. Umständliche Mappings, daraus resultierende technische Probleme, rechenzeitintensive Datenkonvertierungen und damit verbundene Latenzen zur Laufzeit fallen vollständig weg.&lt;/p&gt;</description></item></channel></rss>