ITBlog

Memoize - cichy przyjaciel programisty

Marek Majkowski — Wed, 05 Mar 2008 13:00:00 +0100

Grono generuje wszystkie strony html całkowicie dynamicznie. W przeciwieństwie do innych serwisów, nie mamy żadnego odwrotnego proxy (reverse proxy). Nie zapamiętujemy w cache wygenerowanych stron, nie zachodzi u nas taka potrzeba. To na czym się skupiamy, to cache'owanie¹ surowych informacji pobieranych z bazy danych.

W naszej architekturze zapytanie klienta trafia poprzez Loadbalancer do serwera, który generuje stronę html. Te serwery nazywamy Backendami. Backendy pobierają niezbędne informacje z bazy danych i zwracają wynikową stronę stworzoną dla konkretnego użytkownika.

W takiej architekturze baza danych musi obsłużyć ogromne ilości zapytań. Aby ją odciążyć wyniki zapytań są zapisywane w cache. Jeśli w przyszłości zajdzie potrzeba wykonania takiego samego zapytania, to nie trzeba będzie ponownie pytać bazy. Wystarczy tylko pobrać wynik z cache. Ta technika jest szeroko znana pod nazwą Memoization.

Rozważmy najprostszy przykład:

mem_dict = {}
def add(a, b):
    key = "%r %r" % (a,b)
    if key in mem_dict: # mamy zapamiętane?
        return mem_dict[key]
 
    val = a + b # wylicz wartość
    mem_dict[key] = val # zapamiętaj
    return val

W słowniku mem_dict zapamiętywane są wyniki funkcji. Jeśli funkcja będzie wywołana drugi raz z tymi samymi parametrami, to nie będzie konieczne powtórne wykonywanie obliczeń. Wynik zostanie pobrany ze słownika.

W Gronie do przechowywania cache używamy wielu serwerów Memcached. Nasze serwery Memcached są traktowane przez programistę jako gigantyczny rozproszony słownik, w którym dane są trzymane w pamięci wielu maszyn.

Stosowanie Memcached to dość standardowa praktyka. Używa go wiele serwisów, na przykład Facebook.

Jednak standardowy serwer Memcached udostępnia jedynie podstawowe funkcje, których trudno jest używać w naszym środowisku. Dlatego stworzyliśmy programistyczny interfejs do cache'owania o nazwie Memoize, który znacząco upraszcza używanie cache (jego głównym autorem jest Marek Pułczyński).

Kolejnym przykładem będzie funkcja, która pobiera pewne informacje z bazy danych, na przykład dane użytkownika. Standardowo w Django wyglądałoby to mniej więcej tak:

from models import User

def get_user(uid):
    user = User.objects.get(id=uid)
    return user

Spróbujmy użyć dekoratora Memoize, aby wynik tej funkcji był pobierany z cache:

from models import User
from grono2.contrib.memoize import memoize

def user_key(uid):
    return 'model.user.%i' % (uid)

@memoize(user_key)
def get_user(uid):
    user = User.objects.get(id=uid)
    return user

Funkcja user_key generuje klucz, pod którym zostanie umieszczony element w cache. Moża by przypuszczć, że klucz do obiektu można wygenerować automatycznie z parametrów funkcji. Jednak funkcja generująca klucz została wyodrębniona, gdyż może zaistnieć przypadek, że niektóre parametry cache’owanej funkcji nie są jej kluczami głównymi.

Na przykład, poniższy parametr print_debug nie wpływa w żaden sposób na stan cache'owanego obiektu, dlatego nie powinien być brany pod uwagę podczas generowania klucza:

@memoize(user_key2)
def get_user_with_warning(uid, print_debug=True):
    user = User.objects.get(id=uid)
    if user.name == "Jozin" and print_debug:
        print "Jozin pobrany z bazy."
    return user

Jednak co się stanie, gdy zmienimy coś na obiekcie User? W cache będzie przecież stara wartość, więc kolejne wywołania funkcji będą zwracać niewłaściwe stare dane. Dlatego programista musi explicite usunąć (unieważnić, zinwalidować) starą wartość z cache.

Realizowane jest to następująco:

from grono2.contrib.memoize import invalidate

def change_user_name(uid, new_name):
    user = get_user(uid)
    user.name = new_name
    user.save()
    invalidate(user_key(uid)) # wyczyść stary cache

Zajmijmy się trudniejszym przykładem, gdzie dwa obiekty połączone są relacją. Przy zmianie jednego może zaistnieć potrzeba zinwalidowania drugiego. Nasza implementacja Memoize pozwala na to.

W tym przykładzie niech model Profile będzie powiązany relacją z modelem User:

from models import User, Profile 
from grono2.contrib.memoize import memoize

def user_key(uid):
    return 'model.user.%i' % (uid)

@memoize(user_key)
def get_user(uid):
    user = User.objects.get(id=uid)
    return user


def profile_key(uid):
    return 'model.profile.%i' % (uid)

@memoize(profile_key)
def get_profile(uid):
    p = Profile.objects.get(id=uid)
    p.user = get_user(id=uid)
    return p

Jak widać zmiana w User musi spowodować unieważnienie cache obiektu Profile. Aby to osiągnąć definiujemy klucz wiążący, u nas nazywany kluczem wersji. Następnie, aby usunąć wszystkie powiązane rekordy wystarczy jedynie zinwalidować ten klucz.

def super_key(uid):
  return "super_key.%d" % uid

@memoize(user_key, super_key)
def get_user(uid):
...

@memoize(profile_key, super_key)
def get_profile(uid):
...


