Przez ostatni tydzień miałem spore problemy z hostingiem. Wszystkie domeny oparte o MySQL, którymi zarządzam, zaczęły raportować błędy, głównie 500 Internal Server Error. Zgłosiłem to do mojej firmy hostingowej, która do tej pory dość sprawnie radziła sobie z problemami i czekałem niecierpliwie na rozwiązanie. Niestety, support zbywał mnie standardowymi odpowiedziami, wklejanymi z gotowego szablonu, które niewiele pomagały, a konkluzja była, że problem leży po mojej stronie, a konkretnie uruchamianych skryptów. Nie lubię tego – zapachniało polskimi firmami hostingowymi i wszystkimi moimi wcześniejszymi problemami.

Postanowiłem szybko zorientować się w aktualnych opiniach innych o Dreamhoście i zapodałem odpowiednie wyszukiwanie na Twitterze. Okazało się, że jest sporo świeżych negatywnych opinii o DH, sugerujących, że ostatnio popsuła się tam obsługa klienta i serwery są przeciążone, co pokrywało się z moimi spostrzeżeniami.

Ponieważ nie było poprawy działania moich serwisów, postanowiłem rozejrzeć się za jakimś rozwiązanie. Przez moment chciałem ulec lenistwu i przenieść wszystko na znacznie droższą usługę Virtual Private Servers w DH, ale skorzystałem z sugestii w Twittera i zapoznałem się z ofertą innej firmy hostingowej w USA – Site5. Cena porównywalna, a deklarowana jakość usług miała być lepsza. Zamówiłem 6 miesięcy na początek i napisałem o tym na Twitterze, co zostało natychmiast zauważone przez support nowego usługodawcy – dobry znak.

Miałem trochę zabawy z przeniesieniem zawartości, a potem było nużące oczekiwanie na propagację zmian w DNS, które umożliwiłyby mi reaktywację bloga. W końcu udało się i jestem z powrotem. Przy okazji zrobiłem porządek z wtyczkami, usunąłem trochę nadmiarowych i poprawiłem drobne detale w wyglądzie.

Co do zgodności z deklaracjami, to mogę zaprezentować różnice w obciążeniach serwera, które zanotowałem w tym samym czasie w obu serwisach:

• Dreamhost – serwer z 4 procesorami Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, średnie obciążenie: 14.85, 10.32, 10.46
• Site5 – serwer z 8 procesorami Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, średnie obciążenie: 0.02, 0.07, 0.08

Jak widać, różnica jest kolosalna. Przedstawione tu obciążenie serwera DH nie jest wcale maksymalne – widywałem znacznie większe wartości. Jak na razie serwer Site5 nie przekraczał wartości 0.5. Teraz nie już żałuję, że nie wykupiłem hostingu w Dreamhoście na dłużej.

Wczoraj miałem jakiś dobry dzień na przenosiny i wyemigrowałem Miasik.net na nowy hosting. Najwyższy czas na pożegnanie z polskimi firmami hostingowymi, z którymi prędzej czy później są kłopoty. Ostatni polski hosting funkcjonował całkiem nieźle, ale ze te pieniądze można mieć znacznie więcej za granicą i to zarówno w kwestii oferowanych przestrzeni dyskowych czy pasma, ale także narzędzi i łatwości obsługi.

Wylądowałem w firmie Dreamhost, na której zresztą od pewnego czasu hostuję serwis Libertarianizm.net i inne zaprzyjaźnione strony. Dzięki temu, że mogłem przyjrzeć się wcześniej działaniu tego hostingu, wiem, że to dobra firma i dobra usługa. Ponad 500 GB przestrzeni dyskowej i 6 TB pasma miesięczne to dużo za dużo w stosunku do moich potrzeb, ale nigdy nie wiadomo, kiedy może się przydać. Do tego nielimitowane domeny, konta mejlowe, konta shellowe, bazy mySQL i temu podobne rzeczy. No i firma z wieloletnią tradycją i doświadczeniem.

To wszystko za $120 rocznie albo $215 za dwa lata. Do tego użycie kodu miasik gwarantuje $50 zniżki na dowolny okres usługi, czyniąc ten hosting jeszcze jeszcze tańszym. Sam teraz żałuję, że nie wykupiłem go na dłużej.

