ΟΔΗΓΙΕΣ ΓΙΑ ΙΣΤΟΣΕΛΙΔΕΣ

Το αστείο της υπόθεσης είναι ότι αυτοί που δε ξέρουν και πολλά συνήθως το κάνουν πολύ καλύτερα από αυτού οι οποίοι είναι πιο ψαγμένοι. Είναι άπειρες οι φορές στις οποίες προγραμματιστές ή web-developers προσπαθούνε να βελτιώσουνε μέρη ενός site τα οποία δεν έχουν καμία απολύτως σημασία. Επειδή ακριβώς δεν έχουν καμία σημασία δεν βλέπουν καμία σημαντική βελτίωση και καταλήγουν να ξοδεύουν άπειρο χρόνο στο να κυνηγάνε ουσιαστικά την ουρά τους. Ευτυχώς ο Amdhal’s law τον οποίο θα παρουσιάσουμε λίγο παρακάτω μας δίνει την απάντηση σε αυτό το πρόβλημα. Πριν να περάσουμε όμως σ΄αυτό θα δούμε το ταξίδι μίας σελίδας, θα δούμε τι είναι τα bottlenecks και στο τέλος θα παρουσιάσουμε ένα εργαλείο το KCacheGrind. Πάμε λοιπόν να δούμε το ταξίδι μίας σελίδας στο internet.
Το πρώτο βήμα μίας σελίδας είναι όταν ένας χρήστης συμπληρώνει ένα URL μέσα στον browser και πατάει Enter. Το ενδιαφέρον με αυτή τη πράξη είναι ότι παρόλο που μας φαίνεται ότι φορτώνει μία σελίδα, όπως βλέπουμε εδώ πέρα πολύ περισσότερες αιτήσεις γίνονται στον server. Μία σελίδα λοιπόν αποτελείται από πολλά κομμάτια όπως η κάθε εικόνα - το κάθε css ή javascript αρχείο και για όλα αυτά πρέπει να γίνει μία ξεχωριστή αίτηση.
Για παράδειγμα αν έρθω στο Chrome και ανοίξω εδώ δεξί κλικ inspect element κι αμέσως μετά πάω εδώ που λέει network, τώρα βάζοντας για παράδειγμα saites.gr βλέπουμε πόσα πολλά στοιχεία χρειάζεται να φορτώσουνε μέχρι να φορτώσει η κεντρική σελίδα. Παρατηρούμε εδώ δεκάδες φωτογραφίες, javascript, css και ούτω καθ’εξής. Αν πάω κάτω κάτω θα δω ότι συνολικά γίνανε 164 requests και κατέβηκαν 1.78 Mb. Προφανώς αυτό το νούμερο δεν πρέπει να το πάρουμε τόσο κυριολεκτικά αλλά είναι ενδεικτικό του πόσες αιτήσεις χρειάζεται να γίνουνε για να εμφανιστεί μία τελικά σελίδα μέσα στον browser μας.
Κάθε μία απ’αυτές τις αιτήσεις χρειάζεται να περάσει μέσα από το δίκτυο. Αυτό εμπεριέχει κάποια πράγματα τα οποία λέγονται DNS servers και διάφορα άλλα πράγματα στα οποία συνήθως δεν έχουμε κανέναν απολύτως έλεγχο. Αμέσως μετά μια αίτηση έρχεται στον "καταχρηστικά λεγόμενο" application server. Σ’αυτήν την περίπτωση είναι ο Apache. Αυτός αναλαμβάνει τι τύπου είναι η αίτηση και ποιος είναι ο καλύτερος τρόπος να την εξυπηρετήσει. Αν είναι κάποιο αρχείο μπορεί να προσπαθήσει να το εξυπηρετήσει μόνος του. Παρόλα αυτά αν είναι μία σελίδα του site μας θα προσπαθήσει πιθανότατα να την εξυπηρετήσει στέλνοντάς την στην εφαρμογή. Αυτή για παράδειγμα μπορεί να είναι το Wordpress ή μία οποιαδήποτε σελίδα php ή σε οποιαδήποτε άλλη γλώσσα την έχουμε γράψει.

Τώρα, κι αυτό είναι πολύ σημαντικό, η εφαρμογή κάνει δεκάδες αιτήσεις στη βάση δεδομένων - η οποία συνήθως είναι μία MySQL. Η βάση δεδομένων είναι ας το πούμε έτσι, η "μνήμη" του προγράμματος. Κάθε φορά που χρειάζεται λοιπόν η εφαρμογή να θυμηθεί για παράδειγμα πόσα posts υπάρχουν στο blog ή ποιο είναι το κείμενο ή ποια είναι τα στοιχεία του τρέχοντος χρήστη, θα κάνει μία ερώτηση στην βάση δεδομένων και θα πάρει την απάντηση.Με το που θα ολοκληρωθεί η δημιουργία μίας σελίδας από την php, αυτή περνάει στον Apache. Αυτός με τη σειρά του την ξαναστέλνει στο δίκτυο και στο τέλος πηγαίνει στον browser μας. Ο browser με τη σειρά του δείχνει τον κώδικα της σελίδας, όπως επίσης και τον εκτελεί για παράδειγμα όποιον κώδικα Javascsript μπορεί να υπάρχει μέσα στη σελίδα. Παρατηρούμε λοιπόν ότι υπάρχει μία ακολουθία βημάτων η οποία γίνεται από διαφορετικά σημεία - το ένα γίνεται στον browser - το άλλο στο δίκτυο - το άλλο στον application server – εφαρμογή ή στη βάση δεδομένων.

Σ’αυτή τη διαδικασία εμφανίζονται τα λεγόμενα bottlenecks. Αν φανταστούμε ότι για παράδειγμα ο πάτος σε όλες αυτές τις περιπτώσεις είναι κενός, τότε το νερό το οποίο μπορεί να περάσει από ένα μπουκάλι αν το ρίχνουμε νερό από πάνω και το βγάζουμε από κάτω πάντα περιορίζεται από το bottleneck. Δεν έχει σημασία αν το bottleneck είναι στην αρχή, στην μέση ή στο τέλος. Επίσης δεν έχει σημασία αν διευρύνουμε πάρα πολύ κάποιο σημείο του μπουκαλιού αν αφήσουμε το bottleneck το ίδιο. Το bottleneck είναι αυτό το οποίο μας καθορίζει τη μέγιστη ροή που μπορούμε να έχουμε μέσα από ένα μπουκάλι.
Θα μπορούσαμε να υποθέσουμε ότι το bottleneck είναι για παράδειγμα στο δίκτυο. Αυτό όμως πρακτικά δε φαίνεται να συμβαίνει πλέον. Τον παλιό καλό καιρό με τις συνδέσεις PSTN πράγματι θα μπορούσε να πει κανείς ότι το bottleneck ήταν στο δίκτυο. Παρόλα αυτά οι συνδέσεις σήμερα είναι αρκετά καλύτερες και στις περισσότερες εφαρμογές το bottleneck δεν είναι εδώ. Το δεύτερο σημείο στο οποίο θα μπορούσε να είναι το bottleneck είναι στον application server για παράδειγμα. Παρόλα αυτά οι application servers είναι συνήθως αρκετά καλογραμμένοι από εκατοντάδες πάρα πολύ καλούς developers. Επίσης testάρονται από εκατοντάδες χιλιάδες χρήστες. Αυτό σημαίνει ότι το bottleneck για τις περισσότερες εφαρμογές δεν είναι εδώ.
Η αλήθεια λοιπόν είναι ότι για τις περισσότερες εφαρμογές το bottleneck είναι εδώ αλλά ακόμη περισσότερο εδώ πέρα στην περιοχή της βάσης δεδομένων. Φυσικά αυτό αφορά τον μέσο όρο - για παράδειγμα αν είναι μία εφαρμογή η οποία είναι 99% JavaScript μπορεί να καταλήγει το bottleneck να είναι μέσα στον browser. Παρόλα αυτά οι περισσότερες εφαρμογές ακριβώς εδώ είναι που έχουν το μεγαλύτερο πρόβλημα.
Και κάπως έτσι περνάμε στον Amdhal’s law. Οι περισσότεροί μας έχουμε κάποια αλλεργία στα μαθηματικά αλλά παρόλα αυτά, αυτό το οποίο λέει αυτός ο νόμος είναι κάτι το πολύ απλό. Έστω ότι καθόμαστε μία ώρα και βελτιώνουμε - κάνουμε δηλαδή πάρα πολύ πιο γρήγορο ένα κομμάτι τις παραπάνω διαδικασίας. Έστω για παράδειγμα ότι καταφέρνουμε να το κάνουμε τρείς φορές πιο γρήγορο. Ποια θα είναι η βελτίωση στο σύστημά μας;
Η απάντηση είναι ότι εξαρτάται από το πόσο σημαντικό είναι αυτό το σύστημα το οποίο βελτιώνουμε. Αν για παράδειγμα καταφέρουμε να κάνουμε μία 3x επιτάχυνση σε ολόκληρη τη διαδικασία αυτό σημαίνει 300% επιτάχυνση, 3x δηλαδή σε όλο το σύστημα. Αν παρόλα αυτά καταφέρουμε να βελτιώσουμε 3x ένα πράγμα το οποίο παίρνει μόλις το 60% του χρόνου ολόκληρου του συστήματος, τότε η συνολική επιτάχυνση όπου έχουμε επιτύχει είναι μόλις 82%. Καμία σχέση δηλαδή με το 3x το οποίο βλέπαμε προηγουμένως. Αν καταλήξουμε να βελτιώνουμε 3x ένα κομμάτι το οποίο είναι μόλις 2% του συστήματός μας, όπως βλέπουμε ου ουσιαστικά οι απολαβές μας σε επίπεδο συστήματος είναι μηδαμινές. Πρακτικά όμως τι σημαίνει αυτό για ένα site όπως για παράδειγμα το δικό μας;