Jak przetrwać wykop efekt?

Tagi: hosting, optymalizacja, webmaster

Wykop.pl będący polskim odpowiednikiem anglojęzycznego serwisu digg.com, stał się jednym z najpopularniejszych serwisów Web 2.0 w Polsce. Gromadzi on linki dodawane przez swoich użytkowników, umożliwiając im głosowanie na nie. Dodane witryny, które przekroczą pewien próg punktowy, dostają się na stronę główną serwisu – tak w ogromnym uproszczeniu działa Wykop.pl.

Celem właścicieli stron internetowych jest zwykle maksymalizacja ilości unikalnych użytkowników odwiedzających ich serwis. Cel ten ułatwia właśnie dostanie się na stronę główną wykopu.

Wielkie rozczarowanie

W momencie gdy Twój serwis zdobędzie ilość głosów która zakwalifikuje go do publikacji na stronie głównej wykop.pl, Twoje statystyki odnotują ogromny skok oglądalności. Jest to dokładnie to, co zapewne chciałeś osiągnąć. Niestety bardzo szybko możesz doświadczyć zjawiska zwanego “Wykop efekt”.

Czym jest “Wykop efekt”?

Najprościej mówiąc, jest to zablokowanie dostępu do strony internetowej na skutek zbyt dużej ilości odwiedzających ją osób. W przypadku wejść z wykopu, Twój serwis może spodziewać się od kilku do kilkudziesięciu tysięcy wejść dziennie, co może spowodować:

• przeciążenie bazy danych MySQL
• zużycie transferu na hostingu współdzielonym
• przekroczenie limitu obciążenia procesora na wirtualnych hostingach

Na temat serwerów wirtualnych możesz poczytać więcej w innym wpisie.

Najczęstszym następstwem wykopowego efektu jest wyłączenie hostowanej strony przez administratora hostingu, lub pojawienie się komunikatu o przekroczonej ilości odwołań do bazy danych, lub o przekroczonym transferze konta.

Co muszę zoptymalizować?

Postaram się wypunktować Ci najważniejsze elementy na które musisz zwrócić uwagę projektując serwis dla dużego ruchu przychodzącego.

Musisz zadbać o:

• optymalne zapytania mysql
• możliwie krótki czas wykonywania skryptów PHP
• zminimalizowanie ilości zapytań do serwera
• optymalizacja rozmiarów elementów na stronie WWW

Zacznijmy więc optymalizację

Baza MySQL – podstawy optymalizacji

Najczęściej spotykanym błędem spotykanym w rozwiązaniach autorskich (choć nie tylko) są nieoptymalne zapytania wysyłane do bazy.

Oto lista zasad, których powinieneś się trzymać:

• Twórz indeksy na polach po których wyszukujesz lub grupujesz dane (nie na tych, które wyciągasz – to nic nie daje!)
• Stosuj poprawne indeksy – jeśli wartość jest unikalna, użyj indeksu UNIQUE
• Pamiętaj, że zakładanie indeksów na pola, spowalnia proces dodawania nowych rekordów. Setka indeksów w tabeli z której wyciągasz dane jedynie po ID, spowoduje więcej złego niż dobrego.
• Przechowując dane o stałych rozmiarach, takie jak np. hash md5, stosuj pola o ustalonej na sztywno długości. Czyli dla md5 będzie to char(32) a nie varchar(32)
• Trzymaj w cache zapytania wykonujące się przez ponad sekundę, oraz te, które nie wymagają stale aktualizowanych danych. W praktyce jednak… wrzucaj do cache co się da
• Staraj się unikać losowania danych z dużych tabel za pomocą funkcji rand(). O wiele lepiej jest pobrać ilość wszystkich rekordów, wylosować liczbę z przedziału 1-N w PHP i pobrać ten konkretny rekord.
• Jeśli to tylko możliwe, wyciągaj dane z bazy na podstawie pól numerycznych, a nie tekstowych.

Z głową w chmurach

Analizując kilka serwisów internetowych moich znajomych, doszedłem do wniosku, że około 60% całej “wagi” tych serwisów znajduje się w sekcji HEAD. Są tam najczęściej umieszczone zewnętrzne skrypty języka JavaScript i arkusze CSS. Całość ma przeważnie kilkadziesiąt kilobajtów. Nie jest to niby dużo, jednak zapoznaj się z artykułem na temat serwerów wirtualnych, w którym przedstawiam jak te kilkadziesiąt kilobajtów może wpłynąć na cały serwis internetowy.

