Wpisy

Opublikowane w

Automatyczny wybór najlepszego mirrora w Debianie

Co prawda pisałem o tym blisko trzy lata temu, ale warto przypomnieć, że jest nowa metoda wyboru najlepszego mirrora pakietów deb w Debianie. Okazja tym lepsza, że z http.debian.net awansowało na httpredir.debian.org. Czyli jest pełnoprawną, oficjalną częścią Debiana. Jest też możliwość wyboru tego repozytorium podczas instalacji, przynajmniej od wersji Jessie.

Wiele się nie zmieniło, więc po szczegóły odsyłam do starego opisu albo na stronę projektu. Ze zmian: pojawił się adres IPv6, debootstrap też nie ma od jakiegoś czasu problemów z redirectorem. Ja korzystałem przez te trzy lata na różnych systemach (także produkcyjnych) i nie zauważyłem większych problemów, przynajmniej w wersji podstawowej, bo z niszami typu debootstrap czy apt-p2p kiedyś problemy były. Polecam.

Opublikowane w

Blox przyspieszy

W końcu zostało zapowiedziane, że Blox przyspieszy. Bo o ile nowe szablony wyglądają nieźle, to i czas ładowania, i ilość przesyłanych danych, i ocena w różnych narzędziach woła o pomstę. Różne są zboczenia, a moje jest takie, że czasem robię snapshota migawkę stanu bieżącego. Dla pamięci. I taką migawkę zrobiłem lekko ponad rok temu dla starego wyglądu, a następnie opisałem we wpisie o odchudzaniu.

No to pora zrobić migawkę dla nowego wyglądu przed optymalizacją. Dla głównej strony bloga Google Insights prędkość 58 mobilnie, 94 wygląd, dla desktopu ocena 77. Przy okazji, by wyeliminować ew. zmiany, dla konkretnego wpisu (o routerze TP-Link) odpowiednio 58, 96, 78.

Webpagetest (tym razem Praga, Chrome) – strona główna bloga ładowanie (fully loaded) 7,4 s pierwsze ładowanie, 5,0 s kolejne 2907 kB (sic!), 484 kB;. Konkretny wpis 6,8 s (pierwsze ładowanie), 2,3 s kolejne, przesłane dane 945 kB i 166 kB.

Dorzucę jeszcze wyniki popularnego Pingdom Website Speed Test (Sztokholm). Your website is faster than 60% of all tested websites, rzecze. 81/100, 2,59 s. 2,6 MB. Dla konkretnego wpisu odpowiednio 85%, 82/100, 1,25 s oraz 916 kB.

Pierwszego czerwca było napisane, że w ciągu dwóch tygodni, więc z niecierpliwością czekam. I trzymam kciuki, by wszystko dobrze poszło.

Opublikowane w

PUM

Jakiś czas temu zacząłem korzystać z Uptime Monitor. Przyznaję, że jestem zadowolony, do pełni szczęścia brakowało mi czegoś, co wystawi moje uptime’y na WWW. Tzn. jest sporo fajnych narzędzi, rysujących ładnie i live, tzn. z autoodświeżaniem, ale… nie byłem przekonany do pomysłu publikacji kluczy API. Tym bardziej, że w niektórych przypadkach udostępnienie klucza wiąże się z z podaniem danych hosta, loginu i hasła do htpasswd itp.

Wolałbym mieć możliwość ukrycia nazwy/IP i ogólnie nie podawania zbyt wielu informacji, zwł. klucza API. Zauważyłem też, że nie ma (a przynajmniej nie znalazłem) nic do obsługi Uptime Monitora w Perlu. Stwierdziłem, że generowanie statycznego HTML (docelowo) z crona jest zupełnie wystarczające, a ew. autoodświeżanie prosto można załatwić JSem czy IIRC nawet polem META w HTML (koła nie odkrywam, „konkurencja” też tak robi.

I w ten sposób powstał PUM czyli Perl Uptime Monitor. 😉 Jest możliwość nadpisania nazwy, jest możliwość generowania uptime dla danego okresu (ilość dni wstecz). Brakuje opakowania wyniku w HTML (wyniki na STDOUT póki co…), ale to wkrótce… W sumie nie ma problemu z pobraniem danych do wykresu czasu odpowiedz, ale nie planuję póki co. Zachęcam do forkowania i zgłaszania pull requestów, ew. pomysłów w komentarzach.