Łukasz Stachowiak blog

Enkapsuluj swoje wyjątki

noreply@blogger.com (Anonymous) — Wed, 21 Nov 2012 12:58:00 +0000

Tyle o tej enkapsulacji, a mało kto pisze o tym w kontekście wyjątków.
Może najpierw trochę o tym jakie wyjątki rzucać. Zgodnie z arkanami sztuki metoda powinna rzucać wyjątki _tylko_i_wyłącznie_ istotne z punktu widzenia interfejsu jaki reprezentuje. Biorąc za przykład:

interface UserRepository {
    List<User> activeUsers() throws DataAccessException;
}

Metoday activeUsers zwraca listę użytkowników i jest zupełnie sensownym to, że zgłosi wyjątek DataAccessException, gdy pojawi się błąd z dostępem do danych. Zgłaszanie wyjątku typu BufferOverflowException, albo DOMException nie da klientowi żadnej użytecznej informacji na temat tego co się stało. Klienta interesuje to, że repozytorium ma problem z dostępem do danych, a nie to, że w środku jakiś bufor się przepełnił, albo przetwarza błędny dokument DOM.

To prowadzi do myśli o enkapsulacji. Gdybyśmy sprzedawali bułki w sklepie, a nasz piekarz wstrzymałby dostawę na parę dni, ponieważ w jego piekarni pojawił mklik próchniczek - nie informowalibyśmy o tym naszych klientów, bo już więcej by się nie pojawili. Taką informację zachowamy dla siebie, zmienimy piekarza, a klientowi powiemy, że mamy problemy z dostawą na parę dni. I tak też powinniśmy robić w świecie Javy. Metoda activeUsers() nie powinna zwracać wyjątku typu SQLException czy FileNotFoundException. Klienta to nie interesuje skąd repozytorium bierze dane. Klient po prostu chce te dane!
Wyjątki powinny być enkapsulowane przed rzuceniem ich dalej. Przykładowa implementacja metody activeUsers:

public List<User> activeUsers() throws DataAccessException {
    try {
        // wyciąganie danych z bazy
    } catch (SQLException e) {
        throw new DataAccessException(e);
    }    
    return users;
}

DataAccessException ładnie enkapsuluje w sobie co się stało w metodzie activeUsers. Użytkownik repozytorium jest wolny od tej implementacji i wymiana na inne źródło danych nie pociąga za sobą daleko idących zmian w kodzie.
Jeśli to repozytorium byłoby wystawiane np. przez webservice do zdalnych klientów to implementacja może wyglądać tak:

public List<User> activeUsers() throws DataAccessException {
    try {
        // wyciąganie danych z bazy
    } catch (SQLException e) {
        logger.error(e);
        throw new DataAccessException("Error during data fetching");
    }    
    return users;
}

W takim wypadku klient nie ma zupełnie wiedzy o tym czego używamy do przechowywania danych, a my nie tracimy informacji o błędzie.

Nie zwracaj nulla!

noreply@blogger.com (Anonymous) — Tue, 30 Oct 2012 19:00:00 +0000

Po raz kolejny siedzę w czyimś kodzie w którym co chwilą jest if:

public List <User> usersList() {
    List<Object[]> users = db.query("SELECT id, name, email FROM users");
    if (users == null);
        return null;
    //...
    // mapowanie na obiekty i zwrot wyników

I dalej gdzieś w serwisie czy czymś:

List<User> users = usersRepo.usersList();
if (users == null)
    return null; // i zabawa trwa dalej!

Takie IFy mają tendencje do ciągnięcia się przez wszystkie warstwy sięgając nawet samego widoku. Pozbycie się tego nie tylko poprawi wygląd kodu, zmniejszy złożoność, ale też ograniczy możliwość wystąpienia NullPointerException. A rozwiązanie tego jest proste - zwracać tzw. NullObject. Koncepcja prosta jak budowa cepa. W tym przypadku możemy szybko zmienić by obiekt zwracał pustą listę:

public List <User> usersList() {
    List<Object[]> users = db.query("SELECT id, name, email FROM users");
    if (users == null);
        return Collections.<User>emptyList();
    //...
    // mapowanie na obiekty i zwrot wyników

I już nie trzeba się bać o NPE i kod robi to co powinien (czyli zwrócić _listę_). Ciekawszym przykładem będzie, gdy zaczniemy mieć różne implementacje jakieś funkcjonalności. Np. gdy mamy odpowiednią klasę odpowiedzialną za kolorowanie obramowania, ale czasami nie musimy go kolorować. Najpierw wersja 'brzydka':

public interface BorderPainter {
    void paint(Element element);
}

public class BorderPainterFactory {
    public static BorderFactory get(BorderType type) {
        switch (type) {
            case BOLDED:
                return new BoldetBorderPainter();
            case DOTTED:
                return new DottedBorderPainter();
            case NONE:
                return null;
        }
    }
}

// i użycie
BorderPainter painter = BorderFactory.get(type);
// albo gorsze - sprawdzać czy type jest typu NONE przed wywołaniem factorki
if (painter != null) { 
    painter.paint(someElement);
}

A lepiej sobie wprowadzić implementację BorderPainter która najzwyczajniej w świecie nic nie robi :)

public NoBorderPainter implements BorderPainter {
    public void paint(Element element) {}
}
// i wywołanie jest zawsze takie samo:
BorderPainter painter = BorderFactory.get(type);
painter.paint(someElement);

Takie podejście jest dużo bardziej object oriented, zmniejsza złożoność, zwiększa elastyczność, czytelność, stabilność i testowalność kodu. Oczywiście nie zawsze jest to możliwe, by takowy NullObject skontruować i wprowadzić. Ale z doświadczenia widzę, że około 90% takich konstrukcji może zostać zrefaktoryzowanych.

Piękna prezentacja na temat usuwania IFów z kodu autorstwa Misko Heverego (co mocno rozszerza mój wątek o null objectach) można zobaczyć poniżej. POLECAM!

GeeCON 2012 [Film:]

noreply@blogger.com (Anonymous) — Mon, 26 Mar 2012 18:42:00 +0000

Czwarta edycja GeeCONa zbliża się wielkimi krokami! Dla tych co jeszcze nie wiedzą odbędzie się w pomiędzy 16 a 18 Maja w Poznaniu.

Dzisiaj na twitterze szumu narobił nowy film promocyjny podsumowujący zeszłoroczną edycję:

The laws of GeeCON

Jak widać warto tam być! W tym roku wśród gwiazd konferencji znajdą się:

Bruce Eckel
Gavin King
Ivar Jacobson
Adam Bien
Kevlin Henney
Pete Muir

a z polskich znanych twarzy:

Jacek Laskowski
Dawid Weiss
Tomek Kaczanowski
Piotr Walczyszyn

i inni .. ;-)

Schedule jest już znany, więc można powoli planować ścieżkę prezentacji podczas konferencji.

Jak ktoś już się zapisał to można sobie na bloga wrzucić ładnego bannerka :-)

Do zobaczenia!

Poznań JUG - Warsztaty z języka Scala

noreply@blogger.com (WooKasZ) — Fri, 01 Jul 2011 06:52:00 +0000

Dzięki uprzejmości Grzegorza Balcerka, który zgłosił pomysł oraz siebie jako ochotnika do poprowadzenia warsztatów, mam przyjemność zaprosić wszystkich na otwarte warsztaty z języka Scala!

Scala ostatnio robi się dość popularna, więc warto przyjść i "liznąć" trochę z tego języka. Bez przedłużania dane szczegółowe:

Data: 09.07.2011 (sobota)

Godzina: 10:00

Miejsce: Siedziba Cognifide (uwaga zmiana adresu!) ul. Murawa 12-18

Rejestracja: tutaj (wymagana, liczba miejsc ograniczona!)

Wymagane jest posiadanie własnego laptopa (prosimy zabrać listwy zasilające;) z JDK 6.

Opis warsztatów nadesłany od autora:

Zakres: od podstaw do .... - nie wiem, zależy na ile czas
pozwoli.Poniżej kolejne tematy które mogłyby być omawiane, ale nie
wydaje mi się żeby było możliwe omówienie wszystkiego - ze względów
czasowych: wprowadzenie, podstawy składni, podstawowe typy danych,
wyrażenia sterujące, klasy, cechy, metody, obiekty, typy ogólne,
standardowe typy ogólne, funkcje, dopasowywanie wzorców, klasy i
obiekty przypadków, pakiety, klauzule importu, uprawnienia, wyjątki i
wyrażenie return, modyfikator implicit, kolekcje, pętla for, XML,
programowanie interfejsów graficznych, programowanie współbieżne,
parsowanie, adnotacje, języki dostosowane do dziedziny, kompilator

Przewidziana jest przerwa obiadowa z pizzą i napojami :-)

Zapraszam!

(Prawdopodobnie ostatnie) Podsumowanie nowości w Java 7

noreply@blogger.com (WooKasZ) — Fri, 24 Jun 2011 21:50:00 +0000

Wpisów na temat rzeczy, które mają się pojawić w Java 7 już kilka u mnie powstało (3). Ale ten chyba będzie ostatnim, bo termin wydania jest już znany i bliski - 28 lipca 2011! Z tej okazji postanowiłem przejrzeć ten brzydki dokument JSR 336.

Żeby nie zanudzać i nie rozwodzić się za bardzo (większość rzeczy już jak wspomniałem opisałem), lista zwycięzców tej długiej bitwy:

Bytecode
Lepsze wsparcie dla języków dynamicznych opartych na JVM - dodanie instrukcji invokedynamic.

Java Beans
Tutaj głównie poprawki w API. Dodano adnotację @Transient i oznaczono nią trochę getterów, poza tym poprawki w API ;-)

Kolekcje
Tutaj podobnie dodatki w API. Głównie chwalą się dodaniem metod Collections.emptyIterator() oraz Collections.emptyEnumeration() oraz zaktualizowaniem dokumentacji.

I/O
Nowe IO! NIO.2 opisane w JSR 203 :-) Wsparcie dla POSIX i ACL, nowy pakiet java.nio.file zawierający stuff do obsługi metadanych, dowiązań, ułatwienia przeglądania katalogów (interface FileVisitor) i jeszcze trochę tego, ale za bardzo się nie zagłębiałem akurat w ten temat.

java.lang
Tutaj tzw. project coin (JSR 334) z zestawem kilku zmian do samego języka: switch po stringu, blok try dla zasobów wymagających zamykania, multi-catch, rozszerzona składnia dla liczb, dedukcja typów (dla generyków). Poza tym wiadomo dodatki/usprawnienia w API (w tym już chyba sławny java.util.Objects z metodami do porównywania obiektów, obliczania hashcode itp.).

Class loader
Wsparcie dla współbieżnych class loaderów! :-)

Współbieżność
Dodano nowy framework ForkJoin przeznaczony dla aplikacji z intensywnymi obliczeniami. Posiada dobre wsparcie dla maszyn wieloprocesorowych i jest niezależny od platformy. + dodatki w standardowym API.

I18N
Wsparcie dla Unicode 6.0.0

To były główne zmiany, poza tym różnorakie zmiany w: java.util.logging, java.util.regex, java.net, JMX, java.util.zip, bezpieczeństwie (obsługa TLS 1.2) oraz dodatki do Swinga i AWT.

Jak widać ostatecznie domknięcia nie zmieściły się w wersji finalnej. To samo tyczy się projektu Jigsaw czyli modularyzacji JDK (co mnie bardzo zdziwiło, bo myślałem, że to pewniak). Jestem z tego powodu bardzo zawiedziony, bo to dla mnie były właśnie te killing-features, które wprowadziłyby nowy blask językowi.

No cóż... z nadzieją musimy obserwować rozwój specyfikacji Javy 8... :-/

Pierwszy Job z Hadoop

noreply@blogger.com (WooKasZ) — Sun, 19 Jun 2011 10:40:00 +0000

Zanim napiszemy pierwszego joba trzeba przygotować sobie środowisko. Obsługa wszystkiego z konsoli może z czasem być nużąca (chociaż ja tam lubię;).

Ja do dewelopmentu używam NetBeansa i polecam wtyczkę Karmaspehere Community Edition. Pozwala ona w łatwy sposób definiować i odpalać sobie zadania Hadoopa.
Aby zainstalować tę wtyczkę należy dodać do listy 'update sites' adres: http://hadoopstudio.org/updates/updates.xml. Ja zainstalowałem wszystkie 4 dostępne pluginy od Karmasphere. Polecam też się zarejestrować i aktywować plugin, bo będą się pojawiać komunikaty o aktywacji (ale chyba można pracować bez niej).

Ok, możemy zacząć pisać :-) Projekt oparłem o maven, pom.xml nie jest zbyt rozdbudowany:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>pl.lstachowiak</groupId>
    <artifactId>HadoopSamples</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>HadoopSamples</name>
    <url>http://blog.lstachowiak.pl</url>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8</version>
            <scope>test</scope>
        </dependency>
        
        <dependency>
            <groupId>org.apache.mahout.hadoop</groupId>
            <artifactId>hadoop-core</artifactId>
            <version>0.20.1</version>
        </dependency>
        <dependency>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
            <version>1.1.1</version>
        </dependency>
    </dependencies>
</project>

Problem jaki wybrałem dla pierwszego przykładu to analiza statystyk serwera Apache. Bierzemy plik access.log i analizujemy typy żądań do serwera. Na końcu chcemy mieć liczbę żądań każdego typu.
Mój pomysł na Map i Reduce jest następujący:

Czyli:
- Hadoop wczytuje i dzieli plik na tzw 'input splits'
- przekazuje każdy split do funkcji map, gdzie kluczem jest numer linii w pliku a wartością sama linia
- implementowana przez nas funkcja map sprawdza jaki tym żądania HTTP znajduje się w linii i zwraca jako klucz typ żądania a jako wartość liczbę 1 (umownie sobie tak robimy)
- Hadoop wykonuje tzw. shuffle grupując nam wyniki z map w pary [TYP] -> [KOLEKCJA JEDYNEK]
- nasza funkcja reduce jedyne co robi to zlicza liczbę elementów w kolekcji i zwraca jako klucz typ żądania a jako wartość liczbę elementów w kolekcji co jest zarazem wynikiem końcowym
- Hadoop zapisuje dane na dysk

(Bardzo) Możliwe, że nie jest to idealne rozwiązanie, ale nie mam jeszcze wielkiego doświadczenia z Hadoop ;)

Przejdźmy do implementacji. Funkcja map:
HttpMethodMapper.java:

package pl.lstachowiak.hadoop.sample1;

import java.io.IOException;
import org.apache.hadoop.io.IntWritable;
import org.apache.hadoop.io.LongWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Mapper;


public class HttpMethodMapper extends Mapper<LongWritable, Text, Text, IntWritable> { // 1

    @Override
    public void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException {
        HttpMethod method = getMethodFromLine(value); // 2
        context.write(new Text(method.name()), new IntWritable(1)); // 3
    }

    HttpMethod getMethodFromLine(Text value) {

        if (value.find(HttpMethod.CONNECT.name()) != -1) {
            return HttpMethod.CONNECT;
        }

        if (value.find(HttpMethod.DELETE.name()) != -1) {
            return HttpMethod.DELETE;
        }

        if (value.find(HttpMethod.GET.name()) != -1) {
            return HttpMethod.GET;
        }

        if (value.find(HttpMethod.HEAD.name()) != -1) {
            return HttpMethod.HEAD;
        }

        if (value.find(HttpMethod.OPTIONS.name()) != -1) {
            return HttpMethod.OPTIONS;
        }

        if (value.find(HttpMethod.PATH.name()) != -1) {
            return HttpMethod.PATH;
        }

        if (value.find(HttpMethod.POST.name()) != -1) {
            return HttpMethod.POST;
        }

        if (value.find(HttpMethod.PUT.name()) != -1) {
            return HttpMethod.PUT;
        }

        if (value.find(HttpMethod.TRACE.name()) != -1) {
            return HttpMethod.TRACE;
        }

        return HttpMethod.UNKNOWN;
    }
}

Krótki komentarz do tego co się dzieje w kodzie:
1 - klasa mappera musi (od wersji API 0.20) rozszerzać klasę Mapper. Parametrami są kolejno:
- typ klucza (numer linii)
- typ wartości (linia w pliku)
- typ klucza wynikowego (typ żądania http)
- typ wartości wynikowe (liczba 1)
2 - pobranie typu żądania z linii, wiem, że rozwiązanie jest dalekie od idealnego, ale nie o to chodzi w przykładzie ;)
3 - zapis wyniku

Jak widać Hadoop posiada własny zestaw typów danych. W większości są to obudowane typy podstawowe. Stworzone zostały one aby w troszkę lepszy sposób serializować dane i przesyłać przez sieć. Zaleca się ich używanie. Typ HttpRequest to zwykły enum z listą dostępnych typów żądań HTTP. Dostępny jest w źródłach.

Funkcja reduce:
HttpMethodReducer.java:

package pl.lstachowiak.hadoop.sample1;

import java.io.IOException;
import org.apache.hadoop.io.IntWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Reducer;
import org.apache.hadoop.mapreduce.Reducer.Context;


public class HttpMethodReducer extends Reducer<Text, IntWritable, Text, IntWritable> { // 1

    @Override
    protected void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException { // 2
        int counter = countValues(values); // 3
        context.write(key, new IntWritable(counter)); // 4
    }
    
    <T> int countValues(Iterable<T> values) {
        int counter = 0;
        for (T value : values) {
            counter++;
        }
        
        return counter;
    }
}

Ponownie krótki komentarz:
1 - musimy rozszerzać klasę Reducer, parametry kolejno to:
- typ klucza z Map
- typ wartości z Map
- typ klucza wynikowego
- typ wartości wynikowej
2 - tutaj widać efekt działania operacji shuffle. Zamiast otrzymywać tą jedynkę z funkcji Map otrzymujemy iterator po kolekcji jedynek (w naszym przykładzie).
3 - zliczamy elementy
4 - zapisujemy w wynikach :-)

No to jeszcze program do uruchomienia zadania:
HttpMethodJob.java:

package pl.lstachowiak.hadoop.sample1;

import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IntWritable;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Job;
import org.apache.hadoop.mapreduce.lib.input.FileInputFormat;
import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;


public class HttpMethodJob {
    
    public static void main(String[] args) throws Exception {
        
        if (args.length != 2) {
            System.err.println("Usage: HttpMethodJob <input path> <output path>");
            System.exit(-1);
        }
        
        Job job = new Job();
        job.setJarByClass(HttpMethodJob.class); // 1
        
        FileInputFormat.addInputPath(job, new Path(args[0])); // 2
        FileOutputFormat.setOutputPath(job, new Path(args[1])); // 3
        
        job.setMapperClass(HttpMethodMapper.class); // 4
        job.setReducerClass(HttpMethodReducer.class); // 5
        
        job.setOutputKeyClass(Text.class); // 6
        job.setOutputValueClass(IntWritable.class); // 7
        
        System.exit(job.waitForCompletion(true) ? 0 : 1); // gogogo!
        
    }
}

