Υπάρχουν μόνο δύο σκληρά πράγματα στην Επιστήμη των Υπολογιστών: ακύρωση προσωρινής μνήμης και ονομασία πραγμάτων.

• Συγγραφέας: Phil Karlton

Μια σύντομη εισαγωγή στο Caching

Η προσωρινή αποθήκευση είναι μια ισχυρή τεχνική για την αύξηση της απόδοσης μέσω ενός απλού κόλπου: Αντί να κάνουμε ακριβή εργασία (όπως ένας περίπλοκος υπολογισμός ή ένα σύνθετο ερώτημα βάσης δεδομένων) κάθε φορά που χρειαζόμαστε ένα αποτέλεσμα, το σύστημα μπορεί να αποθηκεύσει - ή να αποθηκεύσει προσωρινά - το αποτέλεσμα αυτής της εργασίας και απλά προμηθεύστε την την επόμενη φορά που θα ζητηθεί χωρίς να χρειάζεται να επαναλάβετε αυτήν την εργασία (και, ως εκ τούτου, μπορεί να ανταποκριθεί πολύ πιο γρήγορα).

Φυσικά, όλη η ιδέα πίσω από την προσωρινή αποθήκευση λειτουργεί μόνο εφόσον το αποτέλεσμα που αποθηκεύσαμε στην κρυφή μνήμη παραμένει έγκυρο. Και εδώ φτάνουμε στο πραγματικό δύσκολο μέρος του προβλήματος: Πώς καθορίζουμε πότε ένα προσωρινά αποθηκευμένο στοιχείο έχει καταστεί άκυρο και πρέπει να αναδημιουργηθεί;

Η κρυφή μνήμη ASP.NET είναι εξαιρετικά γρήγορη
και τέλειο για την επίλυση του κατανεμημένου προβλήματος αποθήκευσης στο web farm Τιτίβισμα

Συνήθως, μια τυπική εφαρμογή ιστού πρέπει να ασχολείται με πολύ μεγαλύτερο όγκο αιτημάτων ανάγνωσης από ό, τι τα αιτήματα εγγραφής. Αυτός είναι ο λόγος για τον οποίο μια τυπική εφαρμογή ιστού που έχει σχεδιαστεί για να χειρίζεται ένα υψηλό φορτίο είναι σχεδιασμένη ώστε να είναι επεκτάσιμη και να διανέμεται, αναπτύσσεται ως ένα σύνολο κόμβων βαθμίδας ιστού, που συνήθως ονομάζεται αγρόκτημα. Όλα αυτά τα γεγονότα έχουν αντίκτυπο στη δυνατότητα εφαρμογής της προσωρινής αποθήκευσης.

Σε αυτό το άρθρο, εστιάζουμε στον ρόλο που μπορεί να παίξει η προσωρινή αποθήκευση στην εξασφάλιση υψηλής απόδοσης και απόδοσης εφαρμογών ιστού που έχουν σχεδιαστεί για να χειρίζονται ένα υψηλό φορτίο και θα χρησιμοποιήσω την εμπειρία από ένα από τα έργα μου και θα παράσχω μια λύση που βασίζεται σε ASP.NET ως απεικόνιση.

Το πρόβλημα του χειρισμού υψηλού φορτίου

Το πραγματικό πρόβλημα που έπρεπε να λύσω δεν ήταν πρωτότυπο. Ο στόχος μου ήταν να φτιάξω ένα ASP.NET MVC το μονολιθικό πρωτότυπο εφαρμογής ιστού μπορεί να χειριστεί ένα υψηλό φορτίο.

μετατροπή μισθού σύμβασης σε πλήρη απασχόληση

Τα απαραίτητα βήματα για τη βελτίωση των δυνατοτήτων απόδοσης μιας μονολιθικής εφαρμογής ιστού είναι:

