Tani Hosting z SSH – LaoHost.pl

1. Wstęp

Pewnego dnia znaleźliśmy w skrzynce kontaktowej elimu ciekawy mail. Właściciel Laohost zwrócił się do nas z prośbą o artykuł prezentujący ofertę jego hostingu. Ponieważ i tak zamierzałem coś takiego kiedyś zrobić (ocenić hostingi z jakich korzystam pod kątem współpracy z Drupalem) postanowiłem, że to dobra okazja aby napisać pierwszy artykuł z tego cyklu. Uzgodniliśmy szczegóły i zabraliśmy się do roboty.

2. Oferta

Na moment pisania recenzji Laohost oferuje standardowy hosting (również z opcją reseller), serwery vps i dedykowane oraz domeny. W ramach najtańszego nawet konta otrzymujemy dostęp SSH, 4 adresy IP na których możemy umieszczać nasze serwisy oraz przyrostowe kopie zapasowe. Nie na każdym tanim hostingu te funkcje są dostępne.

Ceny za hosting są stosunkowo niskie, na pierwszy rzut oka konto o powierzchni 2GB kosztuje bardzo podobnie jak w firmie gdzie obecnie hostuję swoje strony, czyli 59zł.

Spodobało mi się, że oferta jest zaprezentowana przejrzyście i wylicza wiele rzeczy o które w innych firmach musimy dopytywać. Podano na przykład jakie programy są obecne w konsoli dostępnej przez SSH, jakie rozszerzenia wkompilowano w PHP czy też ile dziennie wiadomości mail możemy wysłać.

Jest też coś naprawdę rzadko spotykanego – jawna informacja o ograniczeniach nałożonych na konto i możliwość obserwacji obciążenia jakie generuje nasza strona na serwerze. Szkoda, że strona z wyjaśnieniem stosowanych limitów nie precyzuje jakie konkretnie są progi w poszczególnych wymienionych kategoriach. Napisano na niej tylko, że “Limit obciążenia dotyczy średniego dziennego użycia procesora (CPU), pamięci RAM oraz liczby nieoptymalnych zapytań MySQL”, co jednak pozostawia pole do domysłów. Wykres jaki zaprezentowano nie daje pewności czy w panelu klienta będziemy widzieć które z zasobów są nadmiernie wykorzystywane (później okazało się, że jest kilka wykresów – do każdej kategorii).

Ciekawy (ale nieźle ukryty) jest też patent z możliwością samodzielnego wyboru powierzchni, transferu i limitu zasobów – możemy w ten sposób skomponować sobie konto sporo większe niż te w ofercie (np. 20GB dysku i 5% zasobów serwera). Myślę, że warto by było wyróżnić tę opcję i może dodać ją też na dole, pod przyciskami zamawiania standardowych pakietów. Ja sam ją zauważyłem po n-tym odwiedzeniu strony z ofertą.
3. Rejestracja

Okres testowy bez zobowiązań to 14 dni więc dość sporo, żeby wrzucić swoje strony i zdążyć wszystko solidnie przetestować. Zakładamy konto testowe i zaczynamy obmacywanie od… przeczytania regulaminu. Nie jest on zbyt długi i nie ma w nim zbyt wiele “wodolejstwa”, sprowadza się do konkretnych punktów, które obowiązują obie strony. Nie zauważyłem żadnych “haczyków”, może poza wspomnianym faktem, że poza wykresami wykorzystania limitów przydałoby się znać ich faktyczne wartości i parametry serwera, bo 1% zasobów jest pojęciem względnym.

Zaznaczam, że to i tak lepsza sytuacja niż całkowita dowolność interpretacji “zbyt dużego wykorzystania zasobów” przez administratora serwera, co jest często spotykanym punktem regulaminu w innych firmach.

Następnie w panelu klienta możemy zarejestrować dowolną usługę z oferty. Ciekawa jest możliwość wyboru serwera na którym utworzone zostanie konto.

4. Panel i korzystanie z konta

Autorski panel zarządzania jest czytelny a dodawanie nowych usług jest intuicyjne. Po kilku minutach od zamówienia konta zostało ono utworzone i mogłem zobaczyć jego szczegóły i opcje.

Spodobało mi się to, że w jednym miejscu, jeszcze przed zalogowaniem do Direct Admin, mam wszystkie ważne informacje – adresy IP, DNSy, linki do webmaila, phpmyadmina, panelu DA i tak dalej. Jest nawet to co budziło moje wątpliwości, czyli wykresy z obciążeniem jakie generuje moje konto w rozbiciu na procesor, mysql i ram. Słodko.