def change_user_name(uid, new_name):
    user = get_user(uid)
    user.name = new_name
    user.save()
    invalidatev(super_key(uid)) # usuń powiązane rekordy z cache

Wygląda to prosto i intuicyjnie. Jednak główna trudność polega na tym, że działamy w środowisku rozproszonym. Jest możliwa sytuacja, gdy jeden Backend zmodyfikuje rekord i go usunie z cache, a inny Backend pobierze chwilę wcześniej starą wartość i doda ją do cache. Efekt tego będzie taki, że w cache będzie przechowywana niepoprawna wartość. Na szczęście, dzięki przemyślanej implementacji Memoize mamy gwarancję, że taka sytuacja nie wystąpi.

Opisana architektura bardzo dobrze sprawdza się w praktyce. Serwery Memcached bardzo łatwo się skalują, gdy brakuje nam pamięci na cache, to po prostu dostawiamy kolejną maszynę.

Ciekawskich może zainteresować to, że raz na jakiś czas musimy zrestartować serwery Memcached. Zanim cache ponownie zostanie wypełniony danymi mija co najmniej doba.

Z punktu widzenia programisty dekorator Memoize można bardzo prosto stosować w praktyce. Nie jest to żadna przełomowa technologia, lecz łatwość w nauce i zastosowaniu powoduje że nawet młodsi informatycy mogą pisać kod, który będzie działał dla dziesiątków tysięcy użytkowników.

Dzięki cache'owaniu prawie 99% wszystkich zapytań nie musi trafić do bazy. Jednak cały czas staramy się znaleźć miejsca, które nie są poprawnie cache’owane, aby móc jeszcze bardziej przyspieszyć serwis i odciążyć bazę danych.

¹Przepraszam purystów językowych za polonizowanie wyrazu cache. Jak to często w informatyce bywa, nie istnieje jeszcze dobry odpowiednik tego wyrazu w języku polskim. Artykuł Wikipedii sugeruje odmianę z apostrofem i postaram się tego trzymać.

32 czy 64 bity?

Marek Majkowski — Thu, 17 Jan 2008 11:19:00 +0100

Parafrazując tytuł jednego z poprzednich postów, ten powinien brzmieć “64 bitom mówimy papa”.

Nie jest żadną tajemnicą, że w Gronie używamy Linuxa. Niczym nowym też nie jest, że serwis stoi na frameworku Django. Podobno jesteśmy największym serwisem używającym tej technologii.

Jednak nie dla wszystkich jest jasne jak wygląda Django od strony serwerowej…

Podczas surfowania po Gronie, Twoje żądanie dotyczące strony grona (request) trafia do jednego z naszych serwerów. Następnie serwer przypisuje obsługę Twojego requesta jednemu z wielu procesów Django. Pojedynczy proces generuje stronę Grona, ale może obsługiwać tylko jedno żądanie na raz. Linuxowcy mogą znaleźć podobieństwo w tym modelu z modelem “prefork” z konfiguracji Apache. Po wygenerowaniu strony proces jest znów dostępny i czeka na kolejne kliknięcia użytkowników.

Wynika z tego, że na pojedynczym serwerze możemy obsłużyć na raz tylko tyle żądań, ile mamy uruchomionych procesów Django¹. Niestety, pojedynczy proces zużywa dość dużo pamięci. Aby móc obsługiwać jak najwięcej użytkowników na raz, wypadałoby mieć możliwie dużo uruchomionych procesów. Jednak ich ilość jest limitowana wielkością pamięci operacyjnej.

Aby zwiększyć wydajność (czyli ilość stron które możemy wygenerować), staramy się w miarę możliwości zmniejszać wielkość pojedynczego procesu. W tym celu możemy zmniejszać ilość linii kodu lub optymalizować zużycie pamięci operacyjnej przez proces. Niestety oba zadania są bardzo trudne.

Ostatnio wpadliśmy na inny pomysł.

Nasze serwery używają 64 bitowej wersji linuxa. Administratorzy zdecydowali się na to już dawno temu. Głównym argumentem było to, że zamierzaliśmy używać większej ilości RAMu niż 4GB, oraz lepsza wydajność tej architektury.

Padł pomysł, żeby sprawdzić ile RAMu zaoszczędzimy przenosząc się na “stare” 32 bity. W sumie to w Pythonie całkiem sporo pamięci zajętej jest przez wskaźniki, a właśnie zmniejszenie jej dałoby największy zysk.

Efekt okazał się dużo lepszy niż przewidywaliśmy. W pełni załadowany proces Django na 32 bitach zajmuje około 60MB, czyli o 30% mniej niż na 64 bitach, gdzie jest to 95MB.

Oto przykład “topa” z maszyny 64 bitowej. Kolumna RES pokazuje orientacyjne zużycie pamięci przez proces:

VIRT  RES  SHR S %CPU   TIME+  COMMAND
212m  96m 3832 S    0  1:49.61 django '/gallery/3329236/0/'
203m  96m 3120 S    0  1:37.78 django '/gallery/4871149/6/0/'
211m  95m 3832 S    0  1:38.74 django '/mailbox/box/1/'
210m  95m 3824 S    0  1:45.45 django '/gallery/photo/40328359/'
210m  95m 3844 S    0  1:48.43 django '/users/index/'
210m  94m 3848 S    0  1:33.94 django '/users/'

A oto, dla porównania, analogiczny z maszyny 32 bitowej:

VIRT  RES  SHR S %CPU    TIME+  COMMAND
68396  62m 3484 S    0  2:06.94 django '/users/433317/'
67716  61m 3488 S    0  1:50.23 django '/gallery/photo/42009962/'
66264  60m 3488 S    0  2:01.94 django '/pub/join/'
65312  59m 3484 S    0  2:08.75 django '/users/'
65148  59m 3508 S    0  1:48.02 django '/users/1533943/friendlist/'
64884  59m 3508 S    0  1:51.48 django '/'