1 - tworzymy zadanie i podajemy klasę główna
2,3 - podajemy źródło danych oraz miejsce zapisu danych wynikowych (wczytywane z argumentów)
4,5 - podajemy klasę mappera i reducera
6,7 - konfiguracja typów danych wynikowych
I uruchomienie zadania :-)

Zanim jednak zaczniemy potrzebne są jeszcze jakieś dane do analizy. Ja wygooglałem coś tutaj (4,3MB).

Uruchomienie

Tutaj obrazkowo:) Przechodzimy do zakładki Services (NetBeans) -> Servers -> Hadoop Jobs -> New Job. Wybieramy nazwę dla Joba i typ 'Hadoop Job from pre-existing JAR file'.

Następnie wpisujemy ścieżkę do JARa (ja podałem z targeta) oraz klasę z funkcją main.

W następnym oknie wybieramy klaster dla wersji 0.20 oraz wpisujemy argumenty dla zadania. Kolejno plik access.log oraz katalog w którym mają być składowane wyniki końcowe.

I klikamy 'finish' :-)

Teraz możemy odpalać!

Prawy guzik na nowego Joba -> Run Job -> Run.

Wszystko powinno pójść dobrze, stan konsoli na końcu (statystyki):

11/06/19 11:53:26 INFO mapred.JobClient: Job complete: job_local_0001
11/06/19 11:53:26 INFO mapred.JobClient: Counters: 12
11/06/19 11:53:26 INFO mapred.JobClient:   FileSystemCounters
11/06/19 11:53:26 INFO mapred.JobClient:     FILE_BYTES_READ=18153346
11/06/19 11:53:26 INFO mapred.JobClient:     FILE_BYTES_WRITTEN=9462349
11/06/19 11:53:26 INFO mapred.JobClient:   Map-Reduce Framework
11/06/19 11:53:26 INFO mapred.JobClient:     Reduce input groups=4
11/06/19 11:53:26 INFO mapred.JobClient:     Combine output records=0
11/06/19 11:53:26 INFO mapred.JobClient:     Map input records=17484
11/06/19 11:53:26 INFO mapred.JobClient:     Reduce shuffle bytes=0
11/06/19 11:53:26 INFO mapred.JobClient:     Reduce output records=4
11/06/19 11:53:26 INFO mapred.JobClient:     Spilled Records=34968
11/06/19 11:53:26 INFO mapred.JobClient:     Map output bytes=142014
11/06/19 11:53:26 INFO mapred.JobClient:     Combine input records=0
11/06/19 11:53:26 INFO mapred.JobClient:     Map output records=17484
11/06/19 11:53:26 INFO mapred.JobClient:     Reduce input records=17484

W katalogu wynikowym powinien znajdować się także plik part-r-00000 z zawartością:

GET 15341
HEAD 1744
POST 398
PUT 1

I mamy gotowe statystyki :-)
Pełne źródła dostępne są tutaj.

Wideo z Poznańskiego Code Retreat

noreply@blogger.com (WooKasZ) — Sat, 18 Jun 2011 14:37:00 +0000

Trochę czasu minęło od pierwszego Poznańskiego Code Retreat, ale parę dni temu pojawił się w sieci krótki filmik z tej imprezy. Wg mnie jest świetny :) Dynamiczny i nawet gdzieś tam mnie widać! Brawa dla autora, którym jest Zbigniew Wantuch!

Zapraszam do obejrzenia:

Źródło: Poznań JUG

Szybka instalacja Apache Hadoop dzięki dystrybucji Cloudera

noreply@blogger.com (WooKasZ) — Wed, 15 Jun 2011 19:14:00 +0000

Mając w pamięci trudne doświadczenia z czasów studiów z frameworkiem Hadoop, postanowiłem wrócić do tematu dzięki prezentacji Eugiene Ciurana podczas tegorocznego GeeCONa. Eugienie opowiedział trochę o firmie Cloudera która odwaliła kawał dobrej roboty tworząc i udostępniając dla wszystkich łatwą w instalacji dystrybucję Hadoopa.

Oto jak w szybko zainstalować i uruchomić Hadoop na Ubuntu 11.04:

1. Dodanie nowego repozytorium

sudo touch /etc/apt/sources.list.d/cloudera.list

I dopisać do zawartości:

deb http://archive.cloudera.com/debian lucid-cdh3 contrib
deb-src http://archive.cloudera.com/debian lucid-cdh3 contrib

(Nie ma jeszcze dostępnej wersji dedykowane dla Natty :-/)

2. Instalacja!

sudo apt-get update
apt-cache search hadoop
sudo apt-get install hadoop-0.20

3. Odpalamy przykład :-)

hadoop jar /usr/lib/hadoop-0.20/hadoop-examples.jar pi 10 100

Jeśli wszystko przebiegło poprawnie na końcu powinniśmy otrzymać coś takiego w konsoli:

11/06/15 21:09:07 INFO mapred.JobClient: Job complete: job_local_0001
11/06/15 21:09:07 INFO mapred.JobClient: Counters: 14
11/06/15 21:09:07 INFO mapred.JobClient:   FileSystemCounters
11/06/15 21:09:07 INFO mapred.JobClient:     FILE_BYTES_READ=1642249
11/06/15 21:09:07 INFO mapred.JobClient:     FILE_BYTES_WRITTEN=2108417
11/06/15 21:09:07 INFO mapred.JobClient:   Map-Reduce Framework
11/06/15 21:09:07 INFO mapred.JobClient:     Reduce input groups=2
11/06/15 21:09:07 INFO mapred.JobClient:     Combine output records=0
11/06/15 21:09:07 INFO mapred.JobClient:     Map input records=10
11/06/15 21:09:07 INFO mapred.JobClient:     Reduce shuffle bytes=0
11/06/15 21:09:07 INFO mapred.JobClient:     Reduce output records=0
11/06/15 21:09:07 INFO mapred.JobClient:     Spilled Records=40
11/06/15 21:09:07 INFO mapred.JobClient:     Map output bytes=180
11/06/15 21:09:07 INFO mapred.JobClient:     Map input bytes=240
11/06/15 21:09:07 INFO mapred.JobClient:     Combine input records=0
11/06/15 21:09:07 INFO mapred.JobClient:     Map output records=20
11/06/15 21:09:07 INFO mapred.JobClient:     SPLIT_RAW_BYTES=1110
11/06/15 21:09:07 INFO mapred.JobClient:     Reduce input records=20
Job Finished in 2.361 seconds
Estimated value of Pi is 3.14800000000000000000

Oczywiście uruchomiony Hadoop działa w trybie standalone, który idealnie będzie się dla nas nadawać do deweloperskiej zabawy ;-)
W następnym odcinku trochę pokodzimy!

Eclipse DemoCamp Indigo 2011 - Poznań [02.06.2011]

noreply@blogger.com (WooKasZ) — Wed, 25 May 2011 21:01:00 +0000

Za tydzień w Poznaniu kolejne spotkanie z cyklu Eclipse DemoCamp! Tym razem świętujemy wydanie wersji Indigo.
Jak zwykle impreza oprócz charakteru naukowego (prezentacje) będzie miała także aspekt społeczny (dyskusje, piwo i pizza). Co najlepsze dzięki sponsorom piwo i pizza będzie dla uczestników darmowe! Poza tym przewidywane jest do wygrania trochę gadżetów.
...chyba na tym mógłbym już zakończyć tego newsa, bo już wystarczająco zachęciłem do przyjścia ;)

Poniżej plakat promujący wraz z agendą:

Miejsce i czas:
2 czerwca (czwartek) 2011
Pub Brogans, ul. Szewska 20a, Poznań
Start godzina 18:00

Linki:
Szczegóły: link
Rejestracja: link

Do zobaczenia!

Caching Abstract w Spring Framework 3.1 M1

noreply@blogger.com (WooKasZ) — Wed, 23 Feb 2011 21:40:00 +0000

Po krótkiej przerwie wracamy do pisania ;)
Przyszło mi pójść do pracy i trochę blog się zakurzył, ale mam zamiar go systematycznie przecierać ściereczką, żeby raz na jakiś czas coś dało się przeczytać.

Całkiem niedawno SpringSource wydał milestone pierwszy nowego Springa 3.1. Przeglądając listę zmian napotkałem zupełnie nowy komponent służący do cachowania. Caching Abstract - bo tak został nazwany, jest warstwą abstrakcji (samym API) wspierającym programistę podczas cachowania pobieranych danych z dowolnych źródeł. Z techniczego punktu widzenia (na tę chwilę) zostały wprowadzone dwie nowe adnotacje: @Cacheable oraz @CacheEvict.

Za pomocją @Cacheable adnotujemy metody których zwracane wartości mają trafiać do cache:

@Cacheable("something")
public List<Object> getMeSomething(String param) {
 // ...
}

Jako parametr podajemy nazwę cache do którego mają trafić wyniki. Kluczem dla zapamiętywanych wyników staje się parametr metody. Jeśli metoda posiada kilka parametrów lub przyjmuje jako taki np jakieś DTO, można wyspecyfikować klucz za pomocą atrybutów,przykłady:

@Cacheable(value="magic", key="magicDto.id")
public List<Object> getSomethingMore(MagicDto magicDto) {
 // ..
}

Dla wielu parametrów:

@Cacheable(value="magic", key="param2")
public List&ls;Object> getSomething(String param1, int param2, boolean param3) {
 // ..
}

Możliwe jest także wykorzystanie dowolnej metody do wyliczenia klucza:

@Cacheable(value="magic", key="T(myKeyGenerator).getKey(param2)")
public List&ls;Object> getSomething(String param1, int param2, boolean param3) {
 // ..
}

Domyślnie Spring korzysta z metody hashCode dla wygenerowania klucza z podanej wartości. Można to zmienić podmieniając implementację klasy org.springframework.cache.KeyGenerator (więcej w dokumentacji).

Za pomocą atrybutu condition można zdefiniować warunek, kiedy wyniki mają zostać cachowane:

@Cacheable(value="something", condition="param.length > 1024")
public List<Object> getSomething(String param) {
 return Collections.emptyList();
}

Jako wartość można wstawić dla niego dowolne wyrażenie w SpEL które zwróci wartość boolowską.

Jak już uzbieramy trochę obiektów to możemy się ich pozbyć za pomocą @CacheEvict.

@CacheEvict(value="magicCache", allEntries=true)
public void clearMyCache(int param1) {
        //...
}

Jako value podajemy cache (lub ich wiele) z którego mają zostać usunięte obiekty. Parametr allEntries jest opcjonalny i służy do usuwania wszystkich przechowywanych obiektów. Jeśli nie zostanie użyty obiekty będą usuwane wg klucza, zasady podobne jak w przypadku @Cacheable.

Tyle szybko jeśli chodzi o API. Aby zacząć go używać trzeba jeszcze zrobić mały update konfiguracji o następującą treść:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:cache="http://www.springframework.org/schema/cache"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
   http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd">

   <cache:annotation-driven />

</beans>

Domyślnie w Springa wbudowana jest obsługa dwóch "fizycznych" cache: ConcurrentMap oraz ehcache. Jęsli ktoś używa/potrzebuje czegoś innego musi jak na razie pokusić się o napisanie własnej implementacji.
Aby skorzystać z ehcache we własnej aplikacji trzeba dopisać jeszcze dwie linie:

<!-- konfiguracja springowego CacheManagera -->
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhcacheCacheManager" p:cache-manager="ehcache"/>
<!-- konfiguracja ehcache -->
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:config-location="ehcache.xml"/>

Fajnie, że nareszcie tego typu komponent trafił do Springa. Możliwe będzie cachowanie dowolnych wartości niezależnie czy pobieramy jest przez WebService, bazę danych, z pliku czy czegokolwiek. Posługując się tylko API jednej biblioteki! Nie powinno być także żadnych kolizji jeśli chodzi o cache drugiego poziomu JPA. W tej wersji brakuje mi jeszcze jakiejkolwiek konfiguracji. Nie można (przynajmniej nie znalazłem nigdzie w dokumentacji ani w API) zdefiniować czasu życia dla obiektów w cache co jest kwestią dość podstawową. Ale poczekam jeszcze na wersję finalną....

Oracle Coherence - tworzenie klastra

noreply@blogger.com (WooKasZ) — Mon, 27 Sep 2010 21:51:00 +0000

Żeby w pełni wykorzystać możliwości jakie daje Coherence trzeba utworzyć klaster składający się z wielu węzłów. Mogą być one uruchamiane na jednej maszynie lub wielu - zależnie od potrzeb i możliwości sprzętowych.

Zanim przejdę do tego w jaki sposób jest tworzony klaster przypomnijmy sobie co jest wyświetlane podczas uruchamiania węzła w konsoli:

W pierwszej kolejności konsola wyrzuca informację o używanej wersji Coherence. Później trochę informacji o przyłączaniu węzła do klastra (pierwszy uruchamiany węzeł wyświetla tam informację o tworzonym przez niego klastrze).
Krótka sekcja Group jest bardzo ważna ponieważ zawiera adres multicastowy, port oraz wartość TTL. Coherence podczas uruchamiania węzła używa tych parametrów aby nawiązać komunikację z innymi uruchomionymi węzłami. Jeśli z jakimś nawiąże komunikację (oraz nie będzie innych konfiguracyjnych problemów) przyłączy się do jego klastra. Adres multicastowy jest ściśle związany z wersją Coherence. W moim przypadku wersją jest 3.6.0, więc adresem jest 224.3.6.0, dla 3.5.1 będzie to 224.3.5.1. Podobny mechanizm zastosowany został także co do numeru portu, tylko tam wykorzystywany jest numer builda. Taka numeracja została użyta aby zapobiec łączeniu węzłów obsługiwanych przez różne wersje Coherence.
Sekcja MasterMemberSet zawiera dane o wszystkich węzłach przyłączonych do klastra. W pierwszej kolejności wypisany jest aktualny węzeł oraz węzeł najstarszy (ten który najdłużej znajduje się w klastrze). Następnie wymienione są wszyscy członkowie wraz z adresami sieciowymi i portami na których działają.

Jeśli występuje jakiś problem podczas uruchamiania węzła, to najczęściej jest to problem z mutlicastem. W katalogi /bin/ instalacji jest dostępny skrypt multicast-test umożliwiający przetestowanie czy mechanizm ten działa prawidłowo na Twojej maszynie.
Aby uruchomić test tak aby sprawdził działanie na pojedynczej maszynie (najczęstsza konfiguracja podczas tworzenia oprogramowania) można uruchomić skrypt z parametrem -ttl 0:
mutlicast-test -ttl 0
Konsola w odpowiedzi zwróci nam jeśli wszystko jest ok:

Jeśli coś jest nie tak to powinno się sprawdzić konfigurację firewalla oraz inne ustawienia sieciowe.

Domyślnie użycie multicastu do odnajdywania innych węzłów może zostać zastąpione poprzez skonfigurowanie konkretnych adresów IP serwerów (w terminologii Coherence: Well Known Addressess - WKA). Dla ograniczenia klastra tylko do maszyny lokalnej należy w skrypcie cache-server dodać wpis dla parametrów JAVA_OPTS:
-Dtangosol.coherence.wka=localhost
Całkowicie wyłączy to multicast, co może być bardzo pożądane w fazie produkcyjnej projektu.
Po tej operacji zamiast sekcji Group podczas uruchamiania węzła znajdować się będzie sekcja WellKnownAddressesList, np:

WellKnownAddressList(Size=1,
WKA{Address=192.168.0.2, Port=8088}
)

Kolejną kwestią podczas tworzenia klastra są porty na których działają węzły. Domyślnie pierwszy węzeł uruchamiany jest na porcie 8088 i jest on zwiększany o 1 dla każdego kolejnego węzła na tej samej maszynie. Jeśli jakaś inna aplikacja zajmuje już dany port możliwe jest skonfigurowanie Coherence aby użył innego numeru jako początkowy poprzez parametr:

-Dtangosol.coherence.localport=[numer portu]

Opcje te mogą być także konfigurowane za pomocą pliku XML, ale o tym już w jednym z następnych odcinków ;-)

Oracle Coherence - działający przykład

noreply@blogger.com (WooKasZ) — Sat, 11 Sep 2010 17:46:00 +0000

Po krótkim wstępie do Oracle Coherence, czas uruchomić prosty przykład z użyciem Javy. Coherence jest dość duży i wymagane jest wprowadzenie w wiele rzeczy zanim będzie można go sprawnie używać, jednak mam nadzieje, że uda mi się wszystko opisać w miarę kolejnych wpisów. Jak na razie zróbmy sobie prosty przykład bez używania konsoli ;-)

Projekt Javy można utworzyć w dowolnym IDE.Ważne tylko aby dodać do niego bibliotekę coherence.jar z paczki pobranej ze strony Oracle.
Zacznijmy od stworzenia klasy która będzie przechowywana w klastrze Coherence. Niech to będzie wałkowany wszędzie pracownik.
Employee.java:

package pl.lstachowiak.coherence.example1;

import java.io.Serializable;
import java.math.BigDecimal;

public class Employee implements Serializable, Comparable {

 private int id;
 private String name;
 private String surname;
 private BigDecimal salary;
 private String city;

 public Employee() {
 }

 public Employee(int id, String name, String surname,
     BigDecimal salary, String city) {
  this.id = id;
  this.name = name;
  this.surname = surname;
  this.salary = salary;
  this.city = city;
 }

 public String getCity() {
  return city;
 }

 public void setCity(String city) {
  this.city = city;
 }

 public int getId() {
  return id;
 }

 public void setId(int id) {
  this.id = id;
 }

 public String getName() {
  return name;
 }

 public void setName(String name) {
  this.name = name;
 }

 public BigDecimal getSalary() {
  return salary;
 }

 public void setSalary(BigDecimal salary) {
  this.salary = salary;
 }

 public String getSurname() {
  return surname;
 }

 public void setSurname(String surname) {
  this.surname = surname;
 }

 @Override
 public String toString() {
  return "Employee{" + "id=" + id + " name=" + name + " surname="
    + surname + " salary=" + salary + " city=" + city + '}';
 }

 public int compareTo(Object o) {
  Employee other = (Employee) o;
  if (id > other.id) {
   return 1;
  } else if (id < other.id) {
   return -1;
  } else {
   return 0;
  }
 }
}

