Load Test στην ανάπτυξη εφαρμογών για κινητά — Τι είναι, σενάρια και πώς διεξάγεται

Τι είναι το Load Test;

Load Test (δοκιμή φορτίου) — είναι η διαδικασία ελέγχου του πώς λειτουργεί το σύστημα υπό τον αναμενόμενο αριθμό ταυτόχρονων αιτημάτων ή χρηστών. Στο πλαίσιο της ανάπτυξης εφαρμογών για κινητά, το Load Test εφαρμόζεται τόσο στην πλευρά του διακομιστή (API, βάση δεδομένων, προσωρινή μνήμη) όσο και στην πλευρά του πελάτη (επεξεργασία push ειδοποιήσεων, συγχρονισμός δεδομένων). Η κύρια διαφορά από το stress testing — το Load Test μοντελοποιεί πραγματικό, όχι ακραίο φορτίο. Σύμφωνα με το AWS Well-Architected Framework (2024), η δοκιμή φορτίου πρέπει να διεξάγεται χρησιμοποιώντας προφίλ φορτίου που βασίζονται σε πραγματικά αναλυτικά στοιχεία χρήσης.

Το Load Test μπορεί να διεξαχθεί σε επίπεδο HTTP αιτημάτων προς το API, σε επίπεδο συνδέσεων WebSocket ή σε επίπεδο συναλλαγών βάσης δεδομένων. Στόχος — να διασφαλιστεί ότι ο χρόνος απόκρισης κάθε αιτήματος δεν υπερβαίνει το καθορισμένο όριο (συνήθως 500–1000 ms για API) και ότι η απόδοση μετάδοσης (RPS — requests per second) ανταποκρίνεται στις απαιτήσεις. Το Google Cloud Armor (2024) καθορίζει τιμές ορίων βάσει εκατοστημορίων: ο χρόνος απόκρισης p95 δεν πρέπει να υπερβαίνει τα 2 δευτερόλεπτα για κρίσιμα endpoints.

Η δοκιμή φορτίου του mobile backend περιλαμβάνει προσομοίωση τυπικών σεναρίων: εγγραφή, εξουσιοδότηση, φόρτωση ροής, αποστολή φόρμας. Τα σενάρια καταγράφονται με τη μορφή αρχείων HAR (HTTP Archive) και αναπαράγονται από το εργαλείο δοκιμής φορτίου. Σύμφωνα με την τεκμηρίωση του k6 (2025), η μετατροπή HAR μπορεί να μειώσει τον χρόνο προετοιμασίας του Load Test κατά 60%.

Στόχοι της δοκιμής φορτίου

Πρώτος στόχος του Load Test — επιβεβαίωση της απόδοσης μετάδοσης του συστήματος. Εάν η προδιαγραφή απαιτεί χειρισμό 1000 RPS, η δοκιμή φορτίου πρέπει να το επιβεβαιώσει με περιθώριο 20%. Σύμφωνα με το Netflix Tech Blog (2024), η δοκιμή φορτίου στο Netflix διεξάγεται με περιθώριο 2x από το φορτίο αιχμής: εάν αναμένονται 10000 RPS, η δοκιμή ελέγχει 20000 RPS. Αυτή η προσέγγιση εγγυάται σταθερότητα σε ξαφνικές αυξήσεις κυκλοφορίας.

Δεύτερος στόχος — εντοπισμός σημείων συμφόρησης (bottlenecks) στην αρχιτεκτονική. Τυπικά σημεία συμφόρησης σε mobile backends — βάση δεδομένων (αργά ερωτήματα), προσωρινή μνήμη (λανθασμένη στρατηγική ακύρωσης) και εξωτερικά API (αργές υπηρεσίες τρίτων). Distributed tracing (Jaeger, Zipkin) βοηθά στον εντοπισμό του προβλήματος σε επίπεδο συγκεκριμένης υπηρεσίας ή αιτήματος.

Τρίτος στόχος — προσδιορισμός σημείου κορεσμού (saturation point). Αυτή είναι η στιγμή όταν η προσθήκη νέων χρηστών σταματά να αυξάνει την απόδοση μετάδοσης. Σε εφαρμογές για κινητά, το σημείο κορεσμού συχνά επέρχεται στο 70–80% φορτίου CPU στους διακομιστές βάσης δεδομένων. Auto-scaling πρέπει να ενεργοποιείται πριν από την επίτευξη αυτού του σημείου.