Podsumowując, możemy powiedzieć, że stosowane 64 bitów może nie być takie wspaniałe. Architektura x86_64 niewątpliwie ma wiele zalet, jednak w naszej sytuacji, gdzie ilość zajętego RAMu zaczyna mieć znaczenie, zaczynamy odczuwać jej wady.

Teoretycznie, po całkowitej migracji na 32 bity bylibyśmy w stanie obsługiwać o 1/3 więcej ruchu niż obecnie. Mamy więc o co walczyć.

¹ W praktyce nie jest to takie proste, bo mamy także inne ograniczenia, jak na przykład moc procesora.

MySQL' owi mówimy papa

depesz — Mon, 10 Dec 2007 16:33:00 +0100

Jak zapewne wiadomo Grono.net PostgreSQL’em stoi. Jedynym kawałkiem, który chodził na czymś innym (MySQL) była baza wiadomości między użytkownikami.

Ostatnio przeprowadziliśmy operację zmigrowania jej na PostgreSQL. Udaną operację :)

W chwili obecnej całość działa już na PostgreSQLu, działa ładnie i szybko. Load maszyny z PostgreSQLem jest około 3 krotnie niższy niż load maszyny z MySQL’ em (przy tym samym obciążeniu).

Czym się maszyny różnią? tylko silnikiem bazy danych.

Obie są to dwuprocesorowe xeony 3ghz, z 16GB ramu i macierzą RAID10 z 6 dysków SCSI 72GB 15k rpm.

Wielkość bazy – około 60 gigabajtów w 150 milionach rekordów (i rośnie).

Średni “load” na tej maszynie wynosi ledwie 1.5.

Wychodzi na to, że da się zrobić by PostgreSQL był szybszy i nadal zachować pełną funkcjonalność.

Walka ze spamfiltrami

mieki — Fri, 30 Nov 2007 15:38:00 +0100

Zdecydowałem się na napisanie tego krótkiego tekstu po wielokrotnych próbach skutecznego dostarczenia poczty do serwisu pocztowego, którego właścicielem jest pewien światowy potentat z branży software. Mowa tu o serwisie hotmail.com i wszystkich przystawkach do niego (live.com, msn.com etc.)

Na wstępie warto przytoczyć parę faktów. Whois dla domeny grono.net:

[...]
Domain servers in listed order:
      DNS1.GRONO.NET
      DNS2.GRONO.NET

Odpytanie naszych serwerów dns o rekordy NS dla strefy grono.net

mieki@mieki-laptop:~$ host -t ns grono.net dns1.grono.net
Using domain server:
Name: dns1.grono.net
Address: 193.33.58.3#53
Aliases: 

grono.net name server dns1.grono.net.
grono.net name server dns2.grono.net.

oraz:

mieki@mieki-laptop:~$ host -t ns grono.net dns2.grono.net
Using domain server:
Name: dns2.grono.net
Address: 193.33.58.4#53
Aliases: 

grono.net name server dns2.grono.net.
grono.net name server dns1.grono.net.

Czyli jak widać, delegacja na nasze serwery jest zrobiona w sposób poprawny. Serwis grono.net posiada przyznaną przez RIPE klasę adresów 193.33.59.0/23. Jest to pula PI i rozgłaszamy ją z naszego routera (AS42782).

Jak wiadomo, powszechnym problemem w sieci internet jest wszędobylski spam. Wiadomości o treści reklamowej na przykład o powiększaniu pewnej części ciała. Najczęściej są rozsyłane z zainfekowanych wirusami (lub koniami trojańskimi) komputerów. Posiadacze zarażonego peceta nie są świadomi, że mogą rozsyłać kilkaset maili na sekundę. Odbiorcami spamu są maile użytkowników, zbierane do bazy przez spam-harvestery (czyli takie skrypty, monitorujące witryny webowe, grupy dyskusyjne i inne zasoby sieci w poszukiwaniu prawidłowych adresów email), a także pobierane są z książek adresowych popularnych programów pocztowych na zainfekowanych komputerach.

Protokół przesyłania poczty (SMTP) został zaprojektowany we wczesnych latach osiemdziesiątych XX wieku i praktycznie w niezmienionej formie pozostał do dziś. Ma on szereg błędów, których istnienie można było przewidzieć już na poziomie projektowania samego protokołu. Jednym z poważniejszych z nich jest możliwość podszywania się pod nadawcę. Do tego można użyć zwykłego programu telnet i udawać klienta pocztowego.

Poniżej zaprezentowałem próbę wysłania poczty z konta na nieistniejącej domenie:

mieki@mieki-laptop:~$ telnet mx.grono.net 25
Trying 193.33.58.136...
Connected to mx.grono.net.
Escape character is '^]'.
220 dakota.nemo.pl Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Thu, 4 Oct 2007 23:51:24 +0200 
ehlo jakasdomena.pl
250-dakota.nemo.pl Hello [82.210.166.16]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
mail from: piotr@jakasdomena.pl
250 2.1.0 piotr@jakasdomena.pl....Sender OK
rcpt to: p.milczarek@grono.net
250 2.1.5 p.milczarek@grono.net 
data
354 Start mail input; end with <CRLF>.<CRLF>
From: Piotr Z JakiejsDomeny <piotr@jakasdomena.pl>
Subject: Przykładowa wiadomosc          

Tutaj tresc wiadomosci, czy to dojdzie ?

