Piwik, czyli fajne darmowe statystyki na stronę

O statystykach dla stron Piwik usłyszałem dawno temu. Idea wolnego odpowiednika Google Analytics[1] bardzo mi się spodobała, ale do instalacji nie doszło. Powód prozaiczny – nie miałem maszyny 24/7 działającej na sensownym łączu i posiadającą sensowną moc obliczeniową. Sensowną, tj. taką, żeby instalacja MySQL nie wydawała mi się zabójstwem na maszyny. Niedawno o statystykach przypomniał mi wpis ryśka, a obecne na blogu statystyki stat4u są coraz bardziej niewystarczające, głównie ze względu na brak aktualizacji od dłuższego czasu (ostatnia zmiana kilkadziesiąt miesięcy temu). Szczególnie, że chciałem się pobawić w referral fun.

Postanowiłem zaryzykować i zainstalować Piwika na Dockstarze. Co prawda miałem wrażenie, że 128 MB RAM i dysk 2,5″ 5400 RPM, na dodatek w kieszeni USB to nie jest to, co MySQL lubi najbardziej, ale spróbować można. Instalacja Piwika na lighttpd jest prosta i nie ma czego tak naprawdę opisywać. Ku mojemu zdziwieniu MySQL zajął tylko ok. 10% pamięci, a statystyki się zbierały.

Niestety, kliknięcie czegokolwiek w dashboardzie było męczarnią – skrypty PHP na serwerze mieliył po procku (niby 1,2 GHz, ale ARM, poza tym jakieś drobiazgi do łapania spamerów na Blox tam działają) nieprzyzwoicie intensywnie i nieprzyzwoicie długo. Znaczy dziesiątki sekund. Ale to co zobaczyłem było bardzo obiecujące, więc wrzuciłem Piwika na tymczasowego VPSa, który zasadniczo się nudzi (hell yeah, spojrzałem i prawie drugi rok mija darmowego testu, ale to offtopic, więc spuśćmy zasłonę miłosierdzia).

Po prostu rewelacja. Piwik pokazuje wiele rzeczy, których w stat4u nie ma (o statystykach wbudowanych w Blox nie wspominam, bo trudno to nazwać statystyką). Skąd ktoś przyszedł, gdzie poszedł, ile czasu spędził na stronie, rozbicia na systemy operacyjne, wykorzystywane pluginy, aktywność, powracający użytkownicy. I do tego wszystko estetycznie podane. Niby nic kluczowego się nie dowiedziałem, ale zdecydowanie bardziej mi się to podoba. I mam nad wszystkim kontrolę. Próbka jest mała, ale już mogę stwierdzić, że stat4u ma parę błędów (pewnie skutek braku aktualizacji).

Z drobnych poprawek, które warto wykonać: mimo, że to nie high traffic site, warto doinstalować APC, jest szybciej. Być może spróbuję wrócić na Dockstara z doinstalowanym APC, ale może nic z tego nie wyjść – może PHP wisiał na zapytaniach do baz – mało czasu miałem, nie wnikałem. Poza tym, wolałbym to jednak mieć na czymś porządniejszym, niż ADSL.

W każdym razie, w ramach popularyzacji tego oprogramowania, jeśli ktoś chciałby zobaczyć jak Piwik wygląda na jego własnych realnych danych, a nie ma warunków/ochoty na stawianie go samodzielnie, to może podpiąć na swojej stronie na dłuższą chwilę[2] u mnie (free, no strings attached). Chętnych zapraszam do kontaktu mailowego. Warunki są trzy. Pierwszy: nie więcej niż powiedzmy 10k UU miesięcznie (nie apteka) ze względu na wydajność maszyny. Drugi: best effort, czyli nie gwarantuję działania systemu, mogą być przerwy, nie gwarantuję przywrócenia z backupu itp. Oczywiście można dawać znać jak coś nie będzie działać i postaram się poprawić (bo mam tam własne niekrytyczne zabawki), ale wiecie jak jest. Na ten moment uptime system to 4 m-ce. Trzeci: zastrzegam sobie prawo do absolutnie subiektywnego wyboru chętnych (zwł. znajomi (jeśli się pojawią – nie jest to warunek konieczny) mają pierwszeństwo, podobnie jak nietechniczni/nieadmini – zakładam, że techniczni jakby chcieli, to by sami sobie postawili), wyłączenia usługi w dowolnym momencie wybranym serwisom itp. Jasne, postaram się uprzedzić wcześniej. Jeśli są jakieś wątpliwości co do warunków/coś pominąłem – proszę o pytania w komentarzach.

