Ιστοσελίδα αργό μετά την εκκαθάριση της προσωρινής μνήμης

[tavenger5]

Έχω περάσει και να εφαρμοστούν όλα τα πιθανά τεχνάσματα βελτιστοποίηση μπορώ να βρω. Αυτό περιλαμβάνει nginx ως υποκατάστατο για apache, vbOptimize με memcached, και όλες τις κανονικές διαδικασίες βελτιστοποίησης vBulletin.

Δουλεύω με δύο servers διπλού επεξεργαστή τετραπλού πυρήνα με 12 και *** του RAM και 15k SAS δίσκους σε RAID. Έτσι, με άλλα λόγια, οι servers έχουν αρκετή δύναμη να επεξεργάζονται τα πάντα.

Η κύρια περιοχή αρχίζει να επιβραδύνει αμέσως μετά την προσωρινή μνήμη vBET καθαρίζεται κάθε 15 ημέρες. (Η βάση δεδομένων φτάνει σε λίγο πάνω από *** μετά από αυτό προθεσμίας των 15 ημερών) είναι> 500k σελίδες την ημέρα που ανιχνεύεται από μηχανές αναζήτησης.

Υπάρχει κάτι που μπορώ να κάνω στο τσίμπημα apache να διαχειρίζεται αυτές τις ερωτήσεις καλύτερα εκεί; Αυτές είναι οι τρέχουσες ρυθμίσεις μου apache:
από httpd-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
Maxclients 180
MaxRequestsPerChild 1000

Από httpd-default.conf:

Χρονικό όριο 150
Στις KeepAlive
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Το κόλπο είναι - αν δεν πραγματικά να, τότε δεν χρησιμοποιούν τελευταία στρατηγική συμψηφισμού. Ξέρω ότι υπάρχει αν - Είχατε ελέγξει τις άλλες στρατηγικές εκκαθάριση; Άλλοι δεν θα καθαρίσει όλη cache και θα λάβει περισσότερους πόρους για την εκκαθάριση από άλλη πλευρά.

Επόμενη έκδοση 3.x vBET μπορούν να σας βοηθήσουν - θα προσθέσουμε νέες προηγμένες παραμέτρους επιδόσεων για πραγματικά μεγάλες σελίδες. Ανακαλύψαμε επίσης συμφόρησης με συνδέσμους μετάφραση. Αυτή τη στιγμή έχουμε υλοποιήσει λύση για vB Friendly URLs στο vBET4.x (δεν έχει κυκλοφορήσει ακόμη) και θα προσπαθήσουμε να την εγκρίνει, επίσης, για vBSEO. Εάν επιτύχουμε, θα το μετακινήσετε και να vBET 3.x Το ζήτημα είναι ότι vBSEO ζητά συνδέσεις ένας-ένας και αυτό παράγει δεκάδες Google αιτήματα. Όπως έγραψα έχουμε ήδη θέσει σε εφαρμογή λύση για τις διευθύνσεις URL vB Frinedly - κάναμε καθυστερημένη μετάφραση. Πρόβλημα με vBSEO είναι ότι λειτουργεί έξω από VB, μετά τη μετάφραση συμβαίνει και επίσης δεν λένε δεν χρειάζεται url για να ελέγξει την ορθότητα των πραγματικών ένα
ή για να το πούμε στην παραγωγή.
Πολλές λεπτομέρειες - λίγο γνωρίζουμε το σημείο συμφόρησης που συμβαίνει μόνο όταν cache δεν έχει συμπληρωθεί και είμαστε ήδη εργάζονται για το θέμα αυτό.