Co się przeprowadzę na kolejny hosting w złudnej nadziei, że będzie lepiej. Wylądowałem niedawno w nazwa.pl, zachęcony półroczną promocyjną ceną i ciekawą ofertą. Ogólnie jestem zadowolony, działa sprawnie, choć obsługa domen mogłaby być lepsza. Niewiele jednak tych domen mam, więc się nie przejmowałem. Było nieźle, do czasu.

Okazało się, że mój blog został jakoś intensywnie zaatakowany przez spamboty, z którymi skutecznie radziła sobie wtyczka Spam Karma 2. Niestety, za cenę intensywnej współpracy z bazą danych, a to jest coś, czego nie lubią firmy hostingowe.

To się wpisuje generalnie w ogólny plan oferowania usług, z których nie chce się potem wywiązywać, bo to obciąża innych klientów. Dostajesz niby nieograniczone rozmowy za darmo, ale nie więcej niż 1000 minut miesięcznie. Albo masz hosting, gigabajty przestrzeni dyskowej, olbrzymie pasmo, ale nie możesz przekraczać jakiejś niezdefiniowanej wartości obciążenia procesora. Tym razem jest to przekroczenie jakiejś granicznej ilości zapytań do bazy danych.

No i firma, bez ostrzeżenia, zablokowała dostęp do mojego serwisu. Nie informując mnie ani o takim zamiarze, ani też o samym fakcie. Jeden z czytelników na Gadu-Gadu zapytał o to, co dzieje się z moją stroną, a ja zorientowałem się, że dzieje się coś złego. Zapytałem firmę o przyczynę i dostałem wiadomość, że właśnie zostałem odcięty z powodu generowanie 20-30 tysięcy zapytań do bazy na minutę. Na szczęście dostałem jakiś log z tych zapytań, co pozwoliło mi zorientować się, że chodzi o odparcie ataku spambotów. Informacja też głosiła, że dopiero co nie działam, a wiem, że trwało to już od dnia poprzedniego – tak to jest z rzetelnością.

Acha, nie obyło się bez sugestii o zmianę usługi hostingowej na czterokrotnie droższą, zamiast 300 PLN rocznie, 1200 złociszy. Ten schemat też znam. Fajnie, ale jeszcze muszę sporo popracować nad tym blogiem, aby stać mnie było na taki hosting.

Wyłączyłem Spam Karmę, przeszedłem na Akismeta – na szczęście nie mieszczę się w ramach bloga komercyjnego i nie muszę za Akismeta płacić. Zobaczymy, jak on sobie da radę.

No i czekam na wyrok, czy podjęte przeze mnie działania wystarczą, aby utrzymać obecny hosting. Nie chcę się przenosić ponownie. Wystarczy mi tych hostingów.

Zaliczyłem właśnie kolejną przeprowadzkę hostingową i przydał się mi mój własny opis tego procesu. Zobaczymy, może w nowym miejscu będzie lepiej. Stare było w porzo, ale wolno działało i od kilku miesięcy nie działały statystyki, więc trzeba było ruszyć w dalszą drogę.

Teraz może będzie lepiej – z pewnością szybszy i sprawniejszy serwer, ulokowany w Polsce. Ale nie wszystko jest dobrze, bo na razie nie mam poczty, bo coś jest sknocone. Support na razie milczy, co jest niezbyt fajne, ale co z tego, że poprzedni support odpowiadał błyskawicznie, skoro był nieskuteczny.

Jak się wreszcie to wszystko uspokoi, może zabiorę się znów za pisanie.

Udało się! Pierwsze efekty nie były zbyt obiecujące, ale dalsze próby plus odrobina guglowania przyniosły oczekiwany efekt – Miasik.net nie jest już hostowane na superhost.pl. I bardzo dobrze.

Teraz opis całego procesu:

1. Eksport bazy z aktualnego hostingu. Nie należy używać do tego celu phpMyAdmina, przynajmniej u mnie nie przyniosło to zadowalającego rezultatu. Wyeksportowana baza miała zepsute kodowanie i w docelowym miejscu nic się nie dało z tym zrobić. Eksportujemy bazę używając funkcji Kopia Zapasowa naszego WordPressa lub poprzez phpMyAdmina. Zgrywamy sobie spakowaną bazę na dysk lokalny, czyli do domu.
2. Weryfikacja poprawności eksportu. Rozpakowujemy archiwum bazy i wczytujemy plik SQL do edytora, który daje sobie radę z kodowaniem UTF-8. Ja polecam rodzimy produkt – Fox Edit lub EmEditor Free. Jeśli wczytany plik przy ustawieniu kodowanie UTF-8 pokazuje wpisy z polskimi znaczkami poprawnie, jesteśmy w pół drogi do sukcesu.
3. Utworzenie nowej bazy w hostingu docelowym. Baza będzie pusta. Tworzymy też użytkownika z zestawem praw, który będzie miał dostęp do tej bazy.
4. Instalacja WordPressa. Uploadujemy pliki programu, ale nie uruchamiamy żadnych skryptów instalacyjnych. Odpowiednio modyfikujemy plik wp-config.php wprowadzając ustawienia dla nowej bazy i nowego użytkownika (albo zostawiamy stare, gdy się nie zmieniły). WordPress czeka sobie na wypełnienie bazy.
5. Import zawartości starej bazy. Na nowym hoście importujemy bazę, tym razem przez phpMyAdmin, bo pewnie nie będzie innej możliwości. Wybieramy naszą nową bazę i opcję Import, podajęc następnie lokalizację pliku z kopią zapasową starej bazy na naszym lokalnym dysku.
6. Uruchamiamy WordPressa i patrzymy na rezultat. Najprawdopodobniej zobaczymy sporo znaków zapytania w miejscu polskich literek. Oznacza to, że czeka nas dalszy ciąg hackowania. W tym celu otwieramy w edytorze plik wp-db.php znajdujący się w folderze wp-includes. W nim, w wierszu 43 dodajemy następujący zapis:
   
mysql_query("SET NAMES 'utf8'");

   Po tej edycji wiersze w okolicy wiersza 43 wyglądają następująco:
   