Σενάρια δοκιμής φορτίου

Φορτίο αιχμής (Spike Test) — μοντελοποίηση ξαφνικής αύξησης δραστηριότητας, για παράδειγμα πρωινή αποστολή push ειδοποιήσεων ή έναρξη διαφημιστικής καμπάνιας. Σύμφωνα με το Grafana k6 (2025), το Spike Test προσομοιώνει αύξηση φορτίου από 100 σε 10000 RPS σε 30 δευτερόλεπτα. Το σύστημα πρέπει να το διαχειρίζεται χωρίς απώλεια αιτημάτων και χωρίς υπέρβαση του χρόνου απόκρισης περισσότερο από 50%.

Σταθερό φορτίο (Endurance Test) — έλεγχος σταθερότητας του συστήματος υπό μακροχρόνια λειτουργία με φορτίο. Τυπική διάρκεια — 1–4 ώρες. Το Endurance Test αποκαλύπτει διαρροές μνήμης σε εφαρμογές διακομιστή, προβλήματα με το pool συνδέσεων βάσης δεδομένων και υποβάθμιση απόδοσης της προσωρινής μνήμης. Το pool συνδέσεων της PostgreSQL υπό μακροχρόνιο φορτίο χωρίς σωστή διαμόρφωση μπορεί να εξαντλήσει τις διαθέσιμες συνδέσεις εντός 2–3 ωρών λειτουργίας.

Κλιμακωτό φορτίο (Step Load Test) — σταδιακή αύξηση φορτίου με βήμα 10–20% κάθε 2–5 λεπτά. Αυτό το σενάριο βοηθά στην εύρεση του ακριβούς ορίου μετά το οποίο το σύστημα υποβαθμίζεται. InfluxDB και Prometheus συλλέγουν μετρήσεις σε κάθε βήμα για την κατασκευή γραφήματος εξάρτησης του χρόνου απόκρισης από το RPS.

Μετρήσεις Load Test

Χρόνος απόκρισης

Χρόνος απόκρισης (Response Time) — κύρια μέτρηση του Load Test. Μετριέται σε χιλιοστά του δευτερολέπτου και αναλύεται βάσει εκατοστημορίων: p50 (διάμεσος), p95 και p99. Το Google SRE (2024) συνιστά όριο p95 όχι μεγαλύτερο από 1000 ms για REST API και όχι μεγαλύτερο από 200 ms για gRPC. Τα εκατοστημόρια είναι πιο σημαντικά από τον μέσο όρο, επειδή δείχνουν τη συμπεριφορά των χειρότερων αιτημάτων που οι χρήστες παρατηρούν πρώτα. Apdex (Application Performance Index) — σύνθετη μέτρηση που λαμβάνει υπόψη την αναλογία ικανοποιημένων, ανεκτικών και απογοητευμένων χρηστών.

Απόδοση μετάδοσης

Απόδοση μετάδοσης (Throughput) — αριθμός επιτυχημένων αιτημάτων ανά μονάδα χρόνου. Μετριέται σε RPS (requests per second) ή TPS (transactions per second). Το γράφημα Throughput σε συντεταγμένες “χρόνος — RPS” πρέπει να είναι γραμμικό μέχρι το σημείο κορεσμού. Η απότομη πτώση του Throughput κατά την αύξηση φορτίου — σημάδι επίτευξης του ορίου του συστήματος. Apache Bench και wrk — απλά εργαλεία CLI για γρήγορο έλεγχο του Throughput στο στάδιο ανάπτυξης.

Ποσοστό σφαλμάτων

Ποσοστό σφαλμάτων (Error Rate) — αναλογία αποκρίσεων με κατάσταση HTTP 4xx ή 5xx προς τον συνολικό αριθμό αιτημάτων. Επιτρεπόμενο όριο — λιγότερο από 1%. Τα σφάλματα 429 (Too Many Requests) και 503 (Service Unavailable) υπό υψηλό φορτίο υποδεικνύουν την ανάγκη διαμόρφωσης rate limiting και auto-scaling. Το Rate limiter στην πλευρά του API Gateway προστατεύει το backend από υπέρβαση του επιτρεπόμενου φορτίου. Retry policy με εκθετική υπαναχώρηση βοηθά τους πελάτες να χειρίζονται σωστά τα προσωρινά σφάλματα.