Baza wiedzy jaką dostajemy do dyspozycji jest ciekawą lekturą i zawiera nieco więcej niż standardowe artykuły o konfiguracji poczty i zakładania baz danych. Dowiemy się z niej między innymi jak namierzyć stronę generującą obciążenie na serwerze a także jak zacząć analizować nieoptymalne zapytania sql i zakładać indeksy – godne pochwały zaangażowanie w edukację klientów.

5. Instalacja Drupala

Na początku oczywiście sprawdzamy czy za pomocą wiersza poleceń dostępnego przez protokół SSH możemy skorzystać z drusha. Niestety w chwili obecnej hosting nie planuje umożliwić wykorzystania tego narzędzia. Rozumiem, że nakład pracy potrzebny do prawidłowego i bezpiecznego skonfigurowania drusha dla każdego klienta jest niewspółmierny do potencjalnych korzyści, ale mimo wszystko gorąco zachęcam do spróbowania i wpisania sobie w ofercie hasłą “Jako jedyni w Polsce mamy drusha!” :).

Po kuble zimnej wody pora się otrząsnąć, przyzwyczaić i zacząć cieszyć się z dostępu do wiersza poleceń przez SSH. Nadal niewiele firm udostępnia tę funkcję, a zapewniam, że znakomicie przyspiesza ona pracę z plikami na koncie, ułatwia eksport i import dużych baz danych, tworzenie instalacji wielowitrynowych i tak dalej.

Po utworzeniu bazy danych, pobraniu i rozpakowaniu plików Drupala 7 odpalamy instalator i wypełniamy kilka pól. Kilkadziesiąt sekund później mamy gotową stronę. Wszystkie pliki na koncie mają właściwe uprawnienia – szczerze mówiąc też nie na każdym hostingu się z tym spotkałem (częsta sytuacja to konieczność ręcznego poprawiania uprawnień do pliku konfiguracyjnego bądź katalogu na pliki).

6. Rozbudowa Drupala i wrażenia z działania strony

Nasza nowa strona już działa – wgrajmy do niej tłumaczenie i kilkanaście modułów. Pierwsza czynność jest na niektórych hostingach problematyczna z uwagi na dość długo trwający import napisów. Postanowiłem wypróbować zarówno ręcznego importu pliku .po, jak i wykorzystania modułu l10n_update. Przy okazji przetesuję instalowanie rozszerzeń przez panel administracyjny.

Nowe moduły instalują się błyskawicznie, strona za każdym razem tak samo szybko się ładuje. Import tłumaczenia z pomocą l10n_update, działa bez zarzutu. Niestety po zainstalowaniu kilku modułów i kolejnym uruchomieniu aktualizacji tłumaczeń serwer po raz pierwszy odpowiada nam błędem 500. Na plus laohost należy zaliczyć czytelny komunikat błędu, odsyłający nas do bazy wiedzy w celu sprawdzenia gdzie szukać przyczyny.

Z analizy logów wynika, że prawdopodobnie osiągnęliśmy zbyt długi czas wykonywania się skryptu podczas instalowania tłumaczeń do wielu modułów jednocześnie. No trudno, nie jest to nic nadzwyczajnego, choć w bazie wiedzy trudno znaleźć informację jak użytkownik konta może ten parametr zmienić. Ostatecznie można instalować moduły i tłumaczenia mniejszymi krokami, nie od razu kilkanaście na raz.

Przy okazji zauważam (z lekkim niepokojem), że panel klienta prezentuje dane o obciążeniu na bieżąco. To duża wygoda, możemy bowiem obserwować obciążenie jakie wprowadza nowo zainstalowany moduł czy skrypt “na żywo”.

Konfigurujemy zadania cron i rozpoczynamy “zapełnianie” strony sztuczną zawartością. Za pomocą modułu devel generujemy 5 różnych słowników, 100 terminów, 50 użytkowników i pięćset węzłów. Przy okazji sprawdzamy czy wymuszenie zadań cron z utworzeniem indeksu wyszukiwania dla 500 węzłów spowoduje podobny błąd przekroczenia czasu wykonywania się skryptu jak chwilę wcześniej. Test potwierdza, że ten problem występuje i powtarza się przy każdym dłuższym zadaniu. Tu też można zastosować mniejsze ilości indeksowanych węzłów na przebieg crona, więc tragedii nie ma.