Έτσι, αυτή τη στιγμή δεν μπορώ ακριβώς να σας συμβουλεύσει για να παίξει με στρατηγικές για την εκκαθάριση και άλλες παραμέτρους εκκαθάρισης. Για άλλες στρατηγικές:
- Αν η εκκαθάριση ενός πίνακα cache δεν είναι δολοφονία του διακομιστή σας, ορίστε μεγαλύτερο «Cache συμψηφισμού timelap» - ο διακομιστής σας θα πάρει μια ανάσα μεταξύ ξέφωτα
- Analise κυκλοφορίας φόρουμ σας και ελέγξτε πότε είναι λιγότερο - εκτέλεση εκκαθάρισης αλλαγή αυτή τη φορά
- Ρυθμίστε χαμηλότερα cache TTL - μικρότερα τραπέζια θα είναι ξεκάθαρη, έτσι εκκαθάριση ίδια θα λάβει λιγότερους πόρους. Άλλη πλευρά - server θα πρέπει να ρωτήσετε το Google πιο συχνά για τις μεταφράσεις.
- ΠΕΙΡΑΜΑΤΙΚΗ: «Γρήγορη τοπικές διαγραφή τους πίνακες με τη βελτιστοποίηση» που ανοικτού / Περιλαμβάνει / vbenterprisetranslator_functions.php και σχόλιο υπάρχουν 3 γραμμές κώδικα με 'ΒΕΛΤΙΣΤΟΠΟΙΗΣΗ τοπικό πίνακα». Αυτό θα κάνει πολύ γρήγορα διαγραφή χωρίς ευρετήρια αναβάθμιση. ΣΗΜΕΙΩΣΗ: ευρετήρια θα αυξηθεί, έτσι θα πρέπει να εκτελέσετε το ερώτημα αυτόματο τρόπο - δηλαδή έλεγχος μία φορά την εβδομάδα. Αν αυτό θα λειτουργήσει για σας, θα εφαρμόσει τη νέα στρατηγική, όπου δείκτες θα αναδιοργανωθούν όχι κάθε μέρα.

[tavenger5]

Ναι στην vBSEO.

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

Τα πράγματα μόνο φαίνεται να επιβραδύνει όταν υπάρχει πολλή κίνηση στην ιστοσελίδα και η μνήμη cache γίνεται ανακατασκευή. Είμαι σίγουρος ότι αυτό συμβαίνει επειδή οι Apache διαδικασίες που έκλεισε τόσο γρήγορα όσο θα ήταν κανονικά (αφού τα στοιχεία που έχει ζητηθεί από το Google).

Είναι καλό να ακούμε ότι η επόμενη έκδοση θα βελτιώσει την ταχύτητα και πάλι. Ήμουν απλά φροντίζοντας δεν υπήρχε τίποτ 'άλλο θα μπορούσα να κάνω με apache tweaking.

[vBET]

Εάν χρησιμοποιείτε την κανονική εκκαθάριση στη συνέχεια ξέχασε για συμβουλές μου. Νόμιζα ότι χρησιμοποιείτε τελευταία στρατηγική και να αφαιρέσετε όλο cache. Συγγνώμη - παρεξήγηση Ας το αφήσουμε ως έχει.

Με αυτόν τον τρόπο μπορώ να συμβουλεύσει να είναι μεγαλύτερη Cache TTL. Λιγότερο δεδομένα θα αφαιρεθούν από κάθε φορά, έτσι λιγότερα δεδομένα θα είναι να ανακτήσει.


Τι μπορείτε επίσης να κάνετε είναι να βεβαιωθείτε ότι ο διακομιστής σας δεν κρατά εξερχομένων αιτήσεων. Ανακαλύψαμε ότι ορισμένοι διακομιστές συμπεριφέρονται σαν αυτό, αν πολλές εξερχόμενες αιτήσεις πρόκειται να ίδιο διακομιστή. Επειδή 100 αιτήματα μπορεί να πάρει 1000 x περισσότερο χρόνο από 1 αίτηση (θεωρητικά θα πρέπει να λάβει 100 x περισσότερο χρόνο). Μπορεί να είναι κάποιο τείχος προστασίας, το ζήτημα της ασφάλειας διακομιστή. Φυσικά και μπορεί να είναι ότι το Google βάζει κάποια μικρή «τιμωρία» σε μια τέτοια περίπτωση. Έτσι εάν μπορείτε να βρείτε κάτι σε αυτό τον τομέα - μπορεί να βοηθήσει. Αν όχι παρακαλώ περιμένετε για βελτιώσεις