Zauważyłem, że niemal każdy z analizowanych przeze mnie serwisów korzystał z biblioteki jQuery, a kilka z nich także z pluginu jQueryUI. Obie te biblioteki razem zajmują przeważnie od kilkudziesięciu do nawet 200 kilobajtów. Dlaczego więc nie poprosić kogoś, aby hostował je za nas?

Tym dobrym “kimś” może być “wujek Google”. Możliwe, że niewiele osób o tym wie, ale Google udostępnia na swoim CDN (Content Distribution Network) zarówno biblioteki jQuery i jQueryUI, jak i wszystkie domyślne 24 skórki dla tej drugiej biblioteki (zarówno CSS jak i grafiki).

Chcąc korzystać z tych bibliotek w wersji hostowanej przez chmury  Googla, wystarczy zaincludować następujące dwa pliki JS (Google hostuje także inne, nowsze wersje):

http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js

http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js

Link do domyślnego stylu CSS dla jQuery UI:

http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/start/jquery-ui.css

Pytaj wolniej, bo nie odpowiem…

Każdy serwer internetowy ma ograniczoną wytrzymałość jeśli chodzi o ilość wysyłanych do niego zapytań o pliki. Jest to spowodowane zarówno ograniczeniami pamięciowymi, jak i czasem procesora potrzebnym do obsłużenia tych zapytań.

Wyobraź sobie, że Twoja strona po dostaniu się na Wykop.pl przyjmuje średnio 100 osób na minutę, czyli prawie dwie osoby na sekundę.

Nie oznacza to, że Twój serwer w ciągu sekundy obsługuje dwa zapytania. Musisz pamiętać, że serwis WWW składa się nie tylko z kodu HTML, ale także grafik, plików CSS, JS itp.

Spotkałem się z serwisami, które podczas ładowania pojedynczej podstrony, odwoływały się do ponad 50 plików zewnętrznych. Załóżmy jednak, że taką przyzwoitą normą jest 20 odwołań. Oznacza to, że Twoich dwóch czytelników stara się wykonać około 40 zapytań (pomińmy istnienie limitu requestów zawartego w przeglądarce) do serwera WWW na sekundę. To naprawdę dużo.

Aby zmniejszyć ilość zapytań do Twojego serwera, zastosuj następujące porady:

• Korzystaj z publicznie hostowanych bibliotek JavaScript (Google CDN jest tutaj dobrym pomysłem)
• Zacznij wykorzystywać CSS Sprites w swoim serwisie, czyli zamiast setki małych obrazków, zastosuj jeden ogromny, z którego przy użyciu arkuszy CSS będziesz wycinał potrzebne Ci fragmenty.
• Scal kilka plików CSS w jeden. Wiem, że zapewne podzieliłeś je na kawałki ze względu na porządek w kodzie, jednak includowanie kilku lub kilkunastu plików CSS nie jest dobrym pomysłem. Możesz je scalić w jeden kawałek nawet za pomocą prostego skryptu PHP – tak aby na dysku nadal był porządek.
• Podobnie jak pliki CSS, tak i JavaScript scal w jeden wielki plik. Ilość odwołań znacznie zmaleje.

Z własnego doświadczenia wiem, że najlepsze efekty osiąga się, stosując poradę związaną z zastosowaniem CSS Sprites. Jeśli sam nie umiesz lub nie chcesz przygotowywać odpowiednich grafik do tego celu, może to zrobić za Ciebie serwis spriteme.org.

Dobry kolega przejmie część uderzenia na siebie…

W Internecie istnieje bardzo wiele darmowych hostingów, oferujących potencjalnie nieograniczony transfer. Możesz wykorzystać ten fakt do hostowania tam np. zdjęć wrzucanych na Twojego bloga. W ten sposób pewną część mocy “uderzenia ludzi z wykopu” przejmie inny serwer, a Ty oberwiesz z połową mocy

W praktyce jednak pamiętaj, że Twoje darmowe konto może zostać po prostu zablokowane za przeciążanie systemu. Z tego powodu ja do tego typu działań wykorzystuję Dreamhosta, który nie limituje pojemności konta jak i transferu. Muszę powiedzieć, że nie jest to kolejna ściema typu “nieograniczony transfer pod warunkiem, że nie przekroczysz X giga”. Miesięcznie zużywam tam setki gigabajtów transferu i jak dotąd wszystko działa idealnie.