[1] Google Analytics odpada. I tak za dużo wiedzą, więc staram się unikać produktów ze stajni Google.

[2] VPS będzie działał jeszcze jakiś miesiąc. Potem, jeśli wszystko pójdzie dobrze, planuję przeniesienie się (z gratami) na jakieś 3 m-ce na testowego dedyka, a potem… Albo będzie działać na Dockstarze, albo przedłużę dedyka, albo zawinę zabawki.

Czy to naprawdę kod źródłowy tego programu?

Polecam cały artykuł Is that really the source code for this software? a dla niecierpliwych lub niespikających krótkie streszczenie. Wiele wolnego oprogramowania przychodzi w postaci binarnej. Dołączony jest do niej kod źródłowy w teorii odpowiadający dokładnie temu, z którego zostały zbudowane wersje binarne. Zagadnienie jest ważne zarówno z punktu widzenia wolności oprogramowania, jak i bezpieczeństwa.

Autor ww. artykułu postanowił sprawdzić, jak to wygląda w praktyce dla popularnych dystrybucji Linuksa (Debian, Fedora, OpenSUSE). Na przykładzie tak prostego oprogramowania jak tar. Wykorzystał do tego celu minimalne instalacje systemu, korzystał ze źródeł dostarczonych w dystrybucjach i metod budowania zalecanych przez dystrybucje.

Wyniki są dość zaskakujące: ani razu nie udało mu się uzyskać dokładnej (bit w bit) kopii tego prostego przecież pakietu wykorzystując kod źródłowy.

W przypadku Debiana różnice były minimalne (data i id buildu w plikach wykonywalnych), w przypadku OpenSUSE było gorzej. Powstałe pliki binarne były 5 razy większe od oryginału. Po wykonaniu strip na wersjach binarnych sytuacja wyglądała już podobnie jak w przypadku Debiana. Najgorzej wypadła Fedora – nie tylko różnic było najwięcej, ale autorowi artykułu nie udało się ustalić przyczyn wszystkich rozbieżności . Jak pisze „niełatwo stwierdzić, czy samodzielny build ze źródeł będzie funkcjonował identycznie, jak opublikowana wersja binarna z dystrybucji”.

W przypadku skomplikowanych pakietów i projektów luźniej podchodzących do kwestii wolności oprogramowania, niż dystrybucje Linuksowe (np. firmware routerów z wykorzystaniem wolnego oprogramowania – często zamieszczają kernel, ale zwykle jest to wersja waniliowa wzięta na żywca z kernel.org…) różnice będą jeszcze większe. Gdyby ktoś znalazł komentarz RMS do sprawy, proszę o linka – bardzo jestem ciekaw, co ma do powiedzenia w tej sprawie.

UPDATE: Problem czy to naprawdę kod źródłowy danej binarki został dostrzeżony i doceniony, idea reproducible builds stała się popularna.

Jaki serwer DNS wybrać?

Wybór serwera DNS z którego korzystamy na urządzeniu końcowym jest ważny z kilku powodów:

  • Szybkość serwera DNS. Czas oczekiwania na odpowiedzi z serwerów DNS może być istotną częścią czasu ładowania stron Jest to szczególnie widoczne na stronach z dużą ilością wklejek z różnych domen. W przypadku szybkości serwera DNS nie chodzi jedynie o opóźnienie sieci (to można sprawdzić przy pomocy ping), ale o czas udzielenia odpowiedzi. Zależy on już od większej liczby czynników: opóźnienie sieci, posiadanie bądź nie odpowiedniego spisu w cache (oczywiście lepiej, jeśli odpowiada z cache), wydajność sprzętu i oprogramowania na którym działa DNS.
  • Poprawność odpowiedzi. Nic po szybkiej odpowiedzi z serwera DNS, jeśli będzie ona błędna. W skrajnym przypadku możemy paść ofiarą spoofingu DNS i trafić na podstawioną stronę.
  • Neutralność, czyli brak cenzury. Trochę wiąże się z poprzednim zagadnieniem, ale w tym przypadku chodzi o to, że do pewnych stron w ogóle nie będzie można się dostać. O ile działanie takie ma sens przy ograniczaniu zasięgu szkodliwego oprogramowania, to może być także służyć jako ograniczenie dostępu do treści.

 