Jak widać klasa nie różni się niczym w stosunku to standardowych klas typu POJO. Jedyne co zostało dodane to implementacja interfejsu Serializable, ponieważ obiekt będzie przesyłany przez sieć oraz Comparable, żeby było po czym sortować, gdy będzie to potrzebne.
Napomnę tutaj, że Coherence wprowadził swój własny format serializacji obiektów. Jest od bardziej wydajny, a obiekty po serializacji mniejsze. Więcej o tym w jednym z kolejnych wpisów.

Operacje na Coherence przeprowadźmy w metodzie main...
CoherenceExample1.java:

package pl.lstachowiak.coherence.example1;

import com.tangosol.net.CacheFactory;
import com.tangosol.net.NamedCache;
import java.math.BigDecimal;
import java.util.Map;
import java.util.Set;

public class CoherenceExample1 {

    public static void main(String[] args) {
  // #1
        NamedCache employees = CacheFactory.getCache("employees");

  // #2
  employees.put(1, new Employee(1, "John", "Travolta", new BigDecimal(300000.0), "New York"));
  employees.put(2, new Employee(2, "Jason", "Statham", new BigDecimal(550000.0), "Chicago"));
  employees.put(3, new Employee(3, "Sylvester", "Stalone", new BigDecimal(600000.0), "Miami"));
  employees.put(4, new Employee(4, "Bruce", "Willis", new BigDecimal(780000.0), "Los Angeles"));
  employees.put(5, new Employee(5, "Chuck", "Norris", new BigDecimal(1300000.0), "Kansas"));
  employees.put(6, new Employee(6, "Steven", "Seagal", new BigDecimal(20100.0), "Lansing"));

  // #3
  System.out.println("Pracownik o ID=1: " + employees.get(1));
  System.out.println("Rozmiar cache: " + employees.size());
  System.out.println("Usuwam: " + employees.remove(5));
  System.out.println("Rozmiar cache: " + employees.size());

  // #4
  Set<Map.Entry> entries = employees.entrySet();
  for (Map.Entry entry : entries) {
   System.out.println(entry.getKey() + ": " + entry.getValue());
  }
    }
}

#1 - pierwszym co trzeba zrobić to uzyskać referencję do Cache w którym będą przechowywane obiekty pracowników. CacheFactory odpowiada za jego stworzenie jeśli nie istnieje i zwrócenie referencji. Obiekt zwracany jest typu NamedCache, który implementuje standardowy interfejs Map z biblioteki Javy.
2# - umieszczanie elementów jest bardzo proste, zwykły put na mapie.
3# - podobnie wszystkie operacje pobierania oraz usuwania, wszystko bardzo intuicyjne
4# - można też pobrać całą listę obiektów w cache. Metoda entrySet() występuję w kilku wersjach, można jest podać także filtr oraz komparator jeśli szukamy odpowiedniego podzbioru obiektów w cache.

Po uruchomieniu powinno nam się pojawić coś podobnego do poniższego ekranu:

Chciałbym tutaj zwrócić uwagę, że nie napisałem nic o uruchamianiu węzła Coherence przed odpalaniem aplikacji. Pomimo tego wszystko działa! Jest tak ponieważ domyślnie aplikacja którą stworzyliśmy automatycznie staje się pełnoprawnym węzłem w klastrze. Często jest to niepożądane zachowanie i można tego uniknąć poprzez uruchomienie jej z parametrem:
-Dtangosol.coherence.distributed.localstorage=false
co prawda nadal aplikacja będzie pełnoprawnym węzłem w klastrze, ale nie będzie przechowywać danych;) Wymagany jest wtedy co najmniej jeden węzeł to robiący aby uniknąć wyjątków po uruchomieniu.

Oracle Coherence - zabawy z in memory data grid

noreply@blogger.com (WooKasZ) — Mon, 09 Aug 2010 19:05:00 +0000

Obiecałem tematykę o skalowalności w bardziej praktyczny sposób to czas się z tego wywiązać i zacząć pisać! Przy okazji oczywiście samemu się ucząc, bo po to głównie to miejsce powstało.

Przy okazji GeeCONa podczas University Day w wolnej chwili dosiadłem się na szkolenie Waldemara Kota o Oracle Coherence. To było moje pierwsze zetknięcie z tak zwanym in memory data grid, temat mnie zaciekawił i postanowiłem coś więcej o tym poczytać (przy okazji szkolenia dostałem książkę;)
Oracle Coherence jest (komercyjnym:-/) narzędziem które w łatwy sposób pozwala nam poprawić skalowalność, wydajność oraz dostępność aplikacji.

Umieszczane jest pomiędzy warstwą danych a aplikacją. Najczęściej między bazą danych a klastrem serwerów aplikacyjnych. Komunikacja między tymi warstwami odbywa się tylko poprzez Coherence (konfigurowalne) co w znacznym stopniu odciąża bazy danych i zwiększa czas odpowiedzi do warstwy aplikacji. Coherence przechowuje takie same obiekty jakie używane są w aplikacji, co eliminuje potrzebę ciągłego ładowania i przetwarzania danych w obiekty. Obiekty te rozprowadzane są pomiędzy węzły w klastrze co równoważy obciążenie przy czym dla aplikacji klaster pozostaje widoczny jako pojedynczy system. Zapewniona jest wysoka dostępność i odporność na błędy poprzez przechowywanie więcej niż jednej kopii danego obiektu w różnych miejscach. Co więcej, przechowywane są w pamięci co w znacznym stopniu poprawia czas dostępu do nich.
Co możemy robić z Coherence?

rozproszony cache - to chyba podstawowe zastosowanie, nie trzeba się martwić o synchronizację, w bardzo łatwy sposób można też podpiąć się pod wybrany ORM
rozproszone zapytania - dane można wyciągać nie tylko wg nadanego klucza głównego, ale także możliwe jest wykonywania zapytań na klastrze. Np wybrać klientów powyżej 35 lat, którzy dodatkową posiadają kwotę na koncie pomiędzy 4000 a 6000 PLN
współbieżne operacje i procedury składowane - podobnie jak w bazach danych możliwe jest tworzenie procedur i wykonywanie ich wewnątrz klastra, bez potrzeby przesyłania wszystkich danych do aplikacji. Co więcej możliwe jest też wykonywania operacji współbieżnie
zdarzenia - możliwe jest skonfigurowanie Coherence tak by informował i wykonywał podane operacje gdy wybrane dane zostały zmienione

Teraz możemy przejść do zabawy :)

Ze strony Oracle Coherence Download pobieramy paczkę "Oracle Coherence for Java Version 3.6.0" i rozpakowujemy gdzie nam pasuje. Następnie uruchamiamy konsolę, przechodzimy do katalogu coherence/bin i uruchamiamy skrypt cache-server. Po chwili powinien pojawić się napis "Started DefaultCacheServer..." - oznacza to, że węzeł Coherence został uruchomiony.
Ponieważ dzisiaj jest tylko takie małe wprowadzanie, nie będziemy używać Javy tylko wbudowanej konsoli, na początek starczy. Uruchamiamy skrypt coherence. Na konsoli uruchomionego wcześniej węzła powinno na końcu pojawić się coś w stylu: "2010-08-09 20:34:43.552/180.953 Oracle Coherence GE 3.6.0.0 <D5> (thread=Cluster, member=1): Member 2 joined Service Management with senior member 1". Oznacza to, że konsola podłączyła się pod węzeł.
Korzystając z Coherence należy najpierw utworzyć cache w którym będą przechowywane będą obiekty. Można tworzyć ich wiele oraz (co trochę później) konfigurować zgodnie z wymaganiami. Z konsoli utworzenie cache wykonuje się poleceniem: cache [nazwa]. Po utworzeniu jesteśmy automatycznie do niego podłączani. Co jest bardzo fajne - API korzystania z cache jest identyczne ze standardową mapą Javową. Aby coś włożyć do cache używamy put [klucz] [wartosc], aby wyciągnąć get [klucz], aby wypisać całą zawartość cache należy wpisać list. Poniżej zamieszczam bardzo prostą sesję z użyciem Coherence:

To tyle słowem wstępu. Polecam pobawić się konsolą. Uruchomić nawet więcej niż jedną oraz więcej węzłów i sprawdzić jak to działa. Polecam testy z zamykaniem kolejno węzłów i sprawdzaniem czy jakieś obiekty straciliśmy.

Więcej o tym jak Coherence działa i jak go używać w następnych odcinkach ;)

GeeCON 2011 - Kraków!

noreply@blogger.com (WooKasZ) — Thu, 08 Jul 2010 16:15:00 +0000

Na oficjalnej stronie GeeCONa pojawiła się informacja, że przyszłoroczna edycja konferencji odbędzie się w Krakowie! Wybrana data to 11 do 13 maja, więc podobny termin jak w tym i poprzednim roku.

Już teraz zapraszam serdecznie, bo znowu będzie baaaaardzo ciekawie :)

ps. to chyba pierwszy news w sieci o GeeCONie 2011 :)

JMeter - losowe wartości w żądaniach/zapytaniach

noreply@blogger.com (WooKasZ) — Sun, 13 Jun 2010 08:11:00 +0000

Często zdarza się, że chcemy wywoływać strony z parametrami które mieszczą się w jakimś przedziale liczbowym, np. productView.php?id=XXX, gdzie XXX jest zmienną. W JMeter generowanie losowych wartości jest bardzo proste.
Dodajemy do planu testów Thread Group a następnie do niego Config Elements -> HTTP Request Defaults

