Remote Jmeter και Dacappo
Distributed Jmeter Έχουμε πει στη θεωρία ότι ένα βασικό πρόβλημα είναι client Bottlenecks Δεν μπορείτε να υπερφορτώσετε τον πελάτη σε ένα μηχάνημα ώστε να φτάσει τον απαιτούμενο αριθμό χρηστών για ένα stress test Λύση Master-Slave (server) αρχιτεκτονικές για distributed load generation Ο master καθορίζει το φορτίο και το περνάει στους slaves, εκκινεί την εκτέλεσή τους και μαζεύει τα αποτελέσματα
Distributed Jmeter load testing
Distributed Jmeter client server calls
Βήματα Εγκατάσταση Jmeter Την έχετε ήδη από το προηγούμενο Workload file Cosmos_download.jmx Ανοίξτε όλοι το Jmeter, φορτώστε το αρχείο της προηγούμενης φοράς (ή το cosmos_download.jmx) και εκτελέστε το μία φορά Πόσες κλήσεις γίνονται? Από το View Summary report Κρατήστε αυτό το νούμερο Χωριστείτε σε ομάδες των 2 ατόμων και μηχανημάτων Ο κάθε ένας θα χρησιμοποιήσει το δικό του μηχάνημα και το μηχάνημα του άλλου της ομάδας σαν απομακρυσμένο Βρείτε την IP (με ipconfig) σας και μοιραστείτε τη με το άτομο της ομάδας Αυτή που ξεκινάει από 10.100 κλπ
Βήματα Προσθέτετε την IP των slave μηχανημάτων στο properties file του master client Jmeter.properties file open and add IPs, το δικό σας μηχάνημα και του άλλου ατόμου της ομάδας # Remote Hosts - comma delimited remote_hosts=your_ip, TEAM_MEMBER_IP Αυτή η πληροφορία είναι στον κεντρικό client/master Αλλά επειδή όλοι θα λειτουργήσετε σαν master πρέπει να την έχετε
Βήματα Αν είστε σε Linux προσέξτε τα properties του jmeter-server file να ειναι as executable Σε κάθε slave που θέλετε να χρησιμοποιήσετε: Εκτέλεση Jmeter-server από command line μέσα στο directory που είναι το jmeter jmeter-server.bat Djava.rmi.server.hostname=IP_ADDRESS_OF_THIS_NODE (ip address του συγκεκριμένου slave) Εκτέλεση jmeter client στον master κόμβο (command line) με την εντολή Jmeter.bat Djava.rmi.server.hostname=CLIENT_IP_ADDRESS n t /path_to_workload_file/workload.jmx RSLAVE_IP1,SLAVE_IP2
Επαλήθευση εκτέλεσης
Aπό GUI Jmeter GUI Select remote ή και όλους μαζί
Αποτελέσματα Μετά την εκτέλεση πρέπει να σας βγάζει συγκεντρωτικά αποτελέσματα στον Master client Το πλήθος των κλήσεων πρέπει να είναι διπλάσιο από τον αριθμό της μεμονωμένης εκτέλεσης που πραγματοποιήσατε στην αρχή
Σημεία προσοχής Errors Και στους clients και στους slaves υπάρχουν log files Slave: Jmeter-server.log Ειδικά σε περιπτώσεις που υπάρχουν πολύπλοκες ρυθμίσεις δικτύου μπορεί να μη βρίσκονται μεταξύ τους τα μηχανήματα Τσεκάρετε τα σφάλματα στα Logs και GOOGLE!!! Για να μην δημιουργηθεί Bottleneck στον master client, καλό είναι στο workload να έχετε ορίσει μόνο aggregate results Να εκτελείτε από command line και όχι από GUI Για μια πιο αυτοματοποιημένη μεθοδολογία θα χρησιμοποιούσατε και τεχνολογίες DevOps Π.χ. Docker containers με templates για Jmeter slave kai master Docker Swarm για cluster και scalable εκτέλεση http://www.testautomationguru.com/jmeter-scaling-out-load-servers-usingdocker-compose-in-distributed-load-testing/
DaCapo Java based benchmark για διάφορα είδη εφαρμογών Γιατί ειδικά Java? Πιο δημοφιλής γλώσσα Πολλά open source εργαλεία διαθέσιμα Ιδιαιτερότητες λόγω της χρήσης του vitual layer και του garbage collection
DaCapo Εφαρμογές (Λιγότερο σημαντικές) Avrora: AVR microcontrollers Eclipse: development tool benchmark H2: database-like Pmd: Source code analysis Fop: XML to PDF
DaCapo Εφαρμογές (Πιο σημαντικές) sunflow: Graphics rendering tomcat: Server retrieval of pages xalan: XML to HTML Luindex: indexing για documents Lusearch: text search μέσα στα προηγούμενα documents Batik: δημιουργεί SVG vector graphics Jython: δοκιμάζει εκτέλεση Python μέσα από Java Γιατί είναι αυτές πιο σημαντικές?
DaCapo Οδηγίες Download http://dacapobench.org/ Options java jar dacapo-9.12-bach.jar Δοκιμάστε το Execute java jar dacapo-9.12-bach.jar <benchmark_name>
DaCapo παράμετροι small, default, large workload με την s επιλογή Ανά κατηγορία τεστ έχει και διαφορετικά maximum όρια στα threads (τυπώνει τα όρια στην αρχή της εκτέλεσης) Όταν το εκτελέσετε πρώτη φορά, σας βγάζει τον αριθμό των detected processors Default χρησιμοποιεί τους max detected Παράδειγμα πιο ολοκληρωμένης εντολής java jar dacapo-9.12-bach.jar sunflow n 10 s large t 16 2>results.txt Με το 2>results.txt κάνετε redirect το standard out στο αρχείο results.txt Μπορείτε επίσης να το εκτελέσετε με κάποιο στόχο variance μέχρι τον max αριθμό εκτελέσεων
Επαναλήψεις
Μειονεκτήματα DaCapo Δεν έχει πολλαπλές παραμέτρους να ρυθμίσετε 3 ρυθμίσεις γενικού μεγέθους Αριθμό processing threads σε μερικά tests για παραλληλοποίηση της εκτέλεσης Δεν έχει πλούσιο reporting Elapsed time Πρέπει να φτιάξετε script για την επεξεργασία των αποτελεσμάτων Δεν μπορείτε να κάνετε διαχωρισμό client από server Όπως στο YCSB
Άσκηση Για ένα από τα workloads του DaCapo (π.χ. sunflow) εκτελέστε το benchmark για Αριθμό threads από 1 έως max detected processors με βήμα 1 (αν έχετε μέχρι 4 cores), αλλιώς με βήμα 2 Για small και large workload size 10 επαναλήψεις κάθε εκτέλεσης Προσοχή να ορίζετε διαφορετικό filename για αποθήκευση των αποτελεσμάτων Τι παρατηρείτε για τον χρόνο της 1 ης (ή των πρώτων γενικά) εκτέλεσης σε σχέση με τις υπόλοιπες σε μια διαμόρφωση? Γιατί συμβαίνει αυτό? Τι παρατηρείτε για τον αριθμό των threads σε σχέση με τον χρόνο εκτέλεσης? Γιατί συμβαίνει αυτό?
Επεξεργασία δεδομένων Διαλέξτε ένα από τα result files Επιλέξτε όλα τα περιεχόμενα Ανοίξτε ένα Excel file Αντιγραφή μέσα Επιλογή Import Text Wizard Επιλογή της κύριας στήλης αποτελεσμάτων Σας βγάζει το μέσο όρο
Επεξεργασία δεδομένων Αντιγραφή του μέσου όρου σε ένα άλλο excel Προσθέστε και ποια εκτέλεση ήταν αυτή Παράδειγμα γραμμής δεδομένων Είδος benchmark-threads-workload-average response time-standard deviation Επαναλάβετε τη διαδικασία για όλα τα αρχεία Δημιουργήστε 2 γραφικές στο ίδιο γράφημα (μία για small και μια για large worlkoad) Στο χ ο αριθμός των threads Στο y το μέσο response time Δημιουργήστε 2 γραφικές στο ίδιο γράφημα (μία για small και μια για large worlkoad) Στο χ ο αριθμός των threads Στο y το deviation (χρησιμοποιήστε τη συνάρτηση STDEV.P() για όλη τη στήλη αποτελεσμάτων Π.χ. STDEV.P(L:L)