.
250 2.6.0 <DAKOTAogkJXrRjbDt3H000001ad@dakota.nemo.pl> Queued mail for delivery
quit
221 2.0.0 dakota.nemo.pl Service closing transmission channel
Connection closed by foreign host.

Dopiero po zajrzeniu w nagłówki możemy stwierdzić, że pole From jest sfałszowane.

Received: from jakasdomena.pl ([82.210.166.16]) by dakota.nemo.pl with Microsoft SMTPSVC(6.0.3790.3959);
         Thu, 4 Oct 2007 23:52:26 +0200

podczas gdy:

mieki@mieki-laptop:~$ host jakasdomena.pl
jakasdomena.pl has address 83.133.126.177
jakasdomena.pl mail is handled by 0 jakasdomena.pl.

Czyli host 82.210.166.16 nie jest ani wpisem IN A dla jakasdomena.pl, ani wpisem MX w tej domenie (wybór domeny był całkowicie przypadkowy).

Aby zapobiec procederom tego typu jak powyższy, w Kwietniu 2006 powstał dokument RFC opisujący jak definiować na serwerach dns rekordy dotyczących uprawnień wysyłania poczty.

Typ rekordu, w jakim definiujemy które serwery mogą rozsyłać pocztę z danej domeny, a które nie, to TXT. Przykładowy rekord dla przykładowej domeny grono.net :-)

mieki@mieki-laptop:~$ host -t txt grono.net
grono.net descriptive text "v=spf1 +ip4:193.33.58.0/23 -all" // o tym teraz
grono.net descriptive text "spf2.0/mfrom,pra +ip4:193.33.58.0/23 -all" // natomiast o tym troche później

Ten rekord oznacza deklaracje mechanizmu Sender Policy Framework dla domeny grono.net. Pierwszym elementem rekordu SPF jest deklaracja wersji czyli "v=spf1", następnie występuje lista elementów dla których ustalamy politykę rozsyłania poczty.

Każdy taki element składa się z kilku części. Część pierwsza – kwalifikator – jest to mały znaczek od którego zaczyna się element, wskazujący co zrobić z pocztą przychodzącą od danego elementu. Wszystkie poniższe elementy przedstawiłem w maksymalnym uproszczeniu:

”+” – whitelisting – czyli bezwarunkowe zaakceptowanie poczty i oznaczenie jej jako nie SPAM
”-” – blacklisting – oznaczenie poczty jako niechciana/niepożądana
”˜” – greylisting – w skrócie: zastosuj swoje mechanizmy filtrowania poczty i detekcji spamu

Istnieje jeszcze kwalifikator ”?”, który działa podobnie do ”˜”, ale nie będziemy się zagłębiać w szczegóły. Część druga – typ obiektu:

“a” – rekord IN A w danej domenie np +a – oznacza deklaracje o wysyłaniu poczty z rekordu (bądź rekordów) IN A dla samej domeny
“ip4” – oznacza zakres hostów przedstawiony w postaci CIDR, bądź jeden host bez maski podsieci np. -ip4:193.33.58.0/23
“mx” – oznacza wpis lub wpisy mx w danej domenie, na przykład -mx oznacza deklaracje, że z serwerów pocztowych nie rozsyłamy poczty :>
“all” – oznacza wszystkie inne niezdefiniowane w SPF

Część trzecia (opcjonalna) – wartość parametru: W przypadku domeny grono.net użyty tylko raz – chodzi o “193.33.58.0/23” – czyli klasę adresów IP którą posiada Grono.net

SPF przyjął się jako standard jeżeli chodzi o politykę rozsyłania poczty. Jednakże istnieje sobie firma na świecie o nazwie Microsoft, która stwierdziła, że stworzy swój własny mechanizm polityki walki z pocztą – SenderID. Do deklaracji tego mechanizmu służy właśnie drugi rekord TXT.

Niestety, portale o których wspomniałem na samym początku wykorzystują tę drugą technologię.(Nie wnikam już kto jest rzeczonych serwisów). SenderID nie wnosi tak naprawdę nic więcej do walki ze spamem niż SPF (nawet składnia jest identyczna jeżeli chodzi o deklaracje obiektów). Faktem jest, że wprowadza bardziej szczegółowe sprawdzanie nagłówków które pojawiają się w poczcie (From: i Return Ptah:), oraz tego co jest podawane po HELO/EHLO.

Niestety po mimo zastosowania się do rad potentata z Redmond, nie ma skutecznego sposobu na dostarczenie poczty do adresata, który ma konto przykładowo na serwisie hotmail.com.

Poczta ląduje w folderze Junk, z którego jest automagicznie wywalana po 10 dniach
Poczta wcale nie dociera do adresata.

250 <BAY0-MC10-F5snIXriu0001e384@bay0-mc10-f5.bay0.hotmail.com> Queued mail for delivery

Jeżeli poczta wpadnie do folderu junk i sprytny użytkownik ją oznaczy, że spamem nie jest(kliknie w “znam nadawcę”), kolejna poczta od tego adresata (z tego samego serwera pocztowego), nie jest wrzucana do folderu “Junk” ... ale tylko przez ok. tydzień.

Po przewertowaniu zasobów Usenetu jestem w stanie wysnuć tezę, iż serwery stosujące technologię SenderID zachowują się zgoła niedeterministycznie, albo rządzi nimi jakaś mroczna logika rozmyta, do której zwykły śmiertelnik nie ma dostępu. Na domiar tego dodam, iż ta cudowna technologia jest opatentowana oraz jej nie można stosować bez zgody Microsoftu. Próby kontaktu z kimś ze strony MS są z góry skazane na niepowodzenie. Na maile odpowiadają automaty, albo nic nie odpowiada (w sumie nie dziwne, może im ktoś problem zgłaszał, że im nie działa poczta jak powinna – drogą właśnie pocztową). Po kilku telefonach do MS w pięknym kraju nad Wisłą nie udało się znaleźć osoby kompetentnej, która by podpowiedziała jak w/w problem rozwiązać. Nawet więcej, nie udało się znaleźć osoby, która potrafi skontaktować z personą kompetentną w dziedzinie SenderID.

