Βελτιστοποίηση Linux Apache

Τεχνικές και μόνο Συζητήσεις για WEB hosting servers, Mail servers, DNS servers. Όχι αναζήτηση υπηρεσιών εδώ!

Συντονιστές: WebDev Moderators, Super-Moderators

Απάντηση
Άβαταρ μέλους
giannis17
Honorary Member
Δημοσιεύσεις: 1215
Εγγραφή: 06 Ιαν 2005 19:50
Τοποθεσία: Παγκράτι - Αθήνα
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από giannis17 » 03 Σεπ 2014 20:26

Έχω ένα VPS με CentOS 6.5 x64, 4 Cores και 2GB RAM στο οποίο τρέχω σχετικά τα πάντα (Bind/Apache/MySQL/PostFix+Dovecot/FTP/SSH/Webmin+Virtualmin).

Η κίνηση όλων όσων hostάρω είναι σχετικά μικρή (το πολύ 1500 μοναδικοί επισκέπτες /μέρα συνολικά) οπότε συνήθως χρησιμοποιεί περίπου 1,1-1,2GB RAM και ~200ΜΒ SWAP.

Τα site που hostάρω (26 στο σύνολο) είναι 3 κατηγοριών: Joomla/Wordpress/Custom και με εξαίρεση ένα Wordpress και ένα Custom που είναι e-shop όλα τα υπόλοιπα είναι πολύ ελαφριά.

Κατ' αρχάς δεν είναι όλα στο ίδιο hosting plan. MySQL και email δίνω μόνο σε όποιο χρειάζεται. Έχω ρυθμίσει όλα τα ελαφριά custom να παίζουν με mod_php και τα υπόλοιπα με FastCGI. Επίσης έχω ενεργοποιήσει σε όλα τα Wordpress και Joomla CDN για τα static αρχεία και memcache ενώ παράλληλα γίνεται header caching και συμπίεση DEFLATE σε όλα και από τον apache.

Τα config αρχεία είναι όλα στις default τιμές εκτός του apache που έχω αλλάξει τα παρακάτω...συν μερικά modules που έχω απενεργοποιήσει:

Κώδικας: Επιλογή όλων

KeepAlive off

<IfModule prefork.c>
StartServers       3
MinSpareServers    3
MaxSpareServers   10
ServerLimit      100
MaxClients       30
MaxRequestsPerChild  10000
</IfModule>
Παρατηρώ μια καθυστέρηση στο άνοιγμα των ιστοσελίδων και συγκεκριμένα αργεί να κάνει το connect σε αρκετά request (συνολικά το connect time φτάνει το 60-70% του συνολικού χρόνου). Μιας και δεν είμαι ειδήμων και ειλικρινά οι απόψεις διίστανται σε όποιο σχετικό documentation και forum έχω διαβάσει, θα ήθελα τα φώτα σας ποιο θα ήταν το ιδανικό config για την περίπτωση μου.

Υ.Γ. Το παραπάνω config το έχω εδώ και ένα χρόνο πριν ακόμα κάνω upgrade στο VPS (πριν ήταν 3 cores/1GB RAM) αλλά είχα μόλις 11 site και χωρίς τα 2 βαριά που ανέφερα. Είδα διαφορά με το upgrade αλλά όχι αυτή που περίμενα.
"There is only one problem with common sense; it’s not very common."
&#8211; Milt Bryce

nbc
Honorary Member
Δημοσιεύσεις: 526
Εγγραφή: 05 Σεπ 2009 20:12
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από nbc » 04 Σεπ 2014 11:08

Δεν μας δίνεις URL, οπότε η συζήτηση είναι θεωρητική.

Προσωπικά, εργαλεία τύπου YSlow, PageSpeed, κλπ, δε μου λένε και πολλά. Αυτό που μου λέει σχεδόν τα πάντα είναι το waterfall.

Τρέχοντάς το στο pcware.gr, για παράδειγμα, διαπίστωσα τα εξής, εντός ολίγων δευτερολέπτων.

1) Ο server σου είναι γενικά καλός, με την έννοια ότι έχει sub 50ms connection times και πολύ λίγο waiting.
2) Τα requests στη συγκεκριμένη σελίδα είναι πολλά (94), πρέπει (και μπορούν) να μειωθούν.
3) Ζητάς fonts που είναι στο twilight zone
4) Έχεις ένα iphonec.png που είναι 700KB (!) και μπορεί πανεύκολα να μειωθεί στα ~100KB, χωρίς απώλεια ποιότητας. Μόνο από αυτό, μπορείς να γλυτώσεις 1 δευτερόλεπτο.

Αυτό που είναι εμφανές είναι η επιβάρυνση του να μην επιτρέπεις persistent connections. Αν υποθέσουμε ότι ο X browser ανοίγει 6 sockets τη φορά (κάθε browser έχει το δικό του limit), τότε για τα 94 requests θα χρειαστούν 16 round-trips. Συν του ότι, αν το connection time σου είναι ~50ms, τότε θα υποστείς 94x50ms.