Jednocześnie obserwujemy niepokojący ruch w wykresach obciążenia konta – zużycie CPU i nieoptymalne zapytania SQL powodują podniesienie się ogólnego wykorzystania zasobów do poziomu połowy dozwolonego limitu. No ale proces instalowania wielu modułów, tłumaczeń, generowanie treści – to dzieje się zwykle raz na jakiś czas, więc może podczas standardowej eksploatacji strony nie będzie tak źle?

W celu sprawdzenia czy poprawnie działa instalacja wielowitrynowa dodaję do konta dwie kolejne subdomeny w ramach głównej przypisanej do konta – palik.laohost.net – i instaluję kolejne dwa drupale wykorzystujące różne bazy danych ale te same pliki. Wszystko śmiga bez problemu.

7. Obciążanie konta

Po skonfigurowaniu bazy i zainstalowaniu Drupala możemy zabrać się za jakieś testy obciążeniowe.

Generujemy kolejne kilkaset węzłów, słowników, kategorii i użytkowników. Włączamy i konfigurujemy moduł statistics.  Tworzymy blok zawierający losowo wybierane węzły wraz z informacją o ilości ich odsłon i wrzucamy go na główną stronę. Następnie klikamy jak szaleni po treści aby wygenerować trochę “kliknięć”.

Można to oczywiście zasymulować lepiej, wykorzystując przeróżne serwisy typu http://www.webconfs.com/search-engine-spider-simulator.php czy czy nawet płatne usługi testowania obciążenia, ale otwarcie kilkudziesięciu podstron serwisu naraz w osobnych zakładkach też pozwoli nam zaobserwować czy serwer radzi sobie z takim “sztucznym tłumem”.

Co warto podkreślić – nie udało mi się w powyższy sposób wywołać jakiegokolwiek błędu. Strony generowane były szybko i bez usterek.

Zachęcony dosyć szybkim generowaniem strony postanowiłem dodać jeszcze atak z flanki i zapuścić z innego serwera prosty test obciążenia z pomocą ab. Puściłem kilka równoległych wątków – ponad 2000 żądań i 20 równoległych wątków i  zabrałem się za klikanie po stronie. Niestety tego było serwerowi za wiele i co rusz natykałem się na komunikat:

PDOException: SQLSTATE[42000] [1203] User palik_2 already has more than 'max_user_connections’ active connections in lock_may_be_available() (line 167 of /home/palik/domains/palik.laohost.net/public_html/includes/lock.inc).

Tym samym uświadomiłem sobie, że w ofercie nie ma podanych limitów na równoczesną ilośc połączeń do bazy danych. Wydaje mi się, że warto byłoby to uzupełnić, żeby zasady korzystania z konta były jasne.

Po tym teście zanotować warto dwie rzeczy – dobrą i złą. Dobra to fakt, że serwer jest skonfiguorwany na tyle “idiotoodpornie”, że przy dużym obciążeniu potrafi poradzić sobie z odpowiadaniem na żądania i pokazywaniem błędów. Zła to fakt, że w sytuacji gdy na naszą stronę wpadnie zgraja ludzi przyciągniętych jakimś “wykopanym” artykułem, mogą pojawić się problemy z serwowaniem treści oraz oczywiście z przekroczeniem dozwolonych limitów na serwerze. Po moich testach wykorzystanie CPU i nieoptymalne kwerendy spowodowały gwałtowny skok na wykresie wykorzystanych zasobów serwera do poziomu 10-15% czyli wielokrotnie powyżej dozwolonego limitu.

Zapewne kilka tysięcy żądań http w kilka minut to mało prawdopodobny scenariusz, a nawet jeśli tak się wydarzy, to za tę cenę nie spodziewajmy się odporności na “slashdot effect”. Prawdę mówiąc mała ilość połączeń do bazy chroni klienta przed jeszcze większym przekroczeniem limitów nałożonych na konto. Jeśli chcemy być wykopo-odporni nie kupujmy taniego konta, kropka.

