Οι εφαρμογές Ιστού χρησιμοποιούνται πλέον παντού και μεταξύ όλων των πρωτοκόλλων μεταφοράς, το HTTP καταλαμβάνει τη μερίδα του λέοντος. Κατά τη μελέτη των αποχρώσεων της ανάπτυξης εφαρμογών Ιστού, οι περισσότεροι άνθρωποι δίνουν πολύ λίγη προσοχή στο λειτουργικό σύστημα όπου εκτελούνται πραγματικά αυτές οι εφαρμογές. Ο διαχωρισμός της ανάπτυξης (Dev) και των λειτουργιών (Ops) επιδείνωσε την κατάσταση. Αλλά με την άνοδο της κουλτούρας DevOps, οι προγραμματιστές γίνονται υπεύθυνοι για την εκτέλεση των εφαρμογών τους στο cloud, επομένως είναι πολύ χρήσιμο για αυτούς να εξοικειωθούν πλήρως με το backend του λειτουργικού συστήματος. Αυτό είναι ιδιαίτερα χρήσιμο εάν προσπαθείτε να αναπτύξετε ένα σύστημα για χιλιάδες ή δεκάδες χιλιάδες ταυτόχρονες συνδέσεις.
Οι περιορισμοί στις υπηρεσίες web είναι πολύ παρόμοιοι με αυτούς σε άλλες εφαρμογές. Είτε πρόκειται για εξισορροπητές φορτίου είτε για διακομιστές βάσης δεδομένων, όλες αυτές οι εφαρμογές έχουν παρόμοια προβλήματα σε περιβάλλον υψηλής απόδοσης. Η κατανόηση αυτών των θεμελιωδών περιορισμών και του πώς να τους ξεπεράσετε γενικά θα σας βοηθήσει να αξιολογήσετε την απόδοση και την επεκτασιμότητα των διαδικτυακών εφαρμογών σας.
Γράφω αυτή τη σειρά άρθρων ως απάντηση σε ερωτήσεις νεαρών προγραμματιστών που θέλουν να γίνουν καλά ενημερωμένοι αρχιτέκτονες συστημάτων. Είναι αδύνατο να κατανοήσουμε με σαφήνεια τις τεχνικές βελτιστοποίησης εφαρμογών Linux χωρίς να εμβαθύνουμε στα βασικά του τρόπου λειτουργίας τους σε επίπεδο λειτουργικού συστήματος. Παρόλο που υπάρχουν πολλοί τύποι εφαρμογών, σε αυτήν τη σειρά θέλω να εξερευνήσω εφαρμογές που βασίζονται στον ιστό και όχι εφαρμογές επιτραπέζιου υπολογιστή, όπως πρόγραμμα περιήγησης ή πρόγραμμα επεξεργασίας κειμένου. Αυτό το υλικό προορίζεται για προγραμματιστές και αρχιτέκτονες που θέλουν να κατανοήσουν πώς λειτουργούν τα προγράμματα Linux ή Unix και πώς να τα δομήσουν για υψηλή απόδοση.
Το Linux είναι δωμάτιο διακομιστή λειτουργικό σύστημα και τις περισσότερες φορές οι εφαρμογές σας εκτελούνται σε αυτό το λειτουργικό σύστημα. Αν και λέω "Linux", τις περισσότερες φορές μπορείτε να υποθέσετε με ασφάλεια ότι εννοώ όλα τα λειτουργικά συστήματα που μοιάζουν με Unix γενικά. Ωστόσο, δεν έχω δοκιμάσει τον συνοδευτικό κώδικα σε άλλα συστήματα. Επομένως, αν σας ενδιαφέρει το FreeBSD ή το OpenBSD, τα αποτελέσματά σας μπορεί να διαφέρουν. Όταν δοκιμάζω κάτι συγκεκριμένο για Linux, το επισημαίνω.
Αν και μπορείτε να χρησιμοποιήσετε αυτή τη γνώση για να δημιουργήσετε μια εφαρμογή από την αρχή και θα είναι τέλεια βελτιστοποιημένη, είναι καλύτερο να μην το κάνετε αυτό. Εάν γράψετε έναν νέο διακομιστή ιστού σε C ή C++ για την επιχειρηματική εφαρμογή του οργανισμού σας, αυτή μπορεί να είναι η τελευταία σας ημέρα στη δουλειά. Ωστόσο, η γνώση της δομής αυτών των εφαρμογών θα βοηθήσει στην επιλογή των υπαρχόντων προγραμμάτων. Θα μπορείτε να συγκρίνετε συστήματα που βασίζονται σε διαδικασίες με συστήματα που βασίζονται σε νήματα καθώς και με συστήματα που βασίζονται σε συμβάντα. Θα καταλάβετε και θα εκτιμήσετε γιατί το Nginx αποδίδει καλύτερα από το Apache httpd, γιατί μια εφαρμογή Python που βασίζεται σε Tornado μπορεί να εξυπηρετήσει περισσότερους χρήστες σε σύγκριση με μια εφαρμογή Python που βασίζεται στο Django.
ZeroHTTPd: Εργαλείο εκμάθησης
είναι ένας διακομιστής ιστού που έγραψα από την αρχή στο C ως εργαλείο διδασκαλίας. Δεν έχει εξωτερικές εξαρτήσεις, συμπεριλαμβανομένης της πρόσβασης στο Redis. Τρέχουμε τις δικές μας διαδικασίες Redis. Δείτε παρακάτω για περισσότερες λεπτομέρειες.
Αν και θα μπορούσαμε να συζητήσουμε εκτενώς τη θεωρία, δεν υπάρχει τίποτα καλύτερο από τη σύνταξη κώδικα, την εκτέλεση του και τη σύγκριση όλων των αρχιτεκτονικών διακομιστών μεταξύ τους. Αυτή είναι η πιο προφανής μέθοδος. Επομένως, θα γράψουμε έναν απλό διακομιστή ιστού ZeroHTTPd χρησιμοποιώντας κάθε μοντέλο: βασισμένο σε διεργασίες, σε νήματα και σε συμβάντα. Ας ελέγξουμε κάθε έναν από αυτούς τους διακομιστές και ας δούμε πώς αποδίδουν ο ένας με τον άλλο. Το ZeroHTTPd υλοποιείται σε ένα μόνο αρχείο C. Ο διακομιστής που βασίζεται σε συμβάντα περιλαμβάνει , μια εξαιρετική υλοποίηση πίνακα κατακερματισμού που έρχεται σε ένα μόνο αρχείο κεφαλίδας. Σε άλλες περιπτώσεις, δεν υπάρχουν εξαρτήσεις, για να μην περιπλέκεται το έργο.
Υπάρχουν πολλά σχόλια στον κώδικα για να σας βοηθήσουν να καταλάβετε. Όντας ένας απλός διακομιστής ιστού σε λίγες γραμμές κώδικα, το ZeroHTTPd είναι επίσης ένα ελάχιστο πλαίσιο για την ανάπτυξη ιστού. Έχει περιορισμένη λειτουργικότητα, αλλά είναι σε θέση να εξυπηρετεί στατικά αρχεία και πολύ απλές «δυναμικές» σελίδες. Πρέπει να πω ότι το ZeroHTTPd είναι καλό για να μάθετε πώς να δημιουργείτε εφαρμογές Linux υψηλής απόδοσης. Σε γενικές γραμμές, οι περισσότερες υπηρεσίες web περιμένουν αιτήματα, τα ελέγχουν και τα επεξεργάζονται. Αυτό ακριβώς θα κάνει το ZeroHTTPd. Αυτό είναι ένα εργαλείο μάθησης, όχι παραγωγής. Δεν είναι εξαιρετικό στον χειρισμό σφαλμάτων και είναι απίθανο να υπερηφανεύεται για τις βέλτιστες πρακτικές ασφαλείας (ω ναι, χρησιμοποίησα strcpy) ή τα έξυπνα κόλπα της γλώσσας Γ. Ελπίζω όμως να κάνει καλά τη δουλειά του.
Αρχική σελίδα ZeroHTTPd. Μπορεί να εξάγει διαφορετικούς τύπους αρχείων, συμπεριλαμβανομένων εικόνων
Εφαρμογή βιβλίου επισκεπτών
Οι σύγχρονες διαδικτυακές εφαρμογές συνήθως δεν περιορίζονται σε στατικά αρχεία. Έχουν πολύπλοκες αλληλεπιδράσεις με διάφορες βάσεις δεδομένων, κρυφές μνήμες κλπ. Έτσι θα δημιουργήσουμε μια απλή διαδικτυακή εφαρμογή που ονομάζεται "Βιβλίο επισκεπτών" όπου οι επισκέπτες αφήνουν καταχωρήσεις με τα ονόματά τους. Οι καταχωρήσεις στα βιβλιοπωλεία επισκεπτών έφυγαν νωρίτερα. Υπάρχει επίσης μετρητής επισκεπτών στο κάτω μέρος της σελίδας.
Εφαρμογή Web "Βιβλίο επισκεπτών" ZeroHTTPd
Ο μετρητής επισκεπτών και οι καταχωρήσεις του βιβλίου επισκεπτών αποθηκεύονται στο Redis. Για τις επικοινωνίες με το Redis, εφαρμόζονται οι δικές τους διαδικασίες που δεν εξαρτώνται από την εξωτερική βιβλιοθήκη. Δεν είμαι μεγάλος οπαδός της κυκλοφορίας του κώδικα homebrew όταν υπάρχουν διαθέσιμες στο κοινό και καλά δοκιμασμένες λύσεις. Όμως ο σκοπός του ZeroHTTPd είναι να μελετήσει την απόδοση του Linux και την πρόσβαση σε εξωτερικές υπηρεσίες, ενώ η εξυπηρέτηση αιτημάτων HTTP έχει σοβαρό αντίκτυπο στην απόδοση. Πρέπει να ελέγχουμε πλήρως τις επικοινωνίες με το Redis σε κάθε αρχιτεκτονική διακομιστή μας. Σε ορισμένες αρχιτεκτονικές χρησιμοποιούμε κλήσεις αποκλεισμού, σε άλλες χρησιμοποιούμε διαδικασίες που βασίζονται σε συμβάντα. Η χρήση μιας εξωτερικής βιβλιοθήκης πελάτη Redis δεν παρέχει αυτό το στοιχείο ελέγχου. Επιπλέον, ο μικρός μας πελάτης Redis εκτελεί μόνο μερικές λειτουργίες (λήψη, ρύθμιση και αύξηση ενός κλειδιού, λήψη και προσθήκη σε έναν πίνακα). Επιπλέον, το πρωτόκολλο Redis είναι εξαιρετικά κομψό και απλό. Δεν χρειάζεται καν να το διδάξετε ειδικά. Το ίδιο το γεγονός ότι το πρωτόκολλο κάνει όλη τη δουλειά σε περίπου εκατό γραμμές κώδικα δείχνει πόσο καλά μελετημένο είναι.
Το παρακάτω σχήμα δείχνει τι κάνει η εφαρμογή όταν ζητά ο πελάτης (πρόγραμμα περιήγησης). /guestbookURL.
Πώς λειτουργεί η εφαρμογή βιβλίου επισκεπτών
Όταν χρειάζεται να εκδοθεί μια σελίδα βιβλίου επισκεπτών, υπάρχει μία κλήση στο σύστημα αρχείων για ανάγνωση του προτύπου στη μνήμη και τρεις κλήσεις δικτύου στο Redis. Το αρχείο προτύπου περιέχει το μεγαλύτερο μέρος του περιεχομένου HTML για τη σελίδα στο παραπάνω στιγμιότυπο οθόνης. Υπάρχουν επίσης ειδικά σύμβολα κράτησης θέσης για το δυναμικό μέρος του περιεχομένου: αναρτήσεις και μετρητής επισκεπτών. Τα λαμβάνουμε από τη Redis, τα εισάγουμε στη σελίδα και παρέχουμε στον πελάτη πλήρως διαμορφωμένο περιεχόμενο. Η τρίτη κλήση στο Redis μπορεί να αποφευχθεί επειδή το Redis επιστρέφει τη νέα τιμή κλειδιού όταν προσαυξάνεται. Ωστόσο, για τον διακομιστή μας, ο οποίος έχει μια ασύγχρονη αρχιτεκτονική που βασίζεται σε συμβάντα, πολλές κλήσεις δικτύου είναι μια καλή δοκιμή για μαθησιακούς σκοπούς. Έτσι, απορρίπτουμε την τιμή επιστροφής Redis για τον αριθμό των επισκεπτών και ρωτάμε με μια ξεχωριστή κλήση.
Αρχιτεκτονικές διακομιστή ZeroHTTPd
Κατασκευάζουμε επτά εκδόσεις του ZeroHTTPd με την ίδια λειτουργικότητα αλλά διαφορετικές αρχιτεκτονικές:
- Επαναληπτικός
- Διακομιστής Fork (μία θυγατρική διαδικασία ανά αίτημα)
- Διακομιστής Pre-fork (προδιακλάδωση διεργασιών)
- Διακομιστής με νήματα εκτέλεσης (ένα νήμα ανά αίτημα)
- Διακομιστής με δημιουργία pre-thread
- Με βάση την αρχιτεκτονική
poll() - Με βάση την αρχιτεκτονική
epoll
Μετράμε την απόδοση κάθε αρχιτεκτονικής φορτώνοντας τον διακομιστή με αιτήματα HTTP. Αλλά όταν συγκρίνουμε πολύ παράλληλες αρχιτεκτονικές, ο αριθμός των ερωτημάτων αυξάνεται. Δοκιμάζουμε τρεις φορές και υπολογίζουμε τον μέσο όρο.
Μεθοδολογία δοκιμών
Ρύθμιση δοκιμής φορτίου ZeroHTTPd
Είναι σημαντικό κατά την εκτέλεση δοκιμών, όλα τα εξαρτήματα να μην εκτελούνται στο ίδιο μηχάνημα. Σε αυτήν την περίπτωση, το λειτουργικό σύστημα επιβαρύνεται με πρόσθετο κόστος προγραμματισμού καθώς τα στοιχεία ανταγωνίζονται για την CPU. Η μέτρηση της επιβάρυνσης του λειτουργικού συστήματος για καθεμία από τις επιλεγμένες αρχιτεκτονικές διακομιστή είναι ένας από τους πιο σημαντικούς στόχους αυτής της άσκησης. Η προσθήκη περισσότερων μεταβλητών θα καταστεί επιζήμια για τη διαδικασία. Επομένως, η ρύθμιση στην παραπάνω εικόνα λειτουργεί καλύτερα.
Τι κάνει καθένας από αυτούς τους διακομιστές;
- load.unixism.net: Εδώ τρέχουμε
ab, βοηθητικό πρόγραμμα Apache Benchmark. Δημιουργεί το φορτίο που απαιτείται για τη δοκιμή των αρχιτεκτονικών των διακομιστών μας. - nginx.unixism.net: Μερικές φορές θέλουμε να εκτελέσουμε περισσότερες από μία παρουσίες ενός προγράμματος διακομιστή. Για να γίνει αυτό, ο διακομιστής Nginx με τις κατάλληλες ρυθμίσεις λειτουργεί ως εξισορρόπηση φορτίου που προέρχεται από ab στις διαδικασίες του διακομιστή μας.
- zerohttpd.unixism.net: Εδώ εκτελούμε τα προγράμματα διακομιστή μας σε επτά διαφορετικές αρχιτεκτονικές, μία κάθε φορά.
- redis.unixism.net: Αυτός ο διακομιστής εκτελεί τον δαίμονα Redis, όπου αποθηκεύονται οι καταχωρήσεις στο βιβλίο επισκεπτών και οι μετρητές επισκεπτών.
Όλοι οι διακομιστές λειτουργούν στον ίδιο πυρήνα επεξεργαστή. Η ιδέα είναι να αξιολογηθεί η μέγιστη απόδοση κάθε αρχιτεκτονικής. Δεδομένου ότι όλα τα προγράμματα διακομιστών δοκιμάζονται στο ίδιο υλικό, αυτή είναι μια βάση σύγκρισης. Η δοκιμαστική μου εγκατάσταση αποτελείται από εικονικούς διακομιστές που νοικιάζονται από την Digital Ocean.
Τι μετράμε;
Μπορείτε να μετρήσετε διαφορετικούς δείκτες. Αξιολογούμε την απόδοση κάθε αρχιτεκτονικής σε μια δεδομένη διαμόρφωση φορτώνοντας τους διακομιστές με αιτήματα σε διαφορετικά επίπεδα παραλληλισμού: το φορτίο αυξάνεται από 20 σε 15 ταυτόχρονους χρήστες.
Αποτελέσματα δοκιμών
Το παρακάτω γράφημα δείχνει την απόδοση των διακομιστών σε διαφορετικές αρχιτεκτονικές σε διαφορετικά επίπεδα παραλληλισμού. Ο άξονας y είναι ο αριθμός των αιτημάτων ανά δευτερόλεπτο, ο άξονας x είναι παράλληλες συνδέσεις.
Ακολουθεί πίνακας με τα αποτελέσματα.
αιτήματα ανά δευτερόλεπτο
συνοχή
επαναληπτικός
πιρούνι
προ-πηρούνι
streaming
πριν από τη ροή
ψηφοφορία
επολ
20
7
112
2100
1800
2250
1900
2050
50
7
190
2200
1700
2200
2000
2000
100
7
245
2200
1700
2200
2150
2100
200
7
330
2300
1750
2300
2200
2100
300
-
380
2200
1800
2400
2250
2150
400
-
410
2200
1750
2600
2000
2000
500
-
440
2300
1850
2700
1900
2212
600
-
460
2400
1800
2500
1700
2519
700
-
460
2400
1600
2490
1550
2607
800
-
460
2400
1600
2540
1400
2553
900
-
460
2300
1600
2472
1200
2567
1000
-
475
2300
1700
2485
1150
2439
1500
-
490
2400
1550
2620
900
2479
2000
-
350
2400
1400
2396
550
2200
2500
-
280
2100
1300
2453
490
2262
3000
-
280
1900
1250
2502
μεγάλη εξάπλωση
2138
5000
-
μεγάλη εξάπλωση
1600
1100
2519
-
2235
8000
-
-
1200
μεγάλη εξάπλωση
2451
-
2100
10 000
-
-
μεγάλη εξάπλωση
-
2200
-
2200
11 000
-
-
-
-
2200
-
2122
12 000
-
-
-
-
970
-
1958
13 000
-
-
-
-
730
-
1897
14 000
-
-
-
-
590
-
1466
15 000
-
-
-
-
532
-
1281
Από το γράφημα και τον πίνακα φαίνεται ότι πάνω από 8000 ταυτόχρονα αιτήματα έχουμε μόνο δύο παίκτες: pre-fork και epoll. Καθώς το φορτίο αυξάνεται, ένας διακομιστής που βασίζεται σε δημοσκοπήσεις έχει χειρότερη απόδοση από έναν διακομιστή ροής. Η αρχιτεκτονική του νήματος πριν από τη δημιουργία είναι ένας άξιος ανταγωνιστής του epoll, μια απόδειξη του πόσο καλά ο πυρήνας του Linux προγραμματίζει μεγάλους αριθμούς νημάτων.
Πηγαίος κώδικας ZeroHTTPd
Πηγαίος κώδικας ZeroHTTPd . Υπάρχει ξεχωριστός κατάλογος για κάθε αρχιτεκτονική.
ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── ├├── 03_preforking ├├── 04_preforking _thread ing │ ├── main.c ├── 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └─├ └──├─── main.c ─ ├── index.html │ └── tux . png └── πρότυπα └── βιβλίο επισκεπτών └── index.html
Εκτός από επτά καταλόγους για όλες τις αρχιτεκτονικές, υπάρχουν άλλοι δύο στον κατάλογο ανώτατου επιπέδου: δημόσιος και πρότυπα. Το πρώτο περιέχει το αρχείο index.html και την εικόνα από το πρώτο στιγμιότυπο οθόνης. Μπορείτε να βάλετε άλλα αρχεία και φακέλους εκεί και το ZeroHTTPd θα πρέπει να εξυπηρετήσει αυτά τα στατικά αρχεία χωρίς κανένα πρόβλημα. Εάν η διαδρομή στο πρόγραμμα περιήγησης ταιριάζει με τη διαδρομή στον δημόσιο φάκελο, τότε το ZeroHTTPd αναζητά το αρχείο index.html σε αυτόν τον κατάλογο. Το περιεχόμενο για το βιβλίο επισκεπτών δημιουργείται δυναμικά. Έχει μόνο μια αρχική σελίδα και το περιεχόμενό της βασίζεται στο αρχείο «templates/guestbook/index.html». Το ZeroHTTPd προσθέτει εύκολα δυναμικές σελίδες για επέκταση. Η ιδέα είναι ότι οι χρήστες μπορούν να προσθέσουν πρότυπα σε αυτόν τον κατάλογο και να επεκτείνουν το ZeroHTTPd όπως απαιτείται.
Για να δημιουργήσετε και τους επτά διακομιστές, εκτελέστε make all από τον κατάλογο ανώτατου επιπέδου - και όλες οι εκδόσεις θα εμφανιστούν σε αυτόν τον κατάλογο. Τα εκτελέσιμα αρχεία αναζητούν τους δημόσιους καταλόγους και τα πρότυπα στον κατάλογο από τον οποίο εκκινούνται.
Linux API
Δεν χρειάζεται να είστε καλά γνώστες του Linux API για να κατανοήσετε τις πληροφορίες αυτής της σειράς άρθρων. Ωστόσο, συνιστώ να διαβάσετε περισσότερα για αυτό το θέμα· υπάρχουν πολλοί πόροι αναφοράς στο Διαδίκτυο. Αν και θα αγγίξουμε διάφορες κατηγορίες Linux API, η εστίασή μας θα είναι κυρίως σε διαδικασίες, νήματα, συμβάντα και τη στοίβα δικτύου. Εκτός από τα βιβλία και τα άρθρα σχετικά με το Linux API, συνιστώ επίσης την ανάγνωση mana για κλήσεις συστήματος και λειτουργίες βιβλιοθήκης που χρησιμοποιούνται.
Απόδοση και Επεκτασιμότητα
Μια σημείωση σχετικά με την απόδοση και την επεκτασιμότητα. Θεωρητικά, δεν υπάρχει καμία σχέση μεταξύ τους. Μπορείτε να έχετε μια υπηρεσία web που λειτουργεί πολύ καλά, με χρόνο απόκρισης μερικών χιλιοστών του δευτερολέπτου, αλλά δεν κλιμακώνεται καθόλου. Ομοίως, μπορεί να υπάρχει μια εφαρμογή Ιστού με κακή απόδοση που χρειάζεται μερικά δευτερόλεπτα για να ανταποκριθεί, αλλά κλιμακώνεται κατά δεκάδες για να χειριστεί δεκάδες χιλιάδες ταυτόχρονους χρήστες. Ωστόσο, ο συνδυασμός υψηλής απόδοσης και επεκτασιμότητας είναι ένας πολύ ισχυρός συνδυασμός. Οι εφαρμογές υψηλής απόδοσης γενικά χρησιμοποιούν πόρους με φειδώ και έτσι εξυπηρετούν αποτελεσματικά περισσότερους ταυτόχρονους χρήστες στον διακομιστή, μειώνοντας το κόστος.
Εργασίες CPU και I/O
Τέλος, στους υπολογιστές υπάρχουν πάντα δύο πιθανοί τύποι εργασιών: για I/O και CPU. Η λήψη αιτημάτων μέσω του Διαδικτύου (I/O δικτύου), η εξυπηρέτηση αρχείων (δίκτυο και I/O δίσκος), η επικοινωνία με τη βάση δεδομένων (δίκτυο και I/O δίσκος) είναι όλες οι δραστηριότητες I/O. Ορισμένα ερωτήματα της βάσης δεδομένων μπορεί να απαιτούν λίγο CPU (ταξινόμηση, κατά μέσο όρο ένα εκατομμύριο αποτελέσματα, κ.λπ.). Οι περισσότερες εφαρμογές Ιστού περιορίζονται από τη μέγιστη δυνατή I/O και ο επεξεργαστής σπάνια χρησιμοποιείται σε πλήρη χωρητικότητα. Όταν βλέπετε ότι κάποια εργασία I/O χρησιμοποιεί πολλή CPU, είναι πιθανότατα σημάδι κακής αρχιτεκτονικής εφαρμογών. Αυτό μπορεί να σημαίνει ότι οι πόροι της CPU σπαταλούνται για τη διαχείριση διεργασιών και την εναλλαγή περιβάλλοντος - και αυτό δεν είναι απολύτως χρήσιμο. Εάν κάνετε κάτι όπως επεξεργασία εικόνας, μετατροπή αρχείων ήχου ή μηχανική εκμάθηση, τότε η εφαρμογή απαιτεί ισχυρούς πόρους CPU. Αλλά για τις περισσότερες εφαρμογές αυτό δεν ισχύει.
Μάθετε περισσότερα σχετικά με τις αρχιτεκτονικές διακομιστή
Πηγή: www.habr.com