Wpisujemy nazwę serwera oraz port na którym nasłuchuje.
Następnie dodajemy element odpowiedzialny za generowanie losowej liczby Config Element -> Random Variable. Najważniejsze parametry jakie możemy dla niego ustawić to:
Name: nazwa elementu w drzewku
Variable name: nazwa po której będziemy się odwoływać do tej zmiennej
Output format: format w jakim ma być zwracana wartość. Można wpisać np. PROD_ID_000 wtedy będziemy otrzymywać wartości typu PROD_ID_435. Gdy pozostawi się to pole puste to będzie zwracana tylko liczba.
Minimum Value i Maximum Value jest chyba oczywiste
Per Thread(User)?: czy ten generator liczb ma być współdzielony między wszystkie wątki czy dla każdego utworzony osobny

Użycie jest bardzo proste. Wystarczy utworzyć nowe żądanie Sampler -> HTTP Request i odwołać się do losowej zmiennej poprzez ${[Nazwa zmiennej]}.

Dla podanego na obrazku przykładu będą wywoływane adresy localhost/jmeter/index.php?id=XXX, gdzie XXX jest zmienną losową.
Podobnie może ta zmienna być użyta w zapytaniach do bazy danych:

I w wielu innych miejscach gdzie potrzebna jest losowa wartość ;)

O skalowaniu baz danych słów kilka

noreply@blogger.com (WooKasZ) — Mon, 31 May 2010 15:31:00 +0000

Część druga o skalowalności. Dzisiaj trochę o bazach danych które sprawiają zawsze najwięcej problemów.

Ze względu na naturę baz danych, to co najbardziej obrywa na serwerze to dyski. Wszelkie zmiany muszą być jak najszybciej utrwalane żeby można było zwolnić blokady i zapewnić trwałość danych. Obojętnie jaki wypas serwer by się nie posiadało i tak w końcu dojdzie do tego, że nie będzie już posiadał możliwości by przyjąć więcej obciążenia, a nas nie będzie stać na zakup lepszego. Trzeba będzie się przeskalować w poziomie co jest trochę hardcorowe :)

Podejść jest kilka i chciałem omówić 3 najważniejsze z nich.

1. Master-Slave replication
W tym podejściu mamy jeden węzeł typu master oraz jeden lub więcej węzłów typu slave. Zadaniem węzła master jest tylko i wyłącznie przyjmowanie operacji modyfikacji danych. Ten serwer odpowiada za wszystkie zapytania typu INSERT, UPDATE i DELETE. Jest do tego specjalnie skonfigurowany by operacje te były jak najszybciej wykonywane. Węzły typu slave natomiast odpowiadają za wykonywanie zapytań typu SELECT. Może być ich kilka oczywiście. Aktualizują swoje dane poprzez asynchroniczną komunikację z węzłem master. Co określony czas przesyła on zgrupowane zapytania aktualizujące dane na węzłach slave.
Problemy związane z master-slave replication to:

na dobrą sprawę to nie ma tutaj skalowania poziomego. Co prawda mamy więcej węzłów, ale ciągle istnieje tylko jeden master, który może stać się wąskim gardłem, gdy liczba modyfikacji które musi wykonać przekroczy jego możliwości
synchronizacja aktualizowanych danych może powodować błędy. Jeśli klient coś zmodyfikuje i natychmiast to będzie chciał odczytać to może otrzymać błędne dane. To jednak można obejść stosując cache z polityką write-through
wymagana jest modyfikacja logiki aplikacji aby kierować SELECTy do slave, a modyfikacje do master

Podejście jest bardzo dobre, gdy mamy mało modyfikacji i dużo zapytań.

2. Database clustering

Klastrowanie bazy danych polega na utworzeniu wielu instancji bazy danych współdzielących jedną wspólną pamięć trwałą. Daje to dużo większą przepustowość i nie wymaga prawie zmian w logice aplikacji.
Jednak posiada też wady:

SAN jest drogi i też ma swoje granice
wymagana jest kosztowna synchronizacja między wszystkimi węzłami (blokady itp.). Może nawet dojść do momentu, gdy dodanie nowego węzła spowolni działanie całości

3. Database sharding

Bazę danych można też podzielić na wiele mniejszych baz i tak z nich korzystać. Najpierw należy przeanalizować dokładnie sposób jej używania a później znaleźć grupy tabel które są używane razem w zapytaniach. Na tej podstawie można dzielić ją na mniejsze.
Problemy:

trzeba bardzo dobrze przemyśleć podział, każda późniejsza zmiana jest bardzo trudna do wprowadzenia
gdy jedna z mniejszych baz zacznie działać niewydajnie trzeba będzie ją znowu dzielić. Może dojść do tego, że trzeba będzie mięć np. 3 bazy danych z produktami
zapytania łączące z wielu baz są bardzo wolne
zapytania modyfikujące wymagają rozproszonych transakcji
wymaga znacznych zmian w logice aplikacji

To są tylko koncepcje, firmy w swoich produktach (tych "dużych" głównie) wprowadziły technologie, które ułatwiają skalowanie poziome. Np. w DB2 mamy Database Partitioning Feature, który jest połączeniem podejść database sharding i clustering i eliminuje kilka wad z nimi związanymi.

Problem jest jednak bardzo złożony i wymaga długich przemyśleń. Trzeba zawsze pamiętać aby wdrożone rozwiązanie spełniało wymagania ACID.

O skalowaniu aplikacji słów kilka

noreply@blogger.com (WooKasZ) — Sun, 30 May 2010 19:00:00 +0000

W niedługim czasie zamierzam trochę szerzej pisać o skalowalności, więc postanowiłem napisać kilka słów wstępnych na ten temat. Ale spokojnie, planuję bardziej o produktach i narzędziach niż teoriach jak dzisiaj;)

Żeby później nie mylić trzeba sobie zdefiniować skalowalność. Jest to taka cecha oprogramowania która charakteryzuje jego zdolności do wydajnego działania przy wzrastającym obciążeniu. Np. załóżmy, że mamy super serwis randkowy który ma 1000 użytkowników i generuje strony w 50ms. Po jakimś czasie serwis robi się popularny i przychodzi do niego kolejnych 1000 użytkowników. Byłoby dobrze jakby strony generowały się w powiedzmy w czasie 100-200ms, ale generują się w 5000ms co niestety wskazuje na jego słabą skalowalność. Oczywiście ze wzrostem obciążenia zbliżamy się do limitu jaki może uciągnąć serwer, więc decydujemy się na wymianę starego ,zasłużonego na nowy, dwa razy lepszy. To jak aplikacja będzie się spisywać na nowym serwerze też określa jej skalowalność. Jeśli nadal strony będą się generować powoli przy takim obciążeniu to znaczy, że coś skopaliśmy przy implementacji, jeśli jest znowu fajnie i 50ms to znaczy, że aplikacja daje rade;) Podsumowując skalowalność to także łatwość w rozszerzaniu aplikacji lub jej architektury celem zwiększania wydajności.

Są dwa podstawowe podejścia co do skalowania aplikacji: pionowe (scaling up) oraz poziome (scaling out).

Podejście pionowe to po prostu wymiana lub dodawanie coraz to nowszego i szybszego sprzętu. Jak 12GB RAMu to już mało to dodajemy kolejne 12. Jak procesor nie wyrabia - dodajemy drugi itd. Sprawa jest niezwykle prosta i nie wymaga od nas w większości przypadków ingerencji w aplikację. Jednak posiada wady:

koszty - zakup coraz to lepszego sprzętu odbija się na budżecie i gdy po raz kolejny przyjdzie nam wymienić serwer może się okazać, że nas na niego nie stać, lub zyski z tej wymiany mogą być znacznie mniejsze niż poniesione koszty
bariera technologiczna - nawet jeśli mamy tyle kasy, że nas stać na każdy sprzęt na rynku to i tak w końcu dojdziemy do miejsca kiedy już nie będziemy mogli kupić lepszego sprzętu, bo po prostu nie on będzie istnieć
niska odporność na awarie, jak serwer padnie to system znika z sieci

Dlatego skalowanie pionowe jest dobre do czasu, gdy wymiana sprzętu na lepszy się jeszcze opłaca, lub gdy wiemy jaka jest górna granica wydajności jaką potrzebuje aplikacja.

Podejście poziome to też dodawanie nowego sprzętu, ale tym razem powiększamy jego zbiór dodając go do sieci istniejących już maszyn działających ku dobru systemu. Gdy obciążenie rośnie to dostawiamy kolejny serwer który przejmuje część zadań. Potrzebny jest nam jakiś mechanizm równoważenia obciążenia (load balancer), który będzie rozkładać równo żądania do wszystkich serwerów.

Oczywiście to podejście też posiada swoje wady:

wyższe koszty administracji i konserwacji sprzetu
trzeba (bardzo) dobrze przemyśleć architekturę (zwłaszcza w kwestii bazy danych)
dodanie nowego węzła wcale nie musi przynieść wzrostu wydajności, możemy nawet zanotować spadek

No, ale mamy znacznie większą odporność na błędy. Jak jeden serwer padnie to mamy jeszcze kilka innych które po prostu przejmują jego ruch. Sprawa odporności na awarie to trochę inny wątek, więc może innym razem coś o tym napiszę.

Skalowanie poziome po jakimś czasie jest naturalnym krokiem przy rozwoju systemu. Przynosi lepsze rezultaty i przy dobrej architekturze może nam dać teoretycznie nieograniczoną skalowalność. Poza tym trudno sobie wyobrazić by np. Google działał na jednym serwerze :)

