Spelling suggestions: "subject:"bperformance benchmark"" "subject:"bperformance enchmark""
1 |
Performanceuntersuchungen von JVM–Implementierungen in containerisierten Umgebungen am Beispiel von PodmanWanck, Cedric 29 October 2024 (has links)
Die Bachelorarbeit konzentriert sich auf die Untersuchung der Leistung der Java Virtual Machi-
ne (JVM), insbesondere in containerisierten Umgebungen. Die Motivation für diese Arbeit sowie
die Zielsetzung und das methodische Vorgehen, einschlieSSlich der verwendeten Werkzeuge und
Methoden, werden in Kapitel 1 dargelegt.
Kapitel 2 erläutert die theoretischen Grundlagen, die für das Verständnis der Performanceun-
tersuchungen in dieser Arbeit erforderlich sind. Dazu gehört eine Einführung in die Performance
von Programmen und deren Messung, die Grundlagen von Containertechnologien sowie eine detail-
lierte Untersuchung der Struktur der Java Virtual Machine und der in dieser Arbeit verwendeten
JVM–Implementierungen. Zudem werden die eingesetzten Werkzeuge und Methoden sowie der
aktuelle Forschungsstand in diesem Bereich vorgestellt.
Das Experiment wird umfassend in Kapitel 3 beschrieben. Es wird ein detaillierter Einblick
in die Forschungs– und Entscheidungsprozesse gegeben, die zur Durchführung der Performan-
ceuntersuchungen führten, einschlieSSlich der Entwicklung und Prognosen der Benchmarks. Die
Implementierung der Anwendung, die Containerisierung der JVMs und die notwendigen Schritte
zur Ausführung und Messung der Benchmarks werden ebenfalls erläutert.
In Kapitel 4 werden die Messergebnisse der Container–ImagegröSSen und Startzeiten sowie
die Resultate der implementierten Benchmarks präsentiert. Die Daten werden analysiert und in
Bezug auf verschiedene Performanceaspekte interpretiert. Es wird versucht, die Vor– und Nach-
teile der unterschiedlichen JVM–Implementierungen darzustellen und Designentscheidungen zu
unterstützen.
AbschlieSSend werden die Ergebnisse der Arbeit in Kapitel 5 zusammengefasst. Es wird auf
die Gültigkeit der Ergebnisse unter bestimmten Bedingungen eingegangen und mögliche Grenzen
der Untersuchung aufgezeigt. AuSSerdem wird ein Ausblick auf potenzielle zukünftige Forschungs-
arbeiten gegeben.:Abbildungsverzeichnis III
Tabellenverzeichnis V
Listings VII
1 Einleitung 1
1.1 Motivation 1
1.2 Zielsetzung 1
1.3 Methodisches Vorgehen 2
2 Theoretische Grundlagen 3
2.1 Performance von Programmen 3
2.2 Container und Podman 5
2.3 JVM und ihre Struktur 6
2.3.1 Runtime Data Areas 6
2.3.2 Execution Engine 8
2.4 Unterschiede der JVM–Implementationen 9
2.4.1 HotSpot 9
2.4.2 GraalVM 10
2.4.3 Zulu 10
2.4.4 OpenJ9 10
2.5 Werkzeuge und Methoden 11
2.6 State of the Art 11
3 Experiment 13
3.1 Planung 13
3.1.1 Grundlegende Recherche 13
3.1.2 Entwurf der Benchmarks 14
3.1.3 Erwartungshaltung 15
3.2 Implementierung 15
3.3 Durchführung und Messung 21
4 Auswertung und Vergleich 23
5 Fazit 33
Literaturverzeichnis 35
A Quellcode und Ergebnisse der Benchmarks 39
A.1 Elektronischer Datenträger 39
A.2 Quellcode der Matrixmultiplikation 40
A.3 Ausschnitte des Quellcodes der GC–Benchmarks 41
A.4 Ausschnitte des Quellcodes des Quicksort–Benchmarks 42
|
2 |
Performanceuntersuchungen von JVM–Implementierungen in containerisierten Umgebungen am Beispiel von PodmanWanck, Cedric 06 November 2024 (has links)
Die Bachelorarbeit konzentriert sich auf die Untersuchung der Leistung der Java Virtual Machi-
ne (JVM), insbesondere in containerisierten Umgebungen. Die Motivation für diese Arbeit sowie
die Zielsetzung und das methodische Vorgehen, einschlieSSlich der verwendeten Werkzeuge und
Methoden, werden in Kapitel 1 dargelegt.
Kapitel 2 erläutert die theoretischen Grundlagen, die für das Verständnis der Performanceun-
tersuchungen in dieser Arbeit erforderlich sind. Dazu gehört eine Einführung in die Performance
von Programmen und deren Messung, die Grundlagen von Containertechnologien sowie eine detail-
lierte Untersuchung der Struktur der Java Virtual Machine und der in dieser Arbeit verwendeten
JVM–Implementierungen. Zudem werden die eingesetzten Werkzeuge und Methoden sowie der
aktuelle Forschungsstand in diesem Bereich vorgestellt.
Das Experiment wird umfassend in Kapitel 3 beschrieben. Es wird ein detaillierter Einblick
in die Forschungs– und Entscheidungsprozesse gegeben, die zur Durchführung der Performan-
ceuntersuchungen führten, einschlieSSlich der Entwicklung und Prognosen der Benchmarks. Die
Implementierung der Anwendung, die Containerisierung der JVMs und die notwendigen Schritte
zur Ausführung und Messung der Benchmarks werden ebenfalls erläutert.
In Kapitel 4 werden die Messergebnisse der Container–ImagegröSSen und Startzeiten sowie
die Resultate der implementierten Benchmarks präsentiert. Die Daten werden analysiert und in
Bezug auf verschiedene Performanceaspekte interpretiert. Es wird versucht, die Vor– und Nach-
teile der unterschiedlichen JVM–Implementierungen darzustellen und Designentscheidungen zu
unterstützen.
AbschlieSSend werden die Ergebnisse der Arbeit in Kapitel 5 zusammengefasst. Es wird auf
die Gültigkeit der Ergebnisse unter bestimmten Bedingungen eingegangen und mögliche Grenzen
der Untersuchung aufgezeigt. AuSSerdem wird ein Ausblick auf potenzielle zukünftige Forschungs-
arbeiten gegeben.:Abbildungsverzeichnis III
Tabellenverzeichnis V
Listings VII
1 Einleitung 1
1.1 Motivation 1
1.2 Zielsetzung 1
1.3 Methodisches Vorgehen 2
2 Theoretische Grundlagen 3
2.1 Performance von Programmen 3
2.2 Container und Podman 5
2.3 JVM und ihre Struktur 6
2.3.1 Runtime Data Areas 6
2.3.2 Execution Engine 8
2.4 Unterschiede der JVM–Implementationen 9
2.4.1 HotSpot 9
2.4.2 GraalVM 10
2.4.3 Zulu 10
2.4.4 OpenJ9 10
2.5 Werkzeuge und Methoden 11
2.6 State of the Art 11
3 Experiment 13
3.1 Planung 13
3.1.1 Grundlegende Recherche 13
3.1.2 Entwurf der Benchmarks 14
3.1.3 Erwartungshaltung 15
3.2 Implementierung 15
3.3 Durchführung und Messung 21
4 Auswertung und Vergleich 23
5 Fazit 33
Literaturverzeichnis 35
A Quellcode und Ergebnisse der Benchmarks 39
A.1 Elektronischer Datenträger 39
A.2 Quellcode der Matrixmultiplikation 40
A.3 Ausschnitte des Quellcodes der GC–Benchmarks 41
A.4 Ausschnitte des Quellcodes des Quicksort–Benchmarks 42
|
3 |
Performance Measurement and Analysis of Transactional Web ArchivingMaharshi, Shivam 19 July 2017 (has links)
Web archiving is necessary to retain the history of the World Wide Web and to study its evolution. It is important for the cultural heritage community. Some organizations are legally obligated to capture and archive Web content. The advent of transactional Web archiving makes the archiving process more efficient, thereby aiding organizations to archive their Web content.
This study measures and analyzes the performance of transactional Web archiving systems. To conduct a detailed analysis, we construct a meaningful design space defined by the system specifications that determine the performance of these systems. SiteStory, a state-of-the-art transactional Web archiving system, and local archiving, an alternative archiving technique, are used in this research. We experimentally evaluate the performance of these systems using the Greek version of Wikipedia deployed on dedicated hardware on a private network. Our benchmarking results show that the local archiving technique uses a Web server’s resources more efficiently than SiteStory for one data point in our design space. Better performance than SiteStory in such scenarios makes our archiving solution favorable to use for transactional archiving. We also show that SiteStory does not impose any significant performance overhead on the Web server for the rest of the data points in our design space. / Master of Science / Web archiving is the process of preserving the information available on the World Wide Web into archives. This process provides historians and cultural heritage scholars access to the data that allows them to understand the evolution of the Internet and its usage. Additionally, Web archiving is also essential for some organizations that are obligated to keep the records of online resource access for their customers. Transactional Web archiving is an archiving technique where the information available on the Web is archived by capturing a transaction between a user and the Web server processing the user’s request. Transactional Web archiving provides a more complete and accurate history of a Web server than the traditional Web archiving models. However, in some scenarios the transactional Web archiving solutions may impose performance issues for the Web server being archived.
In this thesis, we conduct a detailed performance analysis of SiteStory, a state-of-the-art transactional Web archiving solution, in various experimental settings. Furthermore, we propose a novel transactional Web archiving approach and compare its performance with SiteStory. To conduct a realistic study, we analyze real-life traffic on Greek Wikipedia website and generate similar traffic to perform our benchmarking experiments. Our benchmarking results show that our archiving technique uses a Web server’s resources more efficiently than SiteStory in some scenarios. Better performance than SiteStory in such scenarios makes our archiving solution favorable to use for transactional archiving. We also show that SiteStory does not impose any significant performance overhead on the Web server in other scenarios.
|
4 |
Možnosti In-memory reportingových nástrojů / Possibilities of In-memory reporting toolsCígler, Lukáš January 2013 (has links)
Diploma thesis focuses on in-memory data processing, its use in reporting and Business Intelligence (BI) in general. The main goal of the theoretical part is to introduce the in memory principles, highlight the differences from hard drive data processing and overview possible implementations of in-memory technology in BI solution. The output of this section is an analysis of advantages and disadvantages of in-memory solutions in various perspectives. The practical part of the thesis consists of the performance benchmark that compares the performance of data processing using the in-memory principles and conventional hard drive methods. The performance comparison is realized in the reporting tools environment, QlikView for in-memory approach and Reporting Services for hard drive based method. Several data sets are used for testing in both mentioned tools. End of the chapter provides the assessment of testing results and discusses the strengths and weaknesses of both principles of data processing. The conclusion of this work discusses the advantages and disadvantages of in-memory data processing and defines the key questions that company management should ask before investing in innovation of the present BI solution. Moreover the conclusion contains recommendations for possible further follow-up work.
|
5 |
A COMPARISON OF DATA INGESTION PLATFORMS IN REAL-TIME STREAM PROCESSING PIPELINESTallberg, Sebastian January 2020 (has links)
In recent years there has been an increasing demand for real-time streaming applications that handle large volumes of data with low latency. Examples of such applications include real-time monitoring and analytics, electronic trading, advertising, fraud detection, and more. In a streaming pipeline the first step is ingesting the incoming data events, after which they can be sent off for processing. Choosing the correct tool that satisfies application requirements is an important technical decision that must be made. This thesis focuses entirely on the data ingestion part by evaluating three different platforms: Apache Kafka, Apache Pulsar and Redis Streams. The platforms are compared both on characteristics and performance. Architectural and design differences reveal that Kafka and Pulsar are more suited for use cases involving long-term persistent storage of events, whereas Redis is a potential solution when only short-term persistence is required. They all provide means for scalability and fault tolerance, ensuring high availability and reliable service. Two metrics, throughput and latency, were used in evaluating performance in a single node cluster. Kafka proves to be the most consistent in throughput but performs the worst in latency. Pulsar manages high throughput with low message sizes but struggles with larger message sizes. Pulsar performs the best in overall average latency across all message sizes tested, followed by Redis. The tests also show Redis being the most inconsistent in terms of throughput potential between different message sizes
|
Page generated in 0.0707 seconds