Εργαλεία για Load Test

k6 (Grafana)

k6 — κορυφαίο εργαλείο ανοιχτού κώδικα για δοκιμή φορτίου από τη Grafana. Τα σενάρια γράφονται σε JavaScript, υποστηρίζουν αρθρωτά σενάρια, όρια (thresholds) και ενσωμάτωση με Prometheus και InfluxDB. Το k6 μπορεί να εκτελεστεί τόσο σε CLI όσο και στο cloud Grafana Cloud k6. Grafana Cloud δημιουργεί αυτόματα πίνακες ελέγχου βάσει των αποτελεσμάτων Load Test και τα συγκρίνει με ιστορικά δεδομένα. Το k6 υποστηρίζει Protocol Buffers και gRPC μέσω ξεχωριστής μονάδας k6/net/grpc.

Apache JMeter

Apache JMeter — κλασικό εργαλείο για Load Test με γραφική διεπαφή. Υποστηρίζει ευρύ φάσμα πρωτοκόλλων: HTTP, JDBC, JMS, FTP και TCP. Το JMeter είναι πιο κατάλληλο για σύνθετα σενάρια με πολλούς διαφορετικούς τύπους αιτημάτων, αλλά απαιτεί περισσότερη μη αυτόματη διαμόρφωση σε σύγκριση με το k6. JMeter Plugins επεκτείνουν τη λειτουργικότητα για δοκιμή WebSocket και gRPC. Για κατανεμημένη εκτέλεση, το JMeter χρησιμοποιεί αρχιτεκτονική master-slave με έναν ελεγκτή.

Locust

Locust — εργαλείο βασισμένο σε Python που επιτρέπει την περιγραφή σεναρίων φορτίου σε κώδικα. Το Locust είναι βολικό για ομάδες που χρησιμοποιούν Python ως κύρια γλώσσα αυτοματισμού. Σε αντίθεση με τα k6 και JMeter, το Locust υποστηρίζει κατανεμημένη εκτέλεση εκτός συσκευασίας: ένας master-node συντονίζει πολλούς worker-nodes. Κατανεμημένη εκτέλεση επιτρέπει τη δημιουργία φορτίου έως 100000 RPS από πολλά μηχανήματα. Το Locust υποστηρίζει επίσης δοκιμή WebSocket μέσω προσαρμοσμένων επεκτάσεων.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Παράδειγμα σύνταξης Load Test σε k6

Το παραπάνω σενάριο k6 δείχνει την τυπική δομή μιας δοκιμής φορτίου. Το Options καθορίζει το προφίλ φορτίου: ramp-up 2 λεπτά έως 100 χρήστες, στη συνέχεια 5 λεπτά σταθερού φορτίου και ξανά ramp-up έως 200 χρήστες. Thresholds καθορίζουν τα κριτήρια επιτυχίας της δοκιμής: p95 χρόνου αιτήματος όχι περισσότερο από 500 ms, ποσοστό σφαλμάτων λιγότερο από 1%. Εάν τα όρια ξεπεραστούν, το k6 ολοκληρώνει τη δοκιμή με μη μηδενικό κωδικό — αυτό επιτρέπει την ενσωμάτωση του Load Test σε CI/CD.

Στην ανάπτυξη εφαρμογών για κινητά, το Load Test του διακομιστή είναι ιδιαίτερα σημαντικό κατά την κυκλοφορία νέων λειτουργιών που δημιουργούν πρόσθετο φορτίο: likes, σχόλια, streaming. Σύσταση — διεξάγετε Load Test σε κάθε staging πριν από την προώθηση στην παραγωγή. Η δημιουργία βασικού προφίλ φορτίου στο στάδιο σχεδιασμού API βοηθά στην αποφυγή αρχιτεκτονικών προβλημάτων σε μεταγενέστερα στάδια.