Dodawanie lub wymiana sprzętu to nie jedyna droga by przyspieszyć aplikację. W pierwszej kolejności powinna być wykonana dokładna analiza wszystkich komponentów czy możliwa jest ich optymalizacja. Wymaga to trochę czasu, ale przynosi rezultaty. Np. digg.com zyskał 4000%, gdy przeniósł sortowanie z bazy danych do php. Optymalizacja to niestety niekończąca się podróż :)

Zainteresowanych tematem zachęcam do zaglądania do serwisu highscalability.com, gdzie można poczytać dużo artykułów od strony praktycznej. Ja postaram się też ciągnąć temat u siebie, bo jest o czym pisać ;)

Dziwny wyjątek podczas uruchamiania skryptu JavaFX

noreply@blogger.com (WooKasZ) — Tue, 25 May 2010 09:07:00 +0000

Wczoraj w zamian za to, że nie mogłem pojawić się na Poznańskim JUGu (trochę się przeziębiłem), zabrałem się za JavaFX. Bardzo mało o tym widzę na (Polskich) blogach, więc stwierdziłem, że może coś poczytam i może coś też popiszę u siebie. Niestety pierwsze wrażenie nie było zbyt miłe :P Przyszło mi walczyć kilka godzin z wyjątkiem który wyglądał jak błąd implementacji czegoś w JavaFX.
Plan był taki aby wziąć jeden z przykładów na stronie JavaFX.com, zmodyfikować i zobaczyć co z tego wyjdzie. Jako środowiska użyłem oczywiście NetBeans IDE w wersji 6.8.
Na komputerze lokalnym mój piękny skrypt działał bez zarzutów (uruchamiałem w trybie run in browser), to samo na serwerze.... do czasu aż nie wyłączyłem NetBeans! Kiedy był wyłączony otrzymywałem w consoli javy taki wyjątek:

java.lang.NullPointerException
at sun.plugin2.applet.JNLP2Manager.initialize(Unknown Source)
at sun.plugin2.main.client.PluginMain.initManager(Unknown Source)
at sun.plugin2.main.client.PluginMain.access$300(Unknown Source)
at sun.plugin2.main.client.PluginMain$2.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Error while initializing manager: java.lang.NullPointerException, bail out

Ten problem występował także na moim laptopie i u znajomych. No to się zaczęło wielkie googlowanie i podmiany SDK/JDK na wszystkie możliwe wersje łącznie z instalacją bety NetBeans 6.9 (swoją drogą zapowiada się bardzo ciekawie!). Nic nie pomogło, nic się nie zmieniło :-/ Ostatecznie poległem i napisałem na forum NetBeans z prośbą o pomoc jakoś przed północą. Do rana nikt nie odpisał, ale dziś gdy wstałem wyjątek już był inny. Konsola zgłaszała, że brakuje pliku xxx_browser.jnlp który na 100% znajduje się zaraz obok JARa. Podejrzałem ten plik, a tam ujrzałem bardzo ładny i krótki XML:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://localhost:8082/servlet/org.netbeans.modules.javafx.project.JnlpDownloadServlet/I%3A/workspace/NetBeans/WebSiteJavaFx/dist/" href="website_browser.jnlp">
    <information>
        <title>website</title>
        <vendor>wookasz</vendor>
        <homepage href="http://localhost:8082/servlet/org.netbeans.modules.javafx.project.JnlpDownloadServlet/I%3A/workspace/NetBeans/WebSiteJavaFx/dist/"/>
        <description>website</description>
        <offline-allowed/>
    </information>
    <resources>
        <j2se version="1.5+"/>
        <extension name="JavaFX Runtime" href="http://dl.javafx.com/1.3/javafx-rt.jnlp"/>
        <jar href="website.jar" main="true"/>
    </resources>
    <applet-desc name="website" main-class="com.sun.javafx.runtime.adapter.Applet" width="700" height="500">
        <param name="MainJavaFXScript" value="pl.lstachowiak.javafx.website.WebSite"/>
    </applet-desc>
    <update check="always"/>
</jnlp>

No jak widać dwie ścieżki coś nie takie jakie powinny być. Podmieniłem na http://lstachowiak.pl i vuala! Działa!:) plik ostatecznie wygląda następująco:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://lstachowiak.pl/" href="website_browser.jnlp">
    <information>
        <title>website</title>
        <vendor>wookasz</vendor>
        <homepage href="http://lstachowiak.pl/"/>
        <description>website</description>
        <offline-allowed/>
    </information>
    <resources>
        <j2se version="1.5+"/>
        <extension name="JavaFX Runtime" href="http://dl.javafx.com/1.3/javafx-rt.jnlp"/>
        <jar href="website.jar" main="true"/>
    </resources>
    <applet-desc name="website" main-class="com.sun.javafx.runtime.adapter.Applet" width="700" height="500">
        <param name="MainJavaFXScript" value="pl.lstachowiak.javafx.website.WebSite"/>
    </applet-desc>
    <update check="always"/>
</jnlp>

Szkoda, że nigdzie nie wyczytałem wcześniej, że ten plik jest plikiem tekstowym. Z pewnością zajrzałbym tam na początku i oszczędziłoby mi to trochę czasu i nerwów.
Zapraszam na lstachowiak.pl, co prawda nie jest to dzieło sztuki, ale zawsze jakieś początki ;-)

UPDATE:
A jednak ciągle nie działa :-/ Nie rozumiem tego zupełnie. Będę rozwijać wątek jak do czegoś dojdę. Może ktoś ma jakieś sugestie ?

UPDATE2:
Dzięki bardzo Krzysztofowi Kula :) Skompilowałem za pomocą eclipsowej wtyczki i zaczęło działać.

Spotkanie Poznań JUG - Processing [24.05.2010]

noreply@blogger.com (WooKasZ) — Thu, 20 May 2010 21:16:00 +0000

Znowu info z Poznania :) Kolejne spotkanie się szykuje! W najbliższy poniedziałek posłuchamy o Processing -środowisku do tworzenia sztuki elektronicznej. Zapowiada się bardzo widowiskowo:) Oto krótkie streszczenie od prelegenta Marcina Ignaca:

Przedstawie swoje doświadczenia z pracy ze środowiskiem Processing. Prezentacje rozpoczne krótkim wyjaśnienie czym jest Processing oraz wprowadzeniem do sposobu pracy z tym środowiskiem. W dalszej części spotkania możecie się spodziewać projektów z obszarów grafiki generatywnej, przez interaktywne instalacje aż do multimedialnych projekcji w przestrzeni publicznej. Od fazy konceptualnej przez prototypowanie aż do finalnego produktu – Processing sprawdza się na każdym kroku. Opowiem również o wadach i zaletach tego narzędzia, a także jak “szkicowanie w kodzie” (sketching in software) zmieniło moje podejście do programowania.

Aby zapoznać wstępnie z tematem zapraszam na stronę prelegenta pod tag processing.org.
To mi się bardzo spodobało:

MSAFluid with motion tracking from Marcin Ignac on Vimeo.

Nie muszę już raczej nikogo namawiać aby się zjawić! ;)

Szczegóły:
Poniedziałek 24.05.2010
Siedziba Cognifide - Aleje Wielkopolskie 4, Poznań
Godzina 18:00
Na spotkanie wymagana jest rejestracja

Do zobaczenia !

ps. ostatnio u mnie czysto informacyjne, ale postaram się niedługo to nadrobić ;)

Zmiana adresu bloga na blog.lstachowiak.pl

noreply@blogger.com (WooKasZ) — Sun, 16 May 2010 20:02:00 +0000

Drobny post informacyjny. Jutro zmieniam adres bloga na blog.lstachowiak.pl Nie wiem jak to się odbije na dostępie do niego ze starego adresu (Google twierdzi, że powinno być spoko) oraz RSS (to też podobno) dlatego jeśli byłyby jakieś problemy to proszę tylko zupdatować sobie adres.

ps. testy wypadły poprawnie ;-)

Eclipse DemoCamp Helios 2010 - Poznań [10.06.2010]

noreply@blogger.com (WooKasZ) — Tue, 11 May 2010 10:49:00 +0000

Dużo się dzieje ostatnio w Poznaniu! Bardzo dużo! GeeCON, spotkanie PJUG a teraz dochodzi jeszcze Eclipse DemoCamp. Parę dni temu zaczęły się zapisy oraz Call for Papers. Jeśli pracujesz z Eclipsem i chcesz podzielić się swoimi doświadczeniami nie wahaj się tylko zgłoś jako prelegent!
Na tę chwilę zgłosiły się już 3 osoby ze swoimi tematami:

Krzysztof Daniel/IBM Eclipse Support Center, EMF supports GWT or Eclipse Extended Preferences
Krzysztof Kazmierczyk, OSGI in the cloud
Jacek Pospychała

Osoby które jeszcze nie są pewne co by mogły przedstawić jak i te co się zdecydowały muszą się dopisać do listy uczestników na wiki Eclipsa: wiki.eclipse.org/Eclipse_DemoCamps_Helios_2010/Poznan.

Impreza odbędzie się 10 czerwca na terenie Centrum Wykładowego Politechniki Poznańskiej w salach 6 i 8.
Rozpoczęcie zaplanowano na godzinę 18:00.
Pizza oczywiście będzie :)

Serdecznie zapraszam!

ps. jak tak dalej pójdzie to Poznań powalczy o miano stolicy Javowej społeczności w Polsce ;-P

Spotkanie JUGs@GeeCON [12.05.2010]

