error log

Kompilując kod w C na systemie 64-bitowym możemy otrzymać następujący komunikat:

gnu/stubs-32.h: No such file or directory

Rozwiązaniem jest dodanie opcji -m64 do wywołania kompilatora gcc.

Jeżeli program, który jest kompilowany, korzysta ze skryptu configure, można uruchomić ten skrypt następująco:

# CFLAGS=-m64 ./configure

WordPress po (przerwanej) aktualizacji wita nas komunikatem:

Briefly Unavailable for Scheduled Maintenance

Szybkie rozwiązanie: usunąć plik .maintenance (nazwa pliku zaczyna się od kropki) z głównego katalogu WordPressa.

Polecenie zf powinno być wywoływane w głównym katalogu aplikacji. Gdy i to nie pomaga, w tymże katalogu brakuje pliku .zfproject.xml

Optymalizacja stron internetowych z myślą o wyszukiwarkach jest równie istotna, jak uczynienie ich wygodnymi w obsłudze przez odwiedzających ją ludzi. Co prawda spece z Google twierdzą, że najważniejsze jest, aby strona była odpowiednia dla ludzi, nie dla robotów, ale dlaczego nie pomyśleć o tych ostatnich?Drupal bezpośrednio po zainstalowaniu nie pozwala na tworzenie w pełni zoptymalizowanych stron. Brakuje choćby możliwości rozróżnienia treści w tytule nagłówkowym i w tagu title strony. Nie można też tworzyć własnych opisów meta description.

Meta description

Aby móc dowolnie zarządzać treścią tagu meta description, należy dołączyć moduł nodewords znany też jako „meta tags” i w ustawieniach konfiguracyjnych (admin/content/nodewords/settings) zaznaczyć przynajmniej checkbox odpowiadający tagowi description. W formularzach edycji zawartości pojawi się wówczas nowe pole tekstowe pozwalające na wpisanie własnego opisu strony.

Należy też sprawdzić, czy w używanej przez nas skórce nie jest przypadkiem zaimplementowane dodawanie znacznika opisu – należy wówczas wyłączyć taką możliwość.

Tytuły stron

Korzystne z punktu widzenia optymalizacji stron jest umieszczenie najważniejszych słów kluczowych na początku tytułu strony. Jednak czasem taki tytuł będzie niestrawny dla czytelnika, a jeżeli zapragniemy być figlarni i użyć metafory… dość powiedzieć, że Google ma bardzo prostolinijny stosunek do życia i gry słów należy stosować wszędzie, byle nie w tagu TITLE.

Po instalacji modułu Page Title zdobędziemy kontrolę nad zawartością tagu tytułowego w sekcji HEAD.

Przypadkowe H2

Jeżeli przygotowaliśmy już szablon strony, w którym najważniejsze rzeczy są zawarte w tagach nagłówkowych od H1 do H6, może nas czekać niemiła niespodzianka. O ile Google przeważnie dość trafnie wyszukuje najważniejszy nagłówek na stronie, o tyle wyszukiwarka Yahoo może jako tytuł strony wyświetlić zawartość pierwszego nagłówka, jaki znajdzie w treści strony, co ostatnio przydarzyło mi się na jednej z moich stron. Tak się składa, że był to nagłówek H2 wygenerowany przez blok wyświetlający menu nawigacyjne – o treści „Primary links” i taki też tytuł strony pojawił się w wynikach wyszukiwania Yahoo.

Jeżeli menu nawigacyjne znajduje się w źródle strony powyżej pierwszego istotnego znacznika H1 lub H2, warto wyłączyć wyświetlanie jego tytułu. W tym celu należy odwiedzić listę bloków (ścieżka admin/build/block), kliknąć na odnośniku konfiguruj przy bloku Primary links, a następnie w polu tytułu bloku wpisać tekst , dzięki czemu tytuł bloku nie będzie się pojawiał.
Duplikująca się treść na wielojęzycznych stronach

Na stronach tworzonych w wielu językach zazwyczaj korzysta się ze standardowego bloku wyświetlającego odnośniki do alternatywnych wersji językowych. Przede wszystkim dotyczy nas tu problem opisany w poprzedniej sekcji. Jeżeli blok zmiany języka znajduje się w źródle strony powyżej pierwszego istotnego znacznika H1 lub H2, należy pozbawić go tytułu w sposób opisany powyżej.