Dla ciekawskich dodam, iż były zmieniane TTLe rekordów w dnsach, oraz wpisy PTR serwerów dns i pocztowych, z których chcemy coś skutecznie dostarczyć do hotmaila – efekt zawsze ten sam. Zrobiliśmy to już na wszystkie możliwe sposoby – zaglądając nawet do nagłówków, poczty która do hotmaila jakimś cudem dotarła.

My chcemy tylko powiadomić o urodzinach znajomego… a nie powiększyć pewną część ciała.

Dla cierpliwych i szukających wrażeń opis jak działa (albo jak powinno działać) SenderID można znaleźć tutaj: http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx.

Co to jest <i>widget</i>?

k3rni — Wed, 21 Nov 2007 11:36:00 +0100

Oryginalnie, słowo widget oznaczało element graficznego interfejsu użytkownika. Dziś używamy ich wszędzie – są to pola wpisywania tekstu, listy z których wybieramy pozycje, pola do zaznaczania opcji, suwaki, opuszczane menu itp. Pierwsze użycie słowa widget w tym kontekście datuje się na lata 80te.

Dzisiaj, o ile nadal w dziedzinie interakcji z użytkownikiem, słowo widget oznacza konstrukcje bardziej skomplikowane. W najogólniejszym znaczeniu, widget to graficzny element pozwalający zrealizować jakieś funkcje lub prezentujący informacje. Przykładem najprostszego widgeta jest zegarek w pasku zadań na dole ekranu. Prezentuje bieżący czas oraz datę i pozwala na wykonanie kilku związanych z tym czynności – możemy ustawić godzinę, dzień, miesiąc, zmienić strefę czasową, obejrzeć cały kalendarz.

Ta definicja nie mówi nic o środowisku, w którym widget jest prezentowany. Może być to zatem pulpit systemu operacyjnego, okno jakiegoś programu, a nawet strona internetowa. Typowe widgety prezentują informację w sposób ciągły, nie wymagając akcji ze strony użytkownika. Jeśli zajrzymy do historii – w 1996 roku Microsoft wypuścił zestaw Power Toys, który prezentował zaawansowane możliwości systemu Windows 95. Jednym z elementów zestawu był program prezentujący czas, czyli zegar. Nowością był fakt, że ów zegar nie miał prostokątnego okna i dzięki temu wpasowywał się doskonale w każdy pulpit. Możemy więc uznać go za wczesny przykład widgeta. Rok później, ta sama firma wypuściła przeglądarkę Internet Explorer 4, a razem z nią funkcję Active Desktop. Dzięki niej pulpit stawał się hybrydą klasycznego pulpitu oraz strony internetowej. Można było na nim umieszczać fragmenty kodu, które prezentowały np. kursy akcji, pogodę czy na żywo, obliczane pozycje satelitów na orbicie Ziemi. Znowu – widgety.

Dziś widgety obsługiwane są przez wiele platform – zarówno systemów operacyjnych, programów jak i stron internetowych. Sztandarowym przykładem pierwszego jest najnowszy Windows Vista, który obsługuje widgety, nazwane tam gadgetami, na pulpicie oraz w pasku bocznym (Sidebar). Inne systemy operacyjne i środowiska również obsługują widgety, według tej definicji – w Mac OS X mamy Dashboard, w Linuksie jest to SuperKaramba lub gDesklets, zależnie od używanego środowiska graficznego. We wcześniejszych wersjach Windowsa możemy używać Kapsules, Klipfolio (gdzie widgety nazywane są Klips), albo Google Desktop. Ten ostatni funkcjonuje również pod Mac OS X i Linuksem.

Jeśli chodzi o aplikacje, to na pierwszym miejscu wymienić należy przeglądarkę Opera, która posiada już duży zestaw widgetów, oraz Firefoxa, który poprzez rozszerzenie Firefoxit obsługuje widgety w sposób zbliżony do wymienionego wcześniej Dashboarda. Inne rozszerzenia do Firefoxa również mogą być zakwalifikowane jako widgety – np. prezentujące pogodę, najnowsze wiadomości z RSS, czy ranking oglądanej strony w pasku statusu.

Na stronach www, dawno temu „bajerem” był zegarek w tekście strony lub w pasku statusu, zrealizowany Javascriptem. Kwalifikuje się jako prosty widget. Dziś te są bardziej rozbudowane – często w technologii Flash. Można na swojej stronie czy blogu umieścić gierki, graficzne zegarki, swoje najnowsze filmy wgrane na któryś z serwisów. Można pozwolić użytkownikom na zostawianie komentarzy głosowych, wyświetlić swój kalendarz, status w Skype, umieścić quiz, rozmawiać przez komunikatory albo cały swój blog zamienić w widget który inni mogą wstawić u siebie.

Istnieją też strony internetowe będące swego rodzaju agregatorami widgetów. Użytkownik może sam skomponować stronę, składającą się z wybranych elementów, np. czytników wiadomości RSS z różnych źródeł, swoim kalendarzem czy podglądem poczty. Takimi miejscami są iGoogle, Netvibes, Pageflakes.