noreply@blogger.com (WooKasZ) — Sun, 09 May 2010 20:01:00 +0000

Poznań JUG w wydaniu specjalnym! Z okazji zbliżającego się GeeCONa odbędzie się spotkanie zorganizowane we współpracy z Polish Java User Group. A na nim wystąpi aż trzech prelegentów z różnych miejsc na świecie:

Geertjan Wielenga:

The NetBeans Platform is the framework that underlies the NetBeans IDE – and many other desktop applications, some of which you may have already used. The Platform saves years of development time in building any significant desktop application, by providing a modular framework that simplifies both developing and updating desktop applications. It is used by vendors as diverse as Nokia (NetACT – cellular network monitoring and management) and Boeing (engineering materials analysis), UNESCO and many others, to develop applications as diverse as photo library management, satellite network management, semiconductor testing, planning oil drilling and music composition.

The NetBeans Platform is based on pure Java and uses the Java standard Swing toolkit, making applications based on it portable – and even deliverable via Java WebStart directly via the web. This talk will provide a comprehensive overview of the NetBeans Platform, how it works, and how to get started using it.

Chris Aniszczyk:

Eclipse e4 brings a new set of technologies into the existing Eclipse platform that make Eclipse applications easier to write, more configurable by developers and integrators and easier to reuse in a variety of runtime environments.
In the end, attendees will be introduced to Eclipse e4 and learn about the future of the Eclipse platform.

Ed Burns:

Ed has developed a 50 minute audio-visual presentation recounting his experience in writing the book. This presentation includes audio clips from the programmers themselves, including subtitles for those for whom English is not their native language, together with insight to tie it all together.

Myślę, że nie muszę nikogo przekonywać do tego, że tego spotkania JUGa przegapić nie można :)

Uwaga! Wyjątkowo spotkanie odbędzie się w innym miejscu - Poznańskim Ośrodku Nauki znajdującym się na ul. Wieniawskiego 17/19, sala 312. Miejsce to zaznaczone jest na GeeCONowej mapce:

Pokaż GeeCON in Poznan na większej mapie

Godzinę rozpoczęcia zaplanowano na 18:00. Do uczestnictwa wymagana jest rejestracja pod tym adresem.
Do zobaczenia!!

GeeCON już w Poznaniu!

noreply@blogger.com (WooKasZ) — Sat, 08 May 2010 14:39:00 +0000

GeeCONowy baner już uświetnia Poznańskie Multikino, gdzie za kilka dni odbędzie się konferencja.
Rozpiska tego co, kto i gdzie dostępna jest tutaj -> geecon.org/site/schedule. Jak widać udało się nam zaprosić wiele gwiazd świata Javowego i nie tylko - nie można tego przegapić!
Jeśli jeszcze się nie zarejestrowałeś/zarejestrowałaś to zostały już ostatnie chwile! Spiesz się!
Można także zapisać się na University Day gdzie czeka kilka bardzo ciekawych szkoleń :)

Zapraszam i do zobaczenia na GeeCONie!!

GeeCON w sieci:
www: www.geecon.org
twitter: twitter.com/Geecon_news
facebook: www.facebook.com/pages/GeeCON/

Rozproszone testy wydajnościowe z użyciem Apache JMeter

noreply@blogger.com (WooKasZ) — Fri, 23 Apr 2010 14:56:00 +0000

Kolejny wpis o JMeter. Bardzo przydatne narzędzie :)
Dzisiaj chciałem pokazać jak wykonywać rozproszone testy wydajnościowe. Do tego będzie nam potrzebne kilka maszyn z kopią JMeter. Ważne by na każdej maszynie były takie same wersje aplikacji.
Moje środowisko testowe wygląda następująco: (Paint wymiata;)

Zadaniem węzła master jest uruchomienie testów na wszystkich slaveach oraz odbieraniem od nich informacji o wynikach pomiarów. Slave natomiast bombarduje cel żądaniami zdefiniowanymi i przesłanymi przez Master.
Aby uruchomić slave należy na każdej węźle uruchomić Server JMeter -> JMETER_HOME/bin/jmeter-server.bat
Tutaj należy uważać, bo z tego co zauważyłem jest wybierany losowy port a nie jakiś stały przez co mogą wystąpić problemy z firewallem. Jeśli wszystko poszło dobrze coś podobnego do tego powinno się pojawić w konsoli:

To wszystko co należy zrobić na tych węzłach. W węźle master należy otworzyć do edycji plik JMETER_HOME/bin/jmeter.properties. W linii remote_host=127.0.0.1 należy wpisać adresy serwerów slave. W moim przypadku będzie to wyglądać następująco:
remote_hosts=192.168.0.6,192.168.0.7,192.168.0.4,192.168.0.15
Po uruchomieniu JMeter w menu Run-> Remote Start -> powinna pojawić się lista serwerów które dodaliśmy. Możemy odpalać je pojedynczo lub wszystkie jednocześnie za pomocą Remote Start All. Wystarczy już tylko przygotować jakiś plan testów i odpalić. Konsola na węzłach Slave powinna nas informować o rozpoczęciu i zakończeniu testów:

W przypadku jakiś problemów polecam sprawdzić plik jmeter.log w ktalogu /bin/.

Podoba mi się to narzędzie:) Bardzo szybko i prosto można skonfigurować duże źródło ruchu dla testowanego środowiska. Jedna maszyna do zastosować domowych może spokojnie symulować ponad 2000 wirtualnych użytkowników. W zupełności mi to wystarcza dla testowanych przeze mnie projektów.
Postaram się niedługo napisać coś więcej na temat skalowalności JMeter i tego kiedy on może stać się wąskim gardłem, a nie aplikacja lub przepustowość sieci w środowisku.

Recenzja - "Wydajne witryny internetowe - Przyspieszanie działania serwisów WWW"

noreply@blogger.com (WooKasZ) — Sun, 18 Apr 2010 08:40:00 +0000

Tematyka optymalizacji oraz skalowania aplikacji WWW jest obiektem moich zainteresowań przez dłuższy już czas. Nie tylko ze względu na temat pracy magisterskiej, ale także ze względu na projekt nad którym aktualnie pracuję, oraz (tak po prostu;) zwykłą ciekawość co i gdzie poprzestawiać by było szybciej, ładniej i wydajniej :)

Przeglądałem parę dni temu zasoby biblioteki na PP i natrafiłem na książkę o interesującym dla mnie tytule "Wydajne witryny internetowe - Przyspieszanie działania serwisów WWW", której autorem jest Steve Souders. Pomyślałem sobie, że to będzie kolejna książka o tym czy używać for czy while oraz, że w php szybsze jest isset od is_null. Jednak zamówiłem, odebrałem i przeczytałem z przyjemnością !
Co ciekawe książka nie zawiera odniesienia do żadnego języka programowania (bezpośrednio przynajmniej) i nie mówi o żadnych wzorcach projektowych. Jej tematem jest optymalizacja bardziej etapu dostarczania strony www do klienta niż logiki biznesowej aplikacji. Jest w niej mowa m.in. o ograniczaniu połączeń TCP, kompresji dokumentów HTML czy buforowaniu zapytań asynchronicznych - prawie nic z programowania.
Wg badań autora sama faza dostarczania dokumentu HTML to około 10-20% całego czasu przesyłania odpowiedzi, reszta czyli ok 80-90% to pobieranie obrazków, cssów jsów i przekierowania. I właśnie te 80-90% jest przez większość lektury przedmiotem optymalizacji.
Książka podzielona została na 17 części z czego 14 to opisane reguły (wraz z przykładami) po których zastosowaniu nasza strona powinna ładować się szybciej - od 25 do 50%, niezły wynik jak na 160 stronicową książkę :)
Oto te reguły posortowane wg autora od najbardziej znaczącej:

Wykonywania mniejszej liczby żądań HTTP
Używanie Content Delivery Network (to rozwiązanie raczej dla bogatszych ;)
Używanie nagłówka Expires
Kompresja gzip
Umieszczanie arkuszy stylów na początku dokumentu
Umieszczanie skryptów na końcu dokumentu
Unikanie wyrażeń CSS
Używanie zewnętrznych plików JavaScript i CSS
Redukcja liczby zapytań DNS
Zmniejszenie objętości kodu JavaScript
Unikanie przekierowań
Usuwanie duplikujących się skryptów
Konfiguracja nagłówka ETag
Buforowanie zapytań Ajax

Trzeba przyznać, że Pan Souders posiada bardzo dużą wiedzę w tej dziedzinie, za każdym razem dane zagadnienie przedstawione jest z dokładnym uzasadnieniem, stosownym przykładem oraz wynikami pomiarów jakie otrzymał. Bardzo dużo wspominane jest o portalu Yahoo! gdzie pracował przy jego optymalizacji, więc przykłady trafiają się także z "dużych" witryn. W ostatnim rozdziale ponadto poddano analizie 10 jednych z największych serwisów internetowych (YouTube, Google, MSN, Amazon, CNN, Wikipedia, AOL, Amazon, Yahoo!, eBay), gdzie zostają wytknięte wszystkie ich słabości. Swoją drogą ten rozdział mógłby być dedykowany administratorom tych serwisów:)
Z czystym sercem polecam tę książkę każdemu webmasterowi, administratorowi, programiście witryn i komukolwiek kto ma do czynienia z WWW. Te 160 stron może przynieść bardzo duże oszczędności finansowe, gdy serwis zacznie się rozrastać. A co najlepsze - książka kosztuje tylko 29,00 zł !