function wpdb($dbuser, $dbpassword, $dbname, $dbhost) {
$this->dbh = @mysql_connect($dbhost, $dbuser, $dbpassword);
mysql_query("SET NAMES 'utf8'");
if (!$this->dbh) {
$this->bail("

   Wysyłamy zmieniony plik na serwer, oczywiście do katalogu wp-includes i odświeżamy strony naszego WordPressa. Znaczki zapytania w cudowny sposób zmieniają się w polskie znaki i wszystko wygląda cudnie.

Ponieważ zmieniłem hosta, ale nie zmieniłem adresu bloga, nie musiałem nic modyfikować w tabelach bazy, aby WordPress uwzględniał nowy adres. Niemniej jednak, jest to operacja, którą można wykonać edytorem Fox-Edit na wyeksportowanej bazie, albo poprzez phpMyAdmina, po zaimportowaniu jej do nowego hosta.

Uaktualnienie: powtórzyłem proces przenosin, tym razem dokonując eksportu poprzez phpMyAdmina. Wszystko udało się znakomicie, z czego wnioskuję, że jeśli plik wyeksportowany SQL dobrze wygląda w np. edytorze EmEditor, czyli mam poprawnie zakodowane polskie znaki, to wszystko będzie w porządku.

Pewnego dnia, zupełnie niespodziewanie otrzymałem od firmy hostującej (superhost.pl) moje oba blogi bardzo niepokojącą informację o następującej treści:

Niestety od dłuższego czasu Państwa konto generuje obciążenie, które przekracza maksymalne obciążenie dozwolone dla pakietu START. W obecniej postaci nie jesteśmy w stanie hostować Państwa na takim koncie. Proszę popracować nad optymalizacją skryptów lub przejść na wyższy pakiet. Jeśli sytuacja nie ulegnie poprawie, konto zostanie zawieszone dnia 06.09.2006.

Przyznam, że byłem trochę zaskoczony, choć z drugiej strony wiedziałem, że dokonywałem przez swoje konto transferów sporej ilości danych, gdy padł firmowy serwer FTP. Szybko sprawdziłem panel kontrolny mojego konta, który jednak nie wykazywał żadnych problemów z przekraczaniem limitów w ostatnim miesiącu, ani też w poprzednich. Co gorsza, z wiadomości wynika, że moje przewinienia są “od dłuższego czasu”, a moje transfery były raczej kwestią niedawną i jednostkową. WTF? – pomyślałem. I jak mam zabrać się za optymalizację i czego, skoro nie wiem, o jakie limity chodzi.

Co ciekawsze, wiadomość jest oficjalną groźbą rozwiązania umowy, a nie podaje ani o jakie “maksymalne obiążenie” chodzi, ani też dlaczego w ogóle chcą mi to konto zamknąć. Przestudiowałem regulamin i znalazłem stosowny punkt, który rzeczywiście pozwala firmie na takie działanie. Szkoda tylko, że w oficjalnym piśmie nic się nie wspomina na ten temat, ale kto by się tam w naszym kraju trzymał jakichś przyzwoitych procedur.

Sugestia optymalizacji skryptów jest może chwalebna, ale skoro nie wiem jakie właściwości tychże skryptów mam optymalizować, to nie wiem, co właściwie mam robić. Skoro nie znam charakteru obciążenia, nie wiem na co mam zwracać uwagę. Skoro nie mam możliwości monitorowania obciążenia innego niż transfer (a ten mieścił się w 60% limitu), to jak mam stwierdzić, że moje działania przynoszą pożądany, czy jakikolwiek, skutek?

Na dodatek to jest tylko blog i to nie należący do najpopularniejszej kategorii. Owszem, rozwiający się, ale bez przesady. Na dodatek jedyna wartościowa rada, którą daje się jasno przeczytać z otrzymanej wiadomości, to możliwość zmiany pakietu na wyższy, czyli droższy. Ogólnie ujmując, wyglądało to na próbę “zachęcenia” mnie do wykupienia droższej usługi pod nieokreślonym pretekstem niemożności korzystania z obecnej.

Użyłem tych wszystkich argumentów w mojej odpowiedzi, wyrażając oburzenie na sposób, w jaki firma traktuje swoich klientów. I oczekiwałem szybkiej odpowiedzi, bo czas uciekał. Odpowiedź nadeszła chyba po 2 dniach:

Witam, problem polega na tym �e skrypt kt�ry wyknuje si� z Pana konta obci��a znacznie nasz procesor. Inni u�ytkownicy serwera maj� problem z korzystaniem z tego serwera poniewa� Pana skrypty nie sa dopsowane do takiej ilo�ci odwiedzaj�cych lub te� zawieraj� b��d. Prosz� so� dostosowa� do terminu 06.09.2006 bo nie mo�emy �wiadczy� us�ug na najwy�szym poziomie ze wzgl�du na obci��enia generowane przez wadliwe skrypty. Porblemy s� z nast�puj�cym skryptem: detalion /usr/bin/php index.php. Prosze poprawi� lub zmieni� pakiet na wy�szy.
Pozdrawiam.

Tak, oprogramawanie użyte do napisania tej odpowiedzi nie oznacza sposobu kodowania polskich znaków, więc zobaczyłem ją tak, jak widać powyżej. Profeska.

Poza tym, że odpowiedź zignorowała większość kwestii i pytań podnoszonych w mojej wiadomości, to niosła jedną cenną informację – wyjaśniło się, o jakie obciążenie i jakie limity chodzi. Moje skrytpy generowały zbyt duże obciążenie CPU, uniemożliwiając innym klientom korzystanie z serwera. Totalna dominacja!

Problem w tym, że podana ścieżka jest nic nie warta. Informuje jedynie, że za nadmierne obciążenie jest odpowiedzialny interpreter języka PHP przetwarzający stronę index.php. Ha, to ci wiadomość. Moje konto obsługuje 3 domeny, a każda z nich zawiera przynajmniej jedną stronę index.php, a tak naprawdę jest ich znacznie więcej. I która z nich jest winna? Każdy, kto choć trochę otarł się o kontrolę jakości, wie, że takie raporty są nic nie warte, bo nie przybliżają nikogo do rozwiązania problemu.

Oczywiście nie trzeba być też geniuszem, aby zorientować się, że chodzi o główny skrypt najpopularniejszej mojej domeny, więc zamiast wojować moimi celnymi argumentami, po prostu poczytałem to i owo i dokonałem pewnych zmian. Usunąłem statystyki, które z pewnością obciążały znacznie bazę i CPU. Zainstalowałem dodatkowy mechanizm cache (WP-Cache), który powinien zmiejszyć obciążenie bazy. Dodałem 2 systemy (Bad Behavior i Referrer Karma) przeciwdziałające dostępowi do bloga przez spamboty szukające możliwości podrzucenia mi spamowych pingów i trackbacków – co prawda inna wtyczka (Spam Karma 2) skutecznie je odsiewa, ale same próby dostępu już generują zbędne obciążenie. Oczywiście były to działania w ciemno, bo nie otrzymałem żadnej możliwości sprawdzenia rezultatów. Poinformowałem usługodawcę o podjętych krokach i oczekiwałem na wyrok, bo deadline był tuż, tuż. Oto on:

Witam, sytuacja wczoraj sie ustabilizowała ale będzie Pan pod obserwacją.

Uff, zdążyłem. Ale będę pod obserwacją. Niezmiernie się cieszę.

Całe to doświadczenie przekonało mnie, że muszę zmienić firmę hostingową, bo superhost.pl nie jest firmą, która potrafi świadczyć usługi na najwyższym poziomie, niezależnie, co tam sobie deklaruje. Dlaczego superhost nie jest firmą godną polecenia? Dlatego:

1. Nie potrafi jasno i przejrzyście powiadomić klienta o problemie, który go dotyka – musiałem domagać się wyjaśnienia lakonicznego komunikatu, zamiast otrzymać takie informacje na wstępie. Na dodatek wyjaśnienie w niczym nie pomogłoby klientowi bez mojego doświadczenia i znajomości tematów.
2. Przedstawiciele firmy nie czytają ze zrozumieniem i nie odpowiadają na kierowane do nich pytania – w szczególności nie dowiedziałem się, czy zmiana pakietu rozwiąże problem moich “wadliwych” przecież skryptów. Sugeruje to, że oferowane “rozwiązanie” problemu wcale nim nie jest.
3. Stosuje niejawne metody limitowania obciążenia (w tym wypadku chodzi o obciążenie CPU) bez uprzedniego powiadomienia o tym klientów i bez udostępnienia im możliwości monitorowania takiego obciążenia. Klient dowiaduje się, że popełnia nieświadomie jakieś wykroczenie i nie wie, o co konkretnie chodzi i dlaczego tak się dzieje.
4. Nie pomaga użytkownikom w likwidacji problemów – choćby przez informację o tym, co jest konkretną przyczyną problemu. Klient zostaje sam ze swoim problemem i musi go sam rozwiązać, działając w ciemno, z braku możliwości oceny skuteczności swoich działań.
5. Nie ma ustawionego kodowania znaków w systemie odpowiadania na zapytania klientów, przez co otrzymane wiadomości wyglądają jak w cytacie powyżej. To też nie świadczy o profesjonalizmie firmy.
6. Jako rozwiązanie problemu podaje zmianę pakietu na droższy, bez żadnego uzasadnienia, że taka zmiana jest naprawdę konieczna. Co gorsza, nie ma żadnej pewności, że zmiana pakietu zapewni likwidację kłopotu.

I nie dlatego superhost.pl nie jest w stanie świadczyć usług klientom na najwyższym poziomie, bo uruchamiam jakieś “wadliwe” skrypty, ale dlatego, że po prostu nie potrafi. Dowodzi tego obsługa mojej skromnej osoby, która nie była nawet na poziomie średnim.

Kiedyś polecałem superhost.pl każdemu. Od teraz, będę go odradzał, co niniejszym czynię. I już, dzięki moim czytelnikom, zabrałem się za sprawdzanie alternatywnych serwisów. Mam już na oku bardzo ciekawego kandydata. I odpowiadają szybko i na temat. Dam znać, kiedy się zdecyduję.