Co warto zrobić w kwestii DNS?

Jeśli posiadamy sieć lokalną z kilkoma (i więcej) komputerami, to prawie na pewno warto postawić lokalny cache DNS – dzięki temu powtarzające się nazwy będą rozwiązywane lokalnie. Dobrym i prostym rozwiązaniem dla małej sieci jest dnsmasq, dostępny także dla OpenWrt.

Poza tym, warto wybrać te serwery DNS, które odpowiadają najszybciej. Zwykle nie popełnimy dużego błędu, jeśli wybierzemy serwery zalecane przez naszego dostawcę sieci lub wskazane automatycznie.

Czy zawsze lokalny serwer DNS lub oferowany przez naszego dostawcę Internetu jest najlepszy? Niestety nie. Prawie zawsze będzie on najszybszy pod względem opóźnienia sieci, ale już zawartość cache bywa różna. Szczególnie w przypadku lokalnego serwera może się okazać, że jego cache jest pusty dla większości zapytań. Na szczęście zwykle narzut lokalnego serwera nie jest duży.

Jeśli nasz komputer łączy się z internetem za pośrednictwem wielu sieci (wifi, połączenia GSM), można pomyśleć o postawieniu lokalnego cache DNS bezpośrednio na nim.

Jak najprościej znaleźć najlepsze serwery DNS?

Istnieje do tego darmowy i wolny program o nazwie namebench, służący do benchmarku serwerów DNS. Działa na wszystkich systemach, wersję dla Windows i Mac OS X można pobrać ze strony, w przypadku Linuksa zapewne jest w dystrybucyjnym repozytorium. Domyślnie działa z GUI, ale nie jest ono niezbędne – program daje się również uruchomić w konsoli. Ważne jest, żeby nie uruchamiać testu od razu, tylko najpierw przeczytać jak program działa i zastanowić się, co chcemy zrobić. Dlaczego? Ano dlatego, że pierwsze uruchomienie jest najbardziej zbliżone do rzeczywistych warunków ze względu na oryginalną, niezakłóconą poprzednimi testami zawartość cache testowanych serwerów DNS, czyli najbardziej miarodajne.

Jak korzystać z namebench?

W polu nameservers warto podać, oddzielone spacjami przynajmniej: DNS lokalny w sieci (jeśli posiadamy), serwery DNS naszego ISP. W przypadku Polski dodatkowo warto podać serwery DNS Orange (najpopularniejsze to 194.204.159.1 i 194.204.152.34) – kiedyś były dostępne tylko dla klientów TPSA, ale obecnie wyglądają na otwarte – działają z każdej sieci, z której testowałem – i osiągają dobre wyniki. W moim przypadku były szybsze, niż serwery DNS mojego ISP.

Namebench - ekran startowy
Ekran startowy namebench. Źródło: strona domowa programu namebench.

Poza tym, zaznaczamy globalne publicznie dostępne serwery cache’ujące oraz serwery regionalne. Można zaznaczyć sprawdzanie pod kątem cenzury i podzielenie się uzyskanymi wynikami. Lokalizacja to oczywiście Polska, query data source – możemy skorzystać z historii stron którejś z naszych przeglądarek, wyniki będą wówczas bardziej zbliżone do realnych.

Następnie uruchamiamy test i na kilka-kilkanaście minut zostawiamy komputer w spokoju. Po tym czasie otrzymamy wyniki: propozycję trzech najlepszych dla nas – zdaniem programu – serwerów DNS (kolejność ma znaczenie) oraz szczegółowe dane i wykresy. Kluczowy dla szybkości działania sieci jest oczywiście średni czas odpowiedzi z serwera DNS.

Na koniec uwaga: jeśli najszybsze serwery nie należą do naszego ISP ani nie są otwartymi, publicznymi serwerami, może się zdarzyć, że ich właściciel ograniczy za jakiś czas do nich dostęp.