Wszystkie wymienione wyżej kategorie są, w ramach konkursu, widgetami. Akceptujemy więc bardzo szeroki zakres prac, pod wiele platform i środowisk, dając wiele możliwości w wykazaniu się umiejętnościami oraz pomysłem. Regulamin określa, że najważniejszymi kryteriami będzie funkcjonalność i stopień wykorzystania zasobów Grona. Stawia za to niewiele ograniczeń co do techniki realizacji projektu, zostawiając ogromne pole do popisu.

Więcej informacji o konkursie na apidoc.grono.net, znajdziecie tam również dokumentację udostępnionych funkcji, przykładowy kod pokazujący jak z nich korzystać, info o kontakcie i pomocy, oraz formularze zgłaszania błędów.

Poznaj...

Kasia — Wed, 07 Nov 2007 18:00:00 +0100

Dzisiaj na nasze podchwytliwe pytania odpowie Depesz, czyli Hubert Lubaczewski.

Q: Imię, nazwisko:
A: depesz. podobno mam też imię i nazwisko (Hubert Lubaczewski), ale z drugiej strony – nie wierzę plotkom.

Q: Data i miejsce urodzenia:
A: Urodziłem się 18 lat temu (plus vat) w takim małym pokoju z lekarzami w Warszawie:) A tak na prawdę mam 31 lat.

Q: Stanowisko w Grono.net:
A: Dba czyli bazodanowiec.

Q: Wykształcenie, ukończone kursy:
A: ekhem. matury nawet nie mam.

Q: W Grono.net pracuję od:
A: 3 września 2007.

Q: Obowiązki w Grono.net:
A: Aby baza rosła w siłę, a zapytania były szczęśliwsze. Albo szybsze.

Q: W jakich językach programujesz:
A: Głównie w sql, perl. Dodatkowo, trochę w shellu, php, ruby, C.

Q: Dotychczasowe prace:
A: Byłem m.in. spedytorem międzynarodowym, programistą od wizualizacji wyników referendum europejskiego w 2003 roku, bazodaniowcem/programistą odpowiedzialnym za analizy rynku tytoniowego w Polsce.

Q: W przyszłości chcę:
A: Żyć dniem i nie zastanawiać się nad tym co przyniesie jutro.

Q: Zainteresowania:
A: Bazy danych (serio, ja naprawdę to lubię), samochody (od strony użytkownika, nie mechanika, bo na tym to się zupełnie nie znam).

Q: Zawsze znajdę czas na…
A: Flame’a. Na dowolny temat, po dowolnej ze stron konfliktu :)

Q: Nigdy nie znajdę czasu na…
A: Oglądanie telenowel. Próbowałem. Padam w okolicach 3 minuty.

Q: Słucham:
A: Dobrej muzyki.

Q: Ulubione strony internetowe: :-)
A: http://www.google.com/reader/view/, http://osloskop.net/, http://hatak.pl

Q: Lubię:
A: To bardzo ogólne pytanie, więc – no cóż, uwielbiam filet mignon we “fridays”.

Q: Nie lubię:
A: Kontynuując tematykę: spaghetti, pasty, latanii i wszystkiego co włoskie (pizza taka jaką jem jest amerykańska, więc się nie liczy:)).

Q: Podziwiam…
A: dużo ludzi za dużo rzeczy.

Q: W życiu prywatnym dbam o:
A: o to by było fajnie.

Q: Grono.net jest:
A: Przyjemnie spokojne.

Q: Mój ulubiony współpracownik to.. (dlaczego):
A: A tu uchylę się od odpowiedzi ponieważ byłaby sprzeczna z moimi przekonaniami religijnymi :)

Poznaj...

Kasia — Fri, 19 Oct 2007 16:00:00 +0200

Tym razem kilka słów o sobie powie Marcin Winkler, Gronowy Release Manager.

Q: Imię, nazwisko:
A: Marcin Winkler

Q: Data i miejsce urodzenia:
A: 22.06.1976 Wołomin

Q: Stanowisko w Grono.net:
A: Release Manager

Q: Wykształcenie, przebyte kursy:
A: Wykształcenie, na razie tylko średnie, ale w przyszłości chcę skończyć studia.

Q: W Grono.net pracuję od:
A: Od początku 2007 roku.

Q: Obowiązki w Grono.net:
A: Opiekuję się kodem napisanym przez programistów, który wrzucają do repozytorium, przekazuję aplikacje do testowania i wrzucam je na Grono. Dbam, aby było jak najmniej błędów oczywistych i takich które “nigdy nie powinny się zdarzyć” więc pilnuje wszystkiego od początku do końca.

Q: W jakich językach programujesz:
A: Najbardziej lubię programować w języku Pyton, Php i Perl oraz w domieszkach bash’a.

Q: Dotychczasowe prace:
A: Pracowałem m.in. jako administrator, programista i bazodanowiec.

Q: W przyszłości chcę:
A: Dalej się rozwijać, podróżować oraz inwestować w siebie i rodzinę.

Q: Zainteresowania:
A: Interesuje mnie inne spojrzenie na świat: medytacja, paranauka, rozwijanie samego siebie. Poza tym… programowanie:)

Q: Zawsze znajdę czas na…
A: …odrobinę pesymizmu.

Q: Nigdy nie znajdę czasu na…
A: …spełnienie wszystkich marzeń.

Q: Słucham:
A: Cafe Del Mar, Zion Train, K44 (ich stare piosenki są najlepsze), Moby, Buddha Bar, preferuję mieszankę Hip-Hopu i Ambientu z dodatkiem Chill Out, czasami muzyka jazzowa i rozrywkowa.

Q: Ulubione strony internetowe:
A: info.onet.pl, reader.google.com , blogi znajomych i własny.

Q: Lubię:
A: Czasami, zjeść coś słodkiego.

Q: Nie lubię:
A: Tych co nie lubią innych:)

Q: Podziwiam….
A: Innych za konsekwentne realizowanie swoich celów.
Q: W życiu prywatnym dbam o:
A: O rozwój osobisty, ponieważ czuję, że ciągle nie jestem doskonały w tym co robię.

Q: Grono.net jest:
A: Dynamiczną, młodą firmą z dużą możliwością rozwoju;)

Q: Mój ulubiony współpracownik to.. (dlaczego):
A: Każdy ma swoje wady i zalety lub zalety i wady. Wszystko zależy od punktu siedzenia.

Napisz widgeta i wygraj staż w Grono.net!

Kasia — Wed, 03 Oct 2007 14:05:00 +0200

Proste zasady – zwycięża 5 najciekawszych i pomysłowych aplikacji, wykorzystujących zasoby i kod API Grono.net.

Freestyle – może to być widget na PC, Maca lub stronę www.

Żadnych formalności – przesyłasz aplikację z opisem i swoje dane na adres api@grono.net, otrzymujesz potwierdzenie i jesteś w konkursie.

DO WYGRANIA:

Staż w Dziale IT Grono.net
Apple MacBook Pro
Apple MacBook
3 iPody
Wieczna sława twórcy ulubionego widgeta dla ponad 1,3 miliona naszych użytkowników!

Zgłoszenia przyjmujemy od 1 października do 30 listopada 2007

WSZYSTKO CZEGO POTRZEBUJESZ ZNAJDZIESZ NA apidoc.grono.net

Test macierzy Dell powervault md1000

depesz — Thu, 27 Sep 2007 17:04:00 +0200

Ostatnio dostaliśmy nową zabawkę do testów - nowiutkiego della powervault md1000. Co to takiego, zapytacie? Otóż jest to całkiem miły "das" (direct attached storage, czyli, upraszczając trochę, po prostu macierz) od Dell'a.
Egzemplarz, który testowaliśmy miał 15 dysków sas, każdy o pojemności 72gb i prędkości obrotowej 15000 rpm. Macierz ma być używana jako nośnik dla bazy danych, więc zanim zostanie użyta musieliśmy przeprowadzić testy (by wiedzieć co i jak podzielić na poszczególne dyski logiczne). Podłączyliśmy ją do wolnego serwera (także Dell'a, ale nieużywanego), którego parametry są "całkiem, całkiem" :

4 dwurdzeniowe xeon'y (3.4ghz)
32gb ram
2 wewnętrzne dyski, sas, 72gb, 15000 rpm, 72g zestawione w raid1

Testy przeprowadziliśmy przy pomocy bonnie++, procedura testowa była prosta:

zestawienie nowego raida
mke2fs -j (ext3)
zamontowanie partycji z opcjami noatime i nodiratime
uruchomienie bonnie++ z tymi opcjami:"-u nobody:nobody -f -s 65000,8192 -n 0 -x 3" (8192 gdyż taka jest wielkość strony w postgresie)
rezultaty dla każdego raida (-x 3!) były uśrednione

Wiedzieliśmy, że docelowo zostanie użyty raid10, więc testowaliśmy głównie różne jego kombinacje. Przeprowadziliśmy 2 oddzielne serie testów:

raid 10, czysto sprzętowy, używając 2, 4, 6, 8, 10, 12 i 14 dysków
raid 10, mieszany sprzętowo/software'owy - sprzęt był użyty do zrobienia 7 oddzielnych dysków logicznych, każdy z użyciem 2 dysków fizycznych spiętych w raid1, ale potem były one składane w jeden dysk logiczny przy pomocy software'owego raida (linux, raid0) w urządzenie na 4, 6, 8, 10, 12 i 14 dyskach fizycznych

Testy przeprowadzono z wyłączeniem read-aheada, zapisy były w trybie write-back, gdyż macierz jest wyposażona w pamięć z podtrzymaniem bateryjnym. Rezultaty są trochę dziwne (czerwona linia - raid10 czysto sprzętowy, zielona linia - rozwiązanie mieszane: sprzęt/software):

Jeśli wolisz wyniki w postaci tabelek:

name	put_block	put_block_cpu	rewrite	rewrite_cpu	get_block	get_block_cpu	seeks	seeks_cpu
2xraid1	34820	12	25105	6	97459	9	436	1
4xraid10	95427	37	65661	19	246490	23	615	1
6xraid10	100367	39	70955	20	288188	27	672	1
8xraid10	165980	66	98887	29	423983	39	737	1
10xraid10	164195	64	96039	28	394442	36	618	1
12xraid10	185671	72	103271	30	414942	38	686	1
14xraid10	195349	76	104087	30	439088	40	821	2
2s0@2h1	86651	32	61836	18	251109	24	618	1
3s0@2h1	110977	42	79381	24	356231	34	708	2
4s0@2h1	120232	45	91988	28	391041	37	748	2
5s0@2h1	131024	50	92403	28	556601	55	788	2
6s0@2h1	123812	47	93563	28	482090	47	778	2
7s0@2h1	137513	53	100083	31	657221	65	839	2
2s0@6h10	160090	61	104375	32	482106	46	716	2
2s1@2h1	44373	16	25972	6	99071	10	651	1
13xraid5	222225	87	113040	32	392238	36	806	2
14xraid5	222690	87	114142	33	398201	36	809	2

Znaczenie kolumny name:

(\d+)xraid(\d+) - $1 dysków w czysto sprzętowym raidzie $2. przykładowo - 6xraid10 oznacza 6 dysków w sprzętowym raidzie 10
(\d+)s0@2h1 - $1 dysków logicznych (gdzie każdy dysk logiczny, to 2 dyski fizyczne spięte w sprzętowy raid1) połączone w software'owy raid0. przykładowo 5s0@2h1 oznacza 5 dysków logicznych (każdy z 2 napędów, w raid1) połączonych, dając razem raid 10 na 10 dyskach w układzie mieszanym sprzętowo/software'owym
2s0@6h10 - 2 dyski logiczne, każdy składający się z 6 dysków fizycznych połączonych w sprzętowy raid10, połączone w software'owy raid 0
2s1@2h1 - 2 dyski logiczne, każdy będący 2 dyskowym, sprzętowym, raidem 1, połączone w software'owy raid1. daje to 4 dyskowa macierz o pojemności pojedynczego dysku.

Jak widać, przetestowaliśmy kilka układów więcej niz pokazane jest to na wykresach powyżej, ale wszystkie pozostałe były jedynie testowe, bez realnego wpływu na jakiekolwiek decyzje. Dziwna sprawa - czysto sprzętowy raid wykazuje "schodki" w wydajności zapisów (i przepisywania danych). Przyrost wydajności był tylko wtedy, gdy ilość dysków była potęgą 2. W raidach mieszanych (sprzęt/software) nie było takiego efektu. Ponieważ macierz ma 15 dysków, zdecydowaliśmy się na użycie takiego layoutu:

1 dysk jako globalny hot-spare
2 diskowy raid1 (sprzętowy) na logi postgresa
8 dyskowy raid10 (sprzętowy) jako główna przestrzeń (tablespace) bazodanowa
4 dyskowy raid10 (sprzętowy) jako dodatkowa przestrzeń bazodanowa

Teoretycznie układ ten powinien zapewnić najlepszą wydajność, czy tak było? Po stworzeniu macierzy, założeniu systemów plików, przetestowaliśmy wydajność wszystkich 3 dysków logicznych jednocześnie. Wyników nie rozrysowywaliśmy, gdyż i tak nie miałoby to zbyt dużego sensu. Ale wyniki z testu można podać tabelarycznie:

name	put_block	put_block_cpu	rewrite	rewrite_cpu	get_block	get_block_cpu	seeks	seeks_cpu
2xraid1	30875	12	15438	5	39867	5	224	1
2xraid1	32489	14	24037	7	99700	9	389	1
2xraid1	35096	13	24708	6	96969	9	383	0
4xraid10	41343	18	31910	11	61798	8	109	0
4xraid10	80630	34	35707	12	137488	18	306	1
4xraid10	40136	17	38388	12	147282	16	255	0
8xraid10	42376	18	37513	13	155740	19	302	1
8xraid10	156044	65	34153	11	177690	22	338	1
8xraid10	146096	61	71307	25	29568	3	154	0

(pokazano tu wyniki każdego testu, czyli po 3 wyniki dla każdej z partycji). Jak widać, wyniki są niższe od oczekiwanych. Dodatkowo, analizę utrudnia fakt, iż test macierzy 8xraid10 skończył się jako pierwszy (bo jest najszybsza), 4xraid10 skończył się trochę później, a 2xraid1 trwał i trwał, i trwał:)
Myślę, że wybraliśmy rozwiązanie optymalne przy tej macierzy i kontrolerze, ale tak czy inaczej zastanawiające jest czemu wydajność tak mocno jest powiązana z potęgami dwójki.

Poznaj...

Kasia — Thu, 27 Sep 2007 14:01:00 +0200

Dziś spotkanie z Kamilem Załęskim, Kierownikiem Działu Wersji Językowych.

Q: Imię, nazwisko:
A: Kamil Załęski

Q: Data i miejsce urodzenia:
A: 23.02.1986, Pruszków

Q: Stanowisko w Grono.net:
A: Kierownik Działu wersji językowych

Q: Wykształcenie, kursy:
A: Wyższa Szkoła Technologii Informatycznych, specjalizacja – Bazy Danych

Q: W Grono.net pracuję od:
A: października 2006

Q: Obowiązki w Grono.net:
A: Przygotowuję wersje językowe Grona. Dbam o otwarcie Grona na zagranicznych użytkowników

Q: W jakich językach programujesz:
A: Python, Ruby, Javascript, PHP

Q: Dotychczasowe prace:
A: Głównie freelance, a bezpośrednio przed Gronem agencja interaktywna Prospekta

Q: W przyszłości chcę:
A; Tajemnica :P

Q: Zainteresowania:
A: Programowanie, web usability, oglądanie seriali (Soprano, Lost, Jericho,...):)

Q: Zawsze znajdę czas na…
A: Czytanie Google Readera

Q: Nigdy nie znajdę czasu na…
A: Posprzątania biurka

Q: Słucham:
A: Wsiowych hitów w samochodzie Sebka, a z wykonawców to: Fatboy Slim, Moby, Chemical Brothers, Rammstein, Prodiży

Q: Ulubione strony internetowe:
A: joemonster.org, digg.com

Q: Lubię:
A: Hamburgery w HRC

Q: Nie lubię:
A: Jeździć komunikacja zbiorową i takich kwestionariuszy

Q: Podziwiam…
A: Ludzi którzy potrafią konsekwentnie realizować swoje cele

Q: W życiu prywatnym dbam o:
A: O ludzi mi bliskich i to co dla mnie ważne

Q: Grono.net jest:
A: Pełne bardzo kumatych ludzi od których wiele się uczę

Q: Mój ulubiony współpracownik to… (dlaczego):
A: Nie lubię nikogo wyróżniać