W celu zasymulowania równomiernego obciążenia ustawiłem na zewnętrznym serwerze odpalane co minutę zadanie cron generujące od 1 do 30 żądań na różne adresy stron z artykułami i komentarzami oraz 2 widokami. Sumarycznie wyszło niecałe 13 tysięcy odsłon strony przez niezalogowanych użytkowników, czyli około 2600 użytkowników, z których każdy wchodzi na stronę i wyświetla 5 podstron. Drupal miał włączone wszelkie możliwe opcje dotyczące zwiększania wydajności. Ruch był “anonimowy”, więc łatwiejszy do obsłużenia, choć na stronach były widoki generowane “pseudolosowo”, więc nie dało się wszystkiego zbuforować.

Na stronie http://www.laohost.pl/knowledgebase/inne/polityka-limitowania-obciazenia możemy przeczytać, że najmniejsze konto powinno wytrzymać bez problemu połowę tego obciążenia (1000-1200 użytkowników dziennie, niestety nie napisano czy chodzi o odsłony czy o wizyty składające się z kilku odsłon). Testy specjalnie przeprowadziłem generując obciążenie powyżej tych opisanych w ofercie. Chciałem w ten sposób zobaczyć czy w ich trakcie pojawią się jakieś problemy z działaniem strony, błędy w logach i tym podobne historie. Nic podobnego się nie stało a proporcje ilość odsłon/zanotowane obciążenie mniej więcej odpowiadało temu co piszą na swoich stronach administratorzy laohost (choć to zależy jak liczyć 1000 użytkowników dziennie).

Efekt przekorczenia limitów był do przewidzenia. Dzienne dostawałem 2 maile z informacją o za dużym obciążeniu jakie generuje moje konto i nieoptymalnych zapytaniach do MySQL. W panelu mogłem obserwować wykresy, z których ten najważniejszy, od którego zależy los klienta w oczach admina, prezentował się następująco:

PODSUMOWANIE

Jak widać na powyższym wykresie konto z ograniczeniem 1%, a nawet 3% zasobów, nie wystarczy na serwowanie strony, którą odwiedza kilka tysięcy osób dziennie. Czy to zarzut? Nic podobnego.

Jeśli popatrzymy na realną grupę docelową oferty hostingowej z ceną 39zł na rok, to w większości przypadków będą to serwisy dopiero rozpoczynające zdobywanie internetu. Ich właściciele niejednokrotnie będą mieli skromny budżet i niewielkie doświadczenie, a uruchomione strony będą odwiedzane przez -naście, -dziesiąt osób na dobę. W takich warunkach najtańsze konto z laohost powinno dać radę, choć przy mocno “napakowanym” Drupalu możemy się spotkać z koniecznością jego optymalizacji albo wykupienia większego limitu zasobów.

Pamiętam swoje pierwsze “tanie” konta (boo.pl, webd), na których wydajność i stabilność pozostawiały wiele do życzenia a klienci naginali cierpliwość adminów i sąsiadów na różne sposoby.  Tutaj mamy niską cenę ale nie kosztem jakości. Przez wszystkie dni pisania tego tekstu serwer chodzi żwawo, nie zdarzają się przestoje, niedostępność usług (ftp, ssh, http), czy znaczące spowolnienia działania. Przy tej cenie cieszy bardzo dostępność SSH, dość dobra baza wiedzy i niezły panel zarządzania usługami.

Paradoksalnie klientów najbardziej powinny cieszyć mnie restrykcyjne zasady współużytkowania serwera. Ponieważ każdy klient będzie na bieżąco alarmowany o ich przekroczeniu możemy przypuszczać, że nie dojdzie do sytuacji kiedy jeden duży serwis notorycznie będzie zabierał moc całego serwera. Jest to w moim odczuciu dobry sposób na dyscyplinowanie użytkowników i jedyne sensowne wyjście z sytuacji. Nie ma niedomówień w stylu “administrator może zamknąć stronę generującą zbyt duże obciążenie”. Są wskaźniki, wykresy, automatyczne maile z napomnieniami – same suche fakty, na podstawie których można dyskutować i negocjować. Jest też opcja dokupienia mocy serwera, co umożliwia klientom utrzymanie się w ramach przydzielonego limitu bez konieczności przenosin serwisu.

Za niewielką kwotę dostajemy niezły zestaw narzędzi, które pozwalają nam obsłużyć niezbyt zatłoczoną witrynę – forum, społeczność czy blog. Drupal działa na tym bez zarzutu i choć drushem nie poszalejemy to sam SSH jest mocnym plusem. Jeśli wybierzemy “lżejszy” CMS to pewnie damy radę przyjąć jeszcze więcej gości. Uważam, że oferta jest adekwatna do ceny i dobrze skomponowana.