Problem jest jednak głębszy. Otóż nawet na stronach, które nie posiadają alternatywnej wersji językowej, pojawi się odnośnik zmiany języka prowadzący do tej samej strony, lecz z adresem wzbogaconym o odpowiedni prefiks. Na tejże stronie przetłumaczone zostaną wszelkie napisy wygenerowane przez Drupala, natomiast zasadnicza treść artykułu pozostanie ta sama.

W tej sytuacji pozostają nam dwa wyjścia – na takich stronach nie umieszczać odnośnika do innych wersji językowych w ogóle, lub umieścić odnośnik do alternatywnej wersji językowej głównej strony naszego serwisu.

Taka zmiana wymaga dopisania jednej funkcji w dowolnym module. Oczywiście dobrze, aby był to jeden z naszych własnych modułów: zmiany w modułach standardowych to zły pomysł (znikną przy kolejnej aktualizacji Drupala). Opis tworzenia modułów wykracza poza ramy tego tekstu, więc zaprezentuję jedynie treść funkcji. Zakładam, że moduł, w którym znajdzie się ta funkcja nosi nazwę „naszmodul”.

function naszmodul_translation_link_alter(&$links, $path) {
    global $language;
    if (!($paths = translation_path_get_translations($path))) {
        foreach ($links as $langcode => $link) {
            if (strpos($links[$langcode]['href'], 'node/') === 0) {
                if ($langcode == $language->language) {
                    unset($links[$langcode]);
                } else {
                    $links[$langcode]['href'] = '';
                }
            }
        }
    }
}

To wystarczy, aby odnośniki zmiany języka nie prowadziły do zduplikowanej treści.

Gdyby zastanowić się przez chwilę, czy serwis oparty o Drupala będzie działał wydajniej po przeniesieniu się z hostingu dzielonego na serwer VPS, odpowiedź wydaje się oczywista – VPS to duży skok jakościowy w sferze wydajności. Jednak nie zawsze.Gdy w konfiguracji Drupala włączone jest pobieranie wyświetlanych stron z cache, wydajność zależy przede wszystkim od prędkości procesora oraz wydajności bazy danych. Jednak zdarzają się serwisy, w których korzystanie z cache jest utrudnione lub wręcz niemożliwe.

W takiej sytuacji każde wywołanie strony oznacza włączenie co najmniej kilkunastu plików przy pomocy operacji include. Czy włączenie pliku to taka czasochłonna operacja?

Napotkałem ostatnio taką właśnie sytuację – serwis uruchomiony na dzielonym hostingu działał o rząd wielkości szybciej niż uruchomiony na serwerze VPS, co stwierdziłem przy pomocy narzędzia ab (istotne jest, aby uruchamiać ab bezpośrednio na testowanym serwerze, aby odrzucić wpływ komunikacji sieciowej na pomiar wydajności, jeżeli już mierzymy ją tym sposobem). Analiza logów wygenerowanych przez moduł xdebug wykazała, że ponad połowa czasu wykonania została spędzona w operacji włączania plików.

Szybkie pomiary wykonane naiwną metodą kopiowania gigabajta danych z /dev/zero do pliku i z powrotem wykazały, że dane były kopiowane ze średnią prędkością 20MB/s (megabajtów na sekundę), co jest wynikiem bardzo miernym.

Duże znaczenie dla wydajności operacji dyskowych ma wybór oprogramowania realizującego wirtualizację. Ogólnie rzecz biorąc serwery VPS oparte o OpenVZ lub Virtuozzo realizują dostęp do dysku z prędkością niewiele mniejszą niż działoby się to na serwerze dedykowanym. Z kolei platforma Xen, choć zapewnia lepszą izolację serwerów wirtualnych – albo w wyniku tego – wypada w tym porównaniu bardzo mizernie. Jeżeli więc wiemy z góry, że nasza aplikacja włącza wiele plików, serwer VPS oparty o Xen może nie być najlepszym wyborem.

Czasem też wydajność operacji dyskowych jest obniżona przez kiepskie sąsiedztwo, a więc serwery VPS znajdujące się na tym samym fizycznym serwerze, na których uruchamiane są aplikacje intensywnie korzystające z dostępu do dysku.

Dobrym pomysłem jest wykupienie w upatrzonej firmie serwera VPS na miesiąc i wykonanie własnych testów wydajnościowych.