• Ενεργοποιήστε το για να εκτελεί παράλληλα πολλαπλά αντίγραφα της εφαρμογής ιστού, πίσω από έναν εξισορροπητή φορτίου και να εξυπηρετεί αποτελεσματικά όλες τις ταυτόχρονες αιτήσεις (δηλ. Να την κάνει επεκτάσιμη).
• Προγραμματίστε την εφαρμογή για να αποκαλύψετε τις τρέχουσες δυσχέρειες απόδοσης και να τις βελτιστοποιήσετε.
• Χρησιμοποιήστε την προσωρινή μνήμη για να αυξήσετε την απόδοση αιτήσεων ανάγνωσης, καθώς αυτό συνήθως αποτελεί σημαντικό μέρος του συνολικού φορτίου εφαρμογών.

Οι στρατηγικές προσωρινής αποθήκευσης περιλαμβάνουν συχνά χρήση κάποιου διακομιστή προσωρινής αποθήκευσης μεσαίου λογισμικού, όπως το Memcached ή το Redis, για την αποθήκευση των αποθηκευμένων τιμών. Παρά την υψηλή υιοθεσία και αποδεδειγμένη εφαρμογή τους, υπάρχουν μερικά μειονεκτήματα σε αυτές τις προσεγγίσεις, όπως:

• Οι καθυστερήσεις δικτύου που εισάγονται μέσω της πρόσβασης στους ξεχωριστούς διακομιστές προσωρινής μνήμης μπορούν να συγκριθούν με τις καθυστερήσεις πρόσβασης στην ίδια τη βάση δεδομένων.
• Οι δομές δεδομένων της βαθμίδας ιστού μπορεί να είναι ακατάλληλες για σειριοποίηση και αποεστερίωση από το κουτί. Για να χρησιμοποιήσετε διακομιστές προσωρινής μνήμης, αυτές οι δομές δεδομένων θα πρέπει να υποστηρίζουν τη σειριοποίηση και την αποεριοποίηση, κάτι που απαιτεί συνεχή πρόσθετη προσπάθεια ανάπτυξης.
• Η σειριοποίηση και η αποεστεροποίηση προσθέτουν επιβάρυνση χρόνου εκτέλεσης με αρνητικές επιπτώσεις στην απόδοση.

Όλα αυτά τα ζητήματα ήταν σχετικά στην περίπτωσή μου, οπότε έπρεπε να διερευνήσω εναλλακτικές επιλογές.

Η ενσωματωμένη προσωρινή μνήμη ASP.NET στη μνήμη (System.Web.Caching.Cache) είναι εξαιρετικά γρήγορη και μπορεί να χρησιμοποιηθεί χωρίς εναέρια σειριοποίηση και αποεριοποίηση, τόσο κατά τη διάρκεια της ανάπτυξης όσο και κατά το χρόνο εκτέλεσης. Ωστόσο, η προσωρινή μνήμη ASP.NET έχει επίσης τα δικά της μειονεκτήματα:

• Κάθε κόμβος επιπέδου ιστού χρειάζεται το δικό του αντίγραφο των αποθηκευμένων τιμών. Αυτό θα μπορούσε να οδηγήσει σε υψηλότερη κατανάλωση βαθμίδας βάσης δεδομένων κατά την έναρξη ή την ανακύκλωση σε κόμβο.
• Κάθε κόμβος επιπέδου ιστού πρέπει να ειδοποιείται όταν ένας άλλος κόμβος καθιστά οποιοδήποτε τμήμα της προσωρινής μνήμης μη έγκυρο γράφοντας ενημερωμένες τιμές. Δεδομένου ότι η προσωρινή μνήμη διανέμεται και χωρίς σωστό συγχρονισμό, οι περισσότεροι από τους κόμβους θα επιστρέψουν παλιές τιμές που είναι συνήθως απαράδεκτες.

Εάν το πρόσθετο επίπεδο βάσης δεδομένων δεν οδηγεί από μόνο του σε δυσχέρεια, τότε η εφαρμογή μιας σωστά κατανεμημένης προσωρινής μνήμης φαίνεται σαν μια εύκολη εργασία, σωστά; Λοιπόν, δεν είναι Ανετα καθήκον, αλλά είναι δυνατόν . Στην περίπτωσή μου, τα σημεία αναφοράς έδειξαν ότι το επίπεδο βάσης δεδομένων δεν πρέπει να είναι πρόβλημα, καθώς το μεγαλύτερο μέρος της εργασίας συνέβη στο επίπεδο ιστού. Έτσι, αποφάσισα να πάω με την προσωρινή μνήμη ASP.NET και να επικεντρωθώ στην εφαρμογή του σωστού συγχρονισμού.

Παρουσιάζοντας μια λύση που βασίζεται σε ASP.NET

Όπως εξηγήθηκε, η λύση μου ήταν να χρησιμοποιήσω το ASP.NET στη μνήμη cache αντί για τον αποκλειστικό διακομιστή προσωρινής αποθήκευσης. Αυτό συνεπάγεται κάθε κόμβο του διαδικτυακού αγροκτήματος να έχει τη δική του προσωρινή μνήμη, να υποβάλλει ερώτημα στη βάση δεδομένων απευθείας, να εκτελεί τους απαραίτητους υπολογισμούς και να αποθηκεύει τα αποτελέσματα σε μια προσωρινή μνήμη. Με αυτόν τον τρόπο, όλες οι λειτουργίες της προσωρινής μνήμης θα είναι γρήγορες χάρη στη φύση της μνήμης στη μνήμη. Συνήθως, τα προσωρινά αποθηκευμένα αντικείμενα έχουν καθαρή διάρκεια ζωής και καθυστερούν μετά από κάποια αλλαγή ή συγγραφή νέων δεδομένων. Έτσι, από τη λογική της εφαρμογής ιστού, είναι συνήθως σαφές πότε πρέπει να ακυρωθεί το στοιχείο προσωρινής αποθήκευσης.

Το μόνο πρόβλημα που απομένει εδώ είναι ότι όταν ένας από τους κόμβους ακυρώνει ένα στοιχείο προσωρινής μνήμης στη δική του προσωρινή μνήμη, κανένας άλλος κόμβος δεν θα γνωρίζει αυτήν την ενημέρωση. Έτσι, τα επόμενα αιτήματα που εξυπηρετούνται από άλλους κόμβους θα αποφέρουν παλιότερα αποτελέσματα. Για να αντιμετωπιστεί αυτό, κάθε κόμβος πρέπει να μοιράζεται τις ακυρώσεις της προσωρινής μνήμης με τους άλλους κόμβους. Μετά τη λήψη αυτής της ακύρωσης, άλλοι κόμβοι θα μπορούσαν απλώς να μειώσουν την προσωρινά αποθηκευμένη τιμή τους και να λάβουν έναν νέο στο επόμενο αίτημα.

Εδώ, ο Redis μπορεί να παίξει. Η δύναμη του Redis, σε σύγκριση με άλλες λύσεις, προέρχεται από αυτό Δυνατότητες Pub / Sub . Κάθε πελάτης ενός διακομιστή Redis μπορεί να δημιουργήσει ένα κανάλι και να δημοσιεύσει ορισμένα δεδομένα σε αυτό. Οποιοσδήποτε άλλος πελάτης μπορεί να ακούσει αυτό το κανάλι και να λάβει τα σχετικά δεδομένα, πολύ παρόμοιο με οποιοδήποτε σύστημα που βασίζεται σε συμβάντα. Αυτή η λειτουργικότητα μπορεί να χρησιμοποιηθεί για την ανταλλαγή μηνυμάτων ακύρωσης προσωρινής μνήμης μεταξύ των κόμβων, επομένως όλοι οι κόμβοι θα μπορούν να ακυρώνουν την προσωρινή μνήμη τους όταν χρειάζεται.

είναι python γραμμένο σε γ

Η προσωρινή μνήμη του ASP.NET είναι απλή με κάποιους τρόπους και πολύπλοκη σε άλλους. Συγκεκριμένα, είναι απλό στο ότι λειτουργεί ως χάρτης ζευγών κλειδιών / τιμών, αλλά υπάρχει πολλή πολυπλοκότητα που σχετίζεται με τις στρατηγικές και τις εξαρτήσεις ακύρωσης.

Ευτυχώς, οι τυπικές περιπτώσεις χρήσης είναι αρκετά απλές και είναι δυνατό να χρησιμοποιήσετε μια προεπιλεγμένη στρατηγική ακύρωσης για όλα τα στοιχεία, επιτρέποντας σε κάθε στοιχείο της προσωρινής μνήμης να έχει μόνο μία εξάρτηση. Στην περίπτωσή μου, τελείωσα με τον ακόλουθο κωδικό ASP.NET για τη διεπαφή της υπηρεσίας προσωρινής αποθήκευσης. (Λάβετε υπόψη ότι αυτός δεν είναι ο πραγματικός κώδικας, καθώς παραλείψαμε ορισμένες λεπτομέρειες για λόγους απλότητας και της άδειας ιδιοκτησίας.)

public interface ICacheKey { string Value { get; } } public interface IDataCacheKey : ICacheKey { } public interface ITouchableCacheKey : ICacheKey { } public interface ICacheService { int ItemsCount { get; } T Get(IDataCacheKey key, Func valueGetter); T Get(IDataCacheKey key, Func valueGetter, ICacheKey dependencyKey); }

Εδώ, η υπηρεσία προσωρινής αποθήκευσης επιτρέπει βασικά δύο πράγματα. Πρώτον, επιτρέπει την αποθήκευση του αποτελέσματος κάποιας λειτουργίας λήψης αξίας με ασφαλή τρόπο στο νήμα. Δεύτερον, διασφαλίζει ότι η τότε τρέχουσα τιμή επιστρέφεται πάντα όταν ζητείται. Μόλις το στοιχείο κρυφής μνήμης γίνει παλιό ή εκδιώκεται ρητά από την κρυφή μνήμη, η τιμή λήψης καλείται ξανά για να ανακτήσει μια τρέχουσα τιμή. Το κλειδί προσωρινής μνήμης αφαιρέθηκε από ICacheKey διεπαφή, κυρίως για να αποφευχθεί ο σκληρός κωδικοποίηση των συμβολοσειρών κλειδιών cache σε όλη την εφαρμογή.

Για να ακυρώσω στοιχεία cache, εισήγαγα μια ξεχωριστή υπηρεσία, η οποία έμοιαζε με αυτήν:

public interface ICacheInvalidator { bool IsSessionOpen { get; } void OpenSession(); void CloseSession(); void Drop(IDataCacheKey key); void Touch(ITouchableCacheKey key); void Purge(); }

Εκτός από τις βασικές μεθόδους απόθεσης αντικειμένων με δεδομένα και πλήκτρα αφής, τα οποία είχαν μόνο εξαρτώμενα στοιχεία δεδομένων, υπάρχουν μερικές μέθοδοι που σχετίζονται με κάποιο είδος «συνεδρίας».

Χρησιμοποιήθηκε η διαδικτυακή μας εφαρμογή Autofac για εξάρτηση εξάρτησης, η οποία είναι μια εφαρμογή του αντιστροφή του ελέγχου (IoC) σχέδιο σχεδιασμού για τη διαχείριση εξαρτήσεων. Αυτή η δυνατότητα επιτρέπει στους προγραμματιστές να δημιουργήσουν τις τάξεις τους χωρίς να χρειάζεται να ανησυχούν για εξαρτήσεις, καθώς το κοντέινερ IoC διαχειρίζεται αυτό το βάρος για αυτούς.

Η υπηρεσία προσωρινής αποθήκευσης και ο ακυρωτής της προσωρινής μνήμης έχουν δραστικά διαφορετικούς κύκλους ζωής σχετικά με το IoC. Η υπηρεσία προσωρινής μνήμης καταχωρήθηκε ως μοναδική (μία παρουσία, κοινή χρήση μεταξύ όλων των πελατών), ενώ ο ακυρωτής προσωρινής μνήμης καταχωρήθηκε ως παρουσία ανά αίτημα (δημιουργήθηκε ξεχωριστή παρουσία για κάθε εισερχόμενη αίτηση). Γιατί;

Η απάντηση έχει να κάνει με μια επιπλέον λεπτότητα που χρειαζόμασταν για να χειριστούμε. Η διαδικτυακή εφαρμογή χρησιμοποιεί αρχιτεκτονική Model-View-Controller (MVC), η οποία βοηθά κυρίως στον διαχωρισμό των UI και των λογικών προβλημάτων. Έτσι, μια τυπική ενέργεια ελεγκτή τυλίγεται σε μια υποκατηγορία ενός ActionFilterAttribute. Στο πλαίσιο ASP.NET MVC, αυτά τα χαρακτηριστικά C # χρησιμοποιούνται για τη διακόσμηση της λογικής δράσης του ελεγκτή με κάποιο τρόπο. Το συγκεκριμένο χαρακτηριστικό ήταν υπεύθυνο για το άνοιγμα μιας νέας σύνδεσης βάσης δεδομένων και την έναρξη μιας συναλλαγής στην αρχή της ενέργειας. Επίσης, στο τέλος της ενέργειας, η δευτερεύουσα κατηγορία χαρακτηριστικών φίλτρου ήταν υπεύθυνη για την πραγματοποίηση της συναλλαγής σε περίπτωση επιτυχίας και την επαναφορά σε περίπτωση αποτυχίας.

Εάν η ακύρωση της προσωρινής μνήμης συνέβη ακριβώς στη μέση της συναλλαγής, θα μπορούσε να υπάρχει συνθήκη αγώνων σύμφωνα με την οποία το επόμενο αίτημα σε αυτόν τον κόμβο θα έβαλε με επιτυχία την παλιά (ακόμα ορατή σε άλλες συναλλαγές) τιμή στην κρυφή μνήμη. Για να αποφευχθεί αυτό, όλες οι ακυρώσεις αναβάλλονται έως ότου γίνει η συναλλαγή. Μετά από αυτό, τα στοιχεία της προσωρινής μνήμης είναι ασφαλή για έξωση και, σε περίπτωση αποτυχίας συναλλαγής, δεν χρειάζεται καθόλου τροποποίηση της προσωρινής μνήμης.

Αυτός ήταν ο ακριβής σκοπός των τμημάτων που σχετίζονται με την «περίοδο λειτουργίας» στον ακυρωτή της προσωρινής μνήμης. Επίσης, αυτός είναι ο σκοπός της διάρκειας ζωής του να δεσμεύεται από το αίτημα. Ο κωδικός ASP.NET έμοιαζε ως εξής:

class HybridCacheInvalidator : ICacheInvalidator { ... public void Drop(IDataCacheKey key) { if (key == null) throw new ArgumentNullException('key'); if (!IsSessionOpen) throw new InvalidOperationException('Session must be opened first.'); _postponedRedisMessages.Add(new Tuple('drop', key.Value)); } ... public void CloseSession() { if (!IsSessionOpen) return; _postponedRedisMessages.ForEach(m => PublishRedisMessageSafe(m.Item1, m.Item2)); _postponedRedisMessages = null; } ... }

Το PublishRedisMessageSafe Η μέθοδος εδώ είναι υπεύθυνη για την αποστολή του μηνύματος (δεύτερο όρισμα) σε ένα συγκεκριμένο κανάλι (πρώτο όρισμα). Στην πραγματικότητα, υπάρχουν ξεχωριστά κανάλια για πτώση και αφή, οπότε ο χειριστής μηνυμάτων για καθέναν από αυτούς ήξερε ακριβώς τι να κάνει - ρίξτε / αγγίξτε το κλειδί ίσο με το ληφθέν ωφέλιμο φορτίο μηνυμάτων.

Ένα από τα δύσκολα μέρη ήταν η σωστή διαχείριση της σύνδεσης με τον διακομιστή Redis. Σε περίπτωση διακοπής λειτουργίας του διακομιστή για οποιονδήποτε λόγο, η εφαρμογή θα πρέπει να συνεχίσει να λειτουργεί σωστά. Όταν το Redis επανέλθει ξανά στο διαδίκτυο, η εφαρμογή θα πρέπει να αρχίσει να το χρησιμοποιεί ξανά και να ανταλλάσσει ξανά μηνύματα με άλλους κόμβους. Για να το επιτύχω αυτό, χρησιμοποίησα το StackExchange.Redis βιβλιοθήκη και η προκύπτουσα λογική διαχείρισης σύνδεσης υλοποιήθηκε ως εξής:

class HybridCacheService : ... { ... public void Initialize() { try { Multiplexer = ConnectionMultiplexer.Connect(_configService.Caching.BackendServerAddress); ... Multiplexer.ConnectionFailed += (sender, args) => UpdateConnectedState(); Multiplexer.ConnectionRestored += (sender, args) => UpdateConnectedState(); ... } catch (Exception ex) { ... } } private void UpdateConnectedState() { if (Multiplexer.IsConnected && _currentCacheService is NoCacheServiceStub) { _inProcCacheInvalidator.Purge(); _currentCacheService = _inProcCacheService; _logger.Debug('Connection to remote Redis server restored, switched to in-proc mode.'); } else if (!Multiplexer.IsConnected && _currentCacheService is InProcCacheService) { _currentCacheService = _noCacheStub; _logger.Debug('Connection to remote Redis server lost, switched to no-cache mode.'); } } }

Εδώ, ConnectionMultiplexer είναι ένας τύπος από τη βιβλιοθήκη StackExchange.Redis, η οποία είναι υπεύθυνη για διαφανή εργασία με το υποκείμενο Redis. Το σημαντικό μέρος εδώ είναι ότι, όταν ένας συγκεκριμένος κόμβος χάσει τη σύνδεση με το Redis, επιστρέφει σε λειτουργία προσωρινής αποθήκευσης για να βεβαιωθείτε ότι κανένα αίτημα δεν θα λαμβάνει παλιά δεδομένα. Μετά την αποκατάσταση της σύνδεσης, ο κόμβος αρχίζει να χρησιμοποιεί ξανά την προσωρινή μνήμη της μνήμης.

Ακολουθούν παραδείγματα ενεργειών χωρίς τη χρήση της υπηρεσίας cache (SomeActionWithoutCaching) και μιας πανομοιότυπης λειτουργίας που τη χρησιμοποιεί (SomeActionUsingCache):

class SomeController : Controller { public ISomeService SomeService { get; set; } public ICacheService CacheService { get; set; } ... public ActionResult SomeActionWithoutCaching() { return View( SomeService.GetModelData() ); } ... public ActionResult SomeActionUsingCache() { return View( CacheService.Get( /* Cache key creation omitted */, () => SomeService.GetModelData() ); ); } }

Ένα απόσπασμα κώδικα από ένα ISomeService η εφαρμογή θα μπορούσε να μοιάζει με αυτό:

class DefaultSomeService : ISomeService { public ICacheInvalidator _cacheInvalidator; ... public SomeModel GetModelData() { return /* Do something to get model data. */; } ... public void SetModelData(SomeModel model) { /* Do something to set model data. */ _cacheInvalidator.Drop(/* Cache key creation omitted */); } }

Συγκριτική αξιολόγηση και αποτελέσματα

Αφού ο κώδικας ASP.NET αποθηκεύτηκε προσωρινά, ήρθε η ώρα να τον χρησιμοποιήσετε στην υπάρχουσα λογική της εφαρμογής ιστού και η συγκριτική αξιολόγηση μπορεί να είναι βολική για να αποφασίσετε πού να κάνετε τις περισσότερες προσπάθειες επανεγγραφής του κώδικα για να χρησιμοποιήσετε την προσωρινή αποθήκευση. Είναι σημαντικό να επιλέξετε μερικές από τις πιο κοινές ή κρίσιμες περιπτώσεις χρήσης που πρέπει να αξιολογείτε. Μετά από αυτό, ένα εργαλείο σαν Apache jMeter θα μπορούσε να χρησιμοποιηθεί για δύο πράγματα:

• Για να συγκρίνετε αυτές τις βασικές περιπτώσεις χρήσης μέσω αιτημάτων HTTP.
• Για προσομοίωση υψηλού φορτίου για τον υπό δοκιμή κόμβο ιστού.

Για να αποκτήσετε ένα προφίλ απόδοσης, θα μπορούσε να χρησιμοποιηθεί οποιοδήποτε προφίλ που είναι ικανό να συνδεθεί με τη διαδικασία εργαζομένων IIS. Στην περίπτωσή μου, χρησιμοποίησα Απόδοση JetBrains dotTrace . Μετά από αρκετό χρόνο που αφιερώθηκε στον πειραματισμό για τον προσδιορισμό των σωστών παραμέτρων jMeter (όπως ταυτόχρονη και μέτρηση αιτημάτων), καθίσταται δυνατή η έναρξη συλλογής στιγμιότυπων απόδοσης, τα οποία είναι πολύ χρήσιμα στον εντοπισμό των σημείων πρόσβασης και των σημείων συμφόρησης.

Στην περίπτωσή μου, ορισμένες περιπτώσεις χρήσης έδειξαν ότι περίπου 15% -45% συνολικός χρόνος εκτέλεσης κώδικα ξοδεύτηκε στη βάση δεδομένων με τις προφανείς δυσχέρειες. Μετά την εφαρμογή της προσωρινής αποθήκευσης, η απόδοση σχεδόν διπλασιάστηκε (δηλαδή, ήταν διπλάσια γρηγορότερη) για τα περισσότερα από αυτά.

Σχετίζεται με: Οκτώ λόγοι για τους οποίους η Microsoft Stack εξακολουθεί να είναι μια βιώσιμη επιλογή

συμπέρασμα

Όπως μπορείτε να δείτε, η περίπτωσή μου θα μπορούσε να μοιάζει με ένα παράδειγμα αυτού που συνήθως αποκαλείται «επανεφεύρεση του τροχού»: Γιατί να ασχοληθείτε με τη δημιουργία κάτι καινούργιου, όταν υπάρχουν ήδη βέλτιστες πρακτικές που εφαρμόζονται ευρέως εκεί έξω; Απλώς ρυθμίστε ένα Memcached ή Redis και αφήστε το να πάει.

Συμφωνώ σίγουρα ότι η χρήση των βέλτιστων πρακτικών είναι συνήθως η καλύτερη επιλογή. Αλλά πριν εφαρμόσει τυφλά οποιαδήποτε βέλτιστη πρακτική, πρέπει να αναρωτηθούμε: Πόσο εφαρμόσιμη είναι αυτή η «βέλτιστη πρακτική»; Ταιριάζει καλά στην περίπτωσή μου;

μετατροπή συμβολαίου σε μόνιμη μισθοδοσία

Ο τρόπος που το βλέπω, οι σωστές επιλογές και η ανάλυση αντιστάθμισης είναι απαραίτητο όταν λάβουμε οποιαδήποτε σημαντική απόφαση, και αυτή ήταν η προσέγγιση που επέλεξα γιατί το πρόβλημα δεν ήταν τόσο εύκολο. Στην περίπτωσή μου, υπήρχαν πολλοί παράγοντες που πρέπει να ληφθούν υπόψη και δεν ήθελα να πάρω μια λύση για όλες τις περιπτώσεις, όταν δεν θα ήταν η σωστή προσέγγιση για το πρόβλημα που αντιμετωπίζουμε.

Στο τέλος, με τη σωστή προσωρινή αποθήκευση στη θέση μου, πήρα σχεδόν 50% αύξηση της απόδοσης σε σχέση με την αρχική λύση.