Zapamiętaj, aby nigdy nie stosować darmowych hostingów zdjęć do tego typu “outsourcowania” zawartości. Mają one bardzo niewielkie limity transferu przypadające na zdjęcie, więc szybko zobaczysz komunikat o przekroczeniu tego limitu.

Co jest lepsze od własnej domeny? kilka domen!

Przeglądarki internetowe mają wbudowany w sobie mechanizm limitujący ilość jednoczesnych zapytań jakie mogą wysłać do serwera. Często jest to ilość ustawiona na 8 lub 16 jednoczesnych połączeń. Oznacza to, że chcąc pobrać stronę mającą np. 30 obrazów, przeglądarka musi to zrobić w dwóch lub czterech “paczkach”. Pobierając pierwszą paczkę danych (np. 8 zapytań), pozostałe pliki czekają w kolejce.

W praktyce łącze użytkownika nie jest zwykle zapchane aż tak bardzo, aby nie był on w stanie przyjąć jednocześnie np. 20 połączeń. Można naturalnie zmienić konfigurację przeglądarki, aby zaciągała więcej danych za jednym razem, ale przecież nie zrobisz tego u swojego czytelnika

Należy się zastanowić, skąd przeglądarka wie, że pobiera dane z jednego serwera. Oczywiście rozpoznaje to na podstawie domeny. Możemy więc powiedzieć, że tak naprawdę, limit requestów przypada tutaj na domenę, a nie na faktyczny serwer.

Idąc dalej tym tokiem rozumowania, dojdziemy do wniosku, że chcąc zwiększyć ilość jednocześnie pobieranych przez użytkownika plików, wystarczy zaciągać te dane z kilku różnych domen.

Oczywiście nie będę Cię teraz namawiał do kupienia np. 10 domen, które po roku będziesz musiał przedłużyć. W tym przypadku w pełni wystarczy Ci jedna domena z kilkoma subdomenami, które przeglądarka także traktuje jako oddzielne serwery.

Zwróć uwagę na to, jak ten problem rozwiązałem na UW-Team.org. Część danych ładuję bezpośrednio z domeny serwisu, a część z subdomeny cdn.uwteam.org. Zastosowanie dwóch domen sprawia, że użytkownik pobiera jednocześnie nie 8 czy 16 plików, lecz 16 lub 32, co potencjalnie powinno skrócić czas ładowania strony o połowę.

Napisałem “potencjalnie”, ponieważ w praktyce tracony jest jeszcze czas na obsługę tych zapytań, oraz na znalezienie tej dodatkowej domeny (resolving DNS). Pomimo marnowania czasu na szukanie dodatkowej domeny, warto wiedzieć, że domena raz znaleziona jest już w przetrzymywana w cache przeglądarki, więc każda kolejna podstrona odwołująca się do niej, działać już będzie znacznie szybciej.

Wordpressie  – oszczędź mój serwer!

Obecnie najpopularniejszym skryptem blogowym jest Wordpress. Niestety nie jest to skrypt optymalny i przystosowany do dużej oglądalności serwisu.

Średnio wywołanie jednej podstrony bloga działającego pod kontrolą systemu Wordpress powoduje wykonanie od kilku do kilkunastu zapytań do bazy danych – wszystko zależy od ilości zainstalowanych pluginów.

Taka ilość zapytań przy dostatecznie dużej ilości unikalnych odwiedzin w serwisie, może skutecznie zapchać każdy serwer.

Na szczęście w przypadku tego skryptu, nie będziesz musiał ani optymalizować bazy danych, ani też zapytań SQL. Wystarczy, że  doinstalujesz specjalny plugin, który zajmie się za Ciebie cachowaniem podstron Twojego bloga.

Pluginem takim jest wp-supercache. jego działanie nie polega na przetrzymywaniu w pamięci podręcznej zapytań SQL, lecz na zapisywaniu kompletnych, statycznych stron do plików na dysku serwera. Oznacza to, że plugin załatwia sprawę optymalizacji serwisu niezwykle kompleksowo. Nie tylko odciąża bazę danych, ale też daje odpocząć interpreterowi PHP, serwując statyczne pliki HTML dla użytkownika.

Podsumowanie

W tym wpisie celowo pominąłem optymalizację od strony serwera. Jest to spowodowane faktem, że znaczna większość czytelników tego bloga hostuje swoje serwisy na serwerach współdzielonych, bez możliwości przekonfigurowania maszyny.

Jeśli masz swoje sposoby na obronę przed wykop efektem, to podziel się proszę nimi w komentarzach do tego wpisu.