Στην άλλη περίπτωση, αν επέτρεπες πχ 15 persistent connections, τότε ο ίδιος browser θα καθάριζε σε μία πάσα (6x15 = 90).

Συνεπώς, στη θεωρητική αυτή κουβέντα μας, εγώ θα έκανα τα εξής εύκολα:

1) Μείωση του png στα 100KB
2) Keep-Alive

και σε 2η μοίρα, αν έχεις όρεξη, δες τα fonts και μείωσε τα requests.

Τρέξε waterfall before και after και εκτίμησε τη διαφορά αναλόγως.
Συνημμένα
waterfall.gif
tinypng.gif

Άβαταρ μέλους
giannis17
Honorary Member
Δημοσιεύσεις: 1215
Εγγραφή: 06 Ιαν 2005 19:50
Τοποθεσία: Παγκράτι - Αθήνα
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από giannis17 » 04 Σεπ 2014 11:18

Με βρήκες άτιμε χαχα...ναι ξέρω πως σε αρκετές ιστοσελίδες μου μπορώ να μειώσω τόσο το μέγεθος όσο και το request pool απλά σε πρώτη φάση με ενδιαφέρει να βελτιστοποιήσω τις ρυθμίσεις του Apache. Στο prefork μήπως έπρεπε να του δίνω πιο πολλά instances ας πούμε, και μου λες να ανοίξω το Keepalive, με τι timeout? 2s? 3s?
"There is only one problem with common sense; it’s not very common."
&#8211; Milt Bryce

nbc
Honorary Member
Δημοσιεύσεις: 526
Εγγραφή: 05 Σεπ 2009 20:12
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από nbc » 04 Σεπ 2014 11:46

Νομίζω τα 3s είναι λίγα. Αφού δεν έχεις - όπως λες - σημαντική κίνηση, και είσαι σε VPS, δε σε πειράζουν 1-2 πιθανά idle threads, now and then. Βάλτο 15+. Αντιθέτως, κινδυνεύεις ο browser να φάει πόρτα, γιατί κάποιο script ήταν βιαστικό και δεν περίμενε το document ready.

Μεγαλύτερη σημασία έχει το πόσα requests (MaxKeepAliveRequests) θα επιτρέπεις ανά σύνδεση.

Το θέμα, όμως, στην περίπτωση σου είναι το mixed model (mod_php, cgi). Δεν καταλαβαίνω το λόγο, και δεν ξέρω πως θα κουρδίσεις ένα τέτοιο σύστημα. Και σα να μην έφτανε αυτό, χτυπάς και ένα prefork να δέσει το γλυκό! Τι το θες το mod_php με prefork;

Τέλος πάντων, έχω μηδενική εμπειρία σε τέτοιο setup, οπότε ...ο επόμενος :D

Άβαταρ μέλους
giannis17
Honorary Member
Δημοσιεύσεις: 1215
Εγγραφή: 06 Ιαν 2005 19:50
Τοποθεσία: Παγκράτι - Αθήνα
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από giannis17 » 04 Σεπ 2014 12:52

Το mod_php το χρησιμοποιώ στα "στατικά" site που ουσιαστικά δεν έχουν php scripts, ή έχουν μόνο για να παίρνουν τιμές από xml και να αλλάζουν δυναμικά πολύ συγκεκριμένα πράγματα. Οπότε εκεί δεν χρειάζεται να φορτώνει όλη τη PHP σε ξεχωριστό proccess, γλυτώνω resources και κατέληξα σε αυτό το setup τότε μετά από δοκιμές.

Anyway θα δοκιμάσω να παίξω πάλι με το config το βράδυ και θα postάρω αύριο αποτελέσματα.

Thanks!
"There is only one problem with common sense; it’s not very common."
&#8211; Milt Bryce

nbc
Honorary Member
Δημοσιεύσεις: 526
Εγγραφή: 05 Σεπ 2009 20:12
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από nbc » 04 Σεπ 2014 13:42

Η ερώτηση μου ήταν ρητορική. Σαφέστατα και η αρχιτεκτονική ISAPI υπερτερεί έναντι της CGI. Βασικά, ο μόνος λόγος που υπάρχει ακόμη αυτός ο δεινόσαυρος (υποθέτω) είναι τα shared accounts. To CGI θα έπρεπε να έχει πεθάνει προ πολλού.

Εσύ, όμως, έχεις ένα setup φιλοσοφίας single-threaded / multi-process. Αυτό προκύπτει από το "KeepAlive off ", το cgi και φυσικά το (γιατί άραγε) prefork. Αυτό το setup εγγυάται compatibility με τα πάντα, κόβει όμως τα φτερά του performance, που είναι και το θέμα μας.

To mod_php, τα persistent connections και η multi-core CPU που έχεις είναι φιλοσοφίας multi-threaded / single-process. Δηλαδή performance-oriented αρχιτεκτονική. Ακριβώς αντίθετη με την υπάρχουσα.

Γι αυτό σου έγραψα ότι δεν έχω ιδέα πως τιουνάρεται ένα τέτοιο σύστημα.

Άβαταρ μέλους
giannis17
Honorary Member
Δημοσιεύσεις: 1215
Εγγραφή: 06 Ιαν 2005 19:50
Τοποθεσία: Παγκράτι - Αθήνα
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από giannis17 » 05 Σεπ 2014 00:16

Άνοιξα το KeepAlive με 200 requests και 15s timeout και είδα αρκετή διαφορά, βασικά τα βαριά site που έχουν πάνω από 60 requests πλέον ανοίγουν ακριβώς στο μισό χρόνο.

Επίσης βρήκα μια @@ριά του Wordpress το οποίο πάει και προσθέτει το version των js/css στα source links με αποτέλεσμα να μην γίνονται cache!!

Το διόρθωσα προσθέτοντας την παρακάτω function στο functions.php του εκάστοτε θέματος:

Κώδικας: Επιλογή όλων

function remove_cssjs_ver&#40; $src &#41; &#123;
    if&#40; strpos&#40; $src, '?ver=' &#41; &#41;
        $src = remove_query_arg&#40; 'ver', $src &#41;;
    return $src;
&#125;
add_filter&#40; 'style_loader_src', 'remove_cssjs_ver', 10, 2 &#41;;
add_filter&#40; 'script_loader_src', 'remove_cssjs_ver', 10, 2 &#41;;
Τώρα μένει να δούμε πως θα ανταποκριθεί το VPS τις επόμενες μέρες από άποψη πόρων.

Υ.Γ. το tinypng τα σπασε! δεν ήξερα πως έπαιζε τέτοια συμπίεση. Θα κάνω ένα check πόσα png γενικά hostάρω και άμα είναι αρκετά αγοράζω και το photoshop plugin! Ευχαριστώ για όλα!
"There is only one problem with common sense; it’s not very common."
&#8211; Milt Bryce

nbc
Honorary Member
Δημοσιεύσεις: 526
Εγγραφή: 05 Σεπ 2009 20:12
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από nbc » 05 Σεπ 2014 08:50

Το versioning χρειάζεται. Αν αλλάξεις κάτι στο css/js θα θέλεις ο κόσμος να δει αυτήν την αλλαγή άμεσα και όχι σε 1 χρόνο!

Το query δεν εμποδίζει το caching, δεν ξέρω πως κατέληξες σε αυτό το συμπέρασμα...

Άβαταρ μέλους
giannis17
Honorary Member
Δημοσιεύσεις: 1215
Εγγραφή: 06 Ιαν 2005 19:50
Τοποθεσία: Παγκράτι - Αθήνα
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από giannis17 » 05 Σεπ 2014 11:00

Όσο είσαι σε development φάση ναι βοηθάει αλλά για μετά όχι.

Κατέληξα σε αυτό το συμπέρασμα γιατί στο waterfall έβλεπα πως συνέχεια τα κατέβαζε αντί να τα τραβάει από την cache (του browser την cache). Οπότε και το απενεργοποίησα και τώρα δουλεύει όπως θέλω.
"There is only one problem with common sense; it’s not very common."
&#8211; Milt Bryce

gvre
Δημοσιεύσεις: 992
Εγγραφή: 14 Οκτ 2010 11:34
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Βελτιστοποίηση Linux Apache

Δημοσίευση από gvre » 05 Σεπ 2014 12:30

giannis17 έγραψε:Όσο είσαι σε development φάση ναι βοηθάει αλλά για μετά όχι.
Το query είναι σημαντικό και στο production. Εκεί που δε χρειάζεται είναι στα libs (πχ. jquery) που είμαστε σίγουροι ότι δεν θα αλλάξουν.
giannis17 έγραψε:Κατέληξα σε αυτό το συμπέρασμα γιατί στο waterfall έβλεπα πως συνέχεια τα κατέβαζε αντί να τα τραβάει από την cache (του browser την cache). Οπότε και το απενεργοποίησα και τώρα δουλεύει όπως θέλω.
Όπως έγραψε και ο nbc, το query δεν εμποδίζει το caching στον browser. Μπορείς να το διαπιστώσεις κι εσύ μέσα από τα dev tools του browser σου.

Απάντηση

Επιστροφή στο “Apache, IIS, DNS Servers”

Μέλη σε σύνδεση

Μέλη σε αυτήν τη Δ. Συζήτηση: Δεν υπάρχουν εγγεγραμμένα μέλη και 0 επισκέπτες