Ακολουθεί μια περίληψη των προβλημάτων κατά την υλοποίηση ενός στοιχείου υποδοχής υψηλής απόδοσης, εάν χρειάζεται να ασχοληθείτε μόνο με χιλιάδες ταυτόχρονες εφαρμογές, τότε μπορείτε να δώσετε προσοχή στη σύνταξη κώδικα, αλλά πρέπει να αντιμετωπίσετε δεκάδες χιλιάδες ή δεκάδες χιλιάδες ταυτόχρονες εφαρμογές. Η περίληψη των παρακάτω ερωτήσεων πιστεύεται ότι θα βοηθήσει πολύ στη σύνταξη αυτής της αίτησης.
SocketAsyncEventArgs
Αυτό το αντικείμενο παρέχεται μετά το .NET 2.0 sp1 και χρησιμοποιείται κυρίως για την υλοποίηση επεξεργασίας αποστολής και λήψης δεδομένων υποδοχής υψηλής απόδοσης (για μια πιο λεπτομερή εισαγωγή, μπορείτε να μεταβείτε στο MSDN). Αυτό το αντικείμενο παρέχει τρεις τρόπους για να ορίσετε τα buffer για την αποστολή και λήψη σχετικών αποστολών, SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, τα δύο πρώτα δεν μπορούν να συνυπάρχουν με το τελευταίο ( Το MSDN εξηγεί γιατί). Όταν ορίζετε ένα Buffer, είτε πρόκειται για SetBuffer(Byte(), Int32, Int32) είτε για BufferList, προσπαθήστε να το ορίσετε μόνο μία φορά ανά παρουσία SocketAsyncEventArgs καθ' όλη τη διάρκεια ζωής του προγράμματος, καθώς αυτή η ρύθμιση μπορεί να απαιτεί πολύ πόρους. Συνιστάται να ρυθμίσετε το buffer δεδομένων μέσω του SetBuffer(Byte(), Int32, Int32) κατά την κατασκευή του SocketAsyncEventArgs και, στη συνέχεια, να χρησιμοποιήσετε το SetBuffer(Int32, Int32) για να το χειριστείτε. Όταν θέλετε να ορίσετε μια BufferList, είναι καλύτερο να μην αλλάξετε <byte>την πηγή byte[] που αναφέρεται από το IList<ArraySegment>. Εάν αλλάξει, θα αναγκάσει το SocketAsyncEventArgs να επανασυνδέσει το buffer και να επηρεάσει την απόδοση.
Πισίνα SocketAsyncEventArgs
Όπως αναφέρθηκε παραπάνω, προσπαθήστε να μην αλλάξετε όσο το δυνατόν περισσότερο το buffer που αναφέρεται από το SocketAsyncEventArgs, προκειμένου να επιτευχθεί αυτός ο στόχος. Επομένως, είναι απαραίτητο να δημιουργήσετε μια ομάδα εφαρμογών SocketAsyncEventArgs και να αρχικοποιήσετε το αντικείμενο SocketAsyncEventArgs όσο το δυνατόν περισσότερο στην αρχή του προγράμματος. Εκτός από τη μείωση της δημιουργίας του SocketAsyncEventArgs, η κατασκευή πισινών μπορεί επίσης να εξοικονομήσει σημαντικά μνήμη. Ο κύριος λόγος είναι ότι δεν μπορείτε να γνωρίζετε πόσο μεγάλο είναι κάθε μήνυμα, φυσικά, μπορείτε να δώσετε στο μήνυμα ένα μέγιστο όριο πριν το σχεδιάσετε και, στη συνέχεια, να ορίσετε το buffer που αντιστοιχεί στο SocketAsyncEventArgs. Ωστόσο, αυτό είναι μεγάλη σπατάλη μνήμης, επειδή δεν έχουν όλα τα μηνύματα μέγιστο μήκος. Εκχωρήστε ένα κατάλληλο μέγεθος buffer στο SocketAsyncEventArgs, παρέχετε κλήσεις μέσω χώρων συγκέντρωσης και γράψτε ευέλικτα μηνύματα σε ένα ή περισσότερα SocketAsyncEventArgs ή αποθηκεύστε πολλά μηνύματα σε ένα SocketAsyncEventArgs για επεξεργασία.
Ουρά
Βλέπω ότι πολλές πρακτικές είναι να ανοίγετε απευθείας νήματα ή να τα ρίχνετε στη δεξαμενή νημάτων μετά τη λήψη δεδομένων, κάτι που είναι πολύ κακό γιατί δεν ελέγχει καλύτερα την εργασία των νημάτων, συμπεριλαμβανομένης της αναμονής των νημάτων. Με προσαρμοσμένα νήματα + ουρές, μπορείτε να ελέγξετε πόσα νήματα είναι υπεύθυνα για ποια εργασία και η εργασία στην ουρά θα υπάρχει μόνο στην ουρά. Δεν θα υπάρχει μεγάλος αριθμός νημάτων ή μεγάλος αριθμός γραμμών σε αναμονή, γεγονός που θα προκαλέσει απώλεια πόρων του λειτουργικού συστήματος λόγω προγραμματισμού νημάτων.
Καθυστερημένη ενοποίηση δεδομένων
Η καθυστερημένη μετάδοση δεδομένων συγχώνευσης είναι ένα μέσο για την επίλυση του προβλήματος των υπερβολικών λειτουργιών IO δικτύου, το οποίο δεν χρησιμοποιείται σε πολλά σενάρια, αλλά είναι σύνηθες σε διακομιστές παιχνιδιών. Κάποιος μου έκανε μια ερώτηση πριν, εάν υπάρχουν 400 χρήστες στη σκηνή, η αλλαγή περιβάλλοντος κάθε χρήστη θα ενημερώσει τους άλλους χρήστες. Εάν δεν χρησιμοποιηθούν τα συνδυασμένα δεδομένα, θα προκύψει μια πολύ τρομακτική λειτουργία IO δικτύου, η οποία είναι δύσκολο να μεταφερθεί από το σύστημα αριθμών λειτουργίας IO. Επομένως, είναι απαραίτητο να συγχωνεύσετε και να στείλετε δεδομένα εντός κατάλληλου διαστήματος καθυστέρησης για την τρέχουσα εφαρμογή. |