Pomóż testować parametr TcpRemoteBufferSize

W pliku konfiguracyjnym firebird.conf jest między innymi parametr TcpRemoteBufferSize. Definiuje on maksymalną wielkość transferowanych pakietów. Domyślna wartość parametru to 8 kB. Maksymalna wartość to 32 767. Teoretycznie większe pakiety powinny przyspieszać transfer dużych ilości danych, zwłaszcza w przypadku sieci o dużych opóźnieniach (takich jak Internet).

Carlos H. Cantu ostatnio testował ten parametr, ale nie znalazł znaczących różnic — wykonując instrukcję select first 2000 * from tabela (tabela nie zawiera pól BLOB). Podobny test, wykonany jakiś czas temu z inną wersją Firebird, w innym systemie operacyjnym, dawał trzykrotne przyspieszenie transferu danych, jeżeli parametr miał wartość 32K, ale podczas testów w obecnym środowisku nie udało się powtórzyć tych wyników.

Carlos H. Cantu prosi wszystkich, którzy mają trochę czasu, aby pomogli testować ten parametr i opublikowali wyniki swoich testów w komentarzu do »tego artykułu«. Podczas testów proszę, aby testować różne wartości w bibliotece klienta, w serwerze oraz w obu, a także napisać w komentarzu, jaka wersja serwera i jaka wersja biblioteki klienta była testowana. Warto też przed właściwym testem wykonać testowaną instrukcję co najmniej raz, aby wypełnić danymi pamięć podręczną (cache) Firebird i systemu operacyjnego. Dzięki temu wyniki testów będą bardziej miarodajne.

Hardcorowi użytkownicy mogliby również zainstalować Wireshark w celu podglądu detali komunikacji.

Nowa strona internetowa projektu

Zespół osób zaangażowanych w utrzymanie strony internetowej projektu Firebird opracował jej całkiem nową wersję. Aktualnie jest dostępna wersja beta strony.

Obecnie potrzebni są testerzy tej nowej strony. Ewentualne błędy należy zgłaszać na tej stronie internetowej.

Pytania dotyczące działania strony internetowej można zadawać na liście mailingowej.

Mierzenie wydajności Firebird

Testy TPC są najlepiej znanym sposobem mierzenia wydajności bazy danych. Nie są jedynym sposobem. Różne testy mierzą różne aspekty wydajności bazy danych. Jednym z takich testów jest Indexed Insertion Benchmark. Służy on do mierzenia wydajności bazy danych w zastosowaniach związanych z reklamą, portalach społecznościowych itp. Test mierzy wydajność w sytuacjach, gdy do bazy dodawane są nowe dane, podczas gdy w tym samym czasie wykorzystywany są różne indeksy do pobierania danych. Test pokazuje wydajność bazy gdy interesuje nas:

• szybkie wyszukiwanie informacji, wymagające korzystania z indeksów,
• szybkie dodawanie do bazy wielu danych,
• aplikacje wymagają szybkiej odpowiedzi, co jest możliwe przy natychmiastowej aktualizacji indeksów w miarę modyfikowania lub dodawania nowych danych.

Philippe Makowski zaimplementował ten test dla wykorzystania do mierzenia wydajności Firebird. Można je pobrać z »tej strony internetowej«.

Potrzeba beta-testerów programu IBReplicator

Fundacja IBPhoenix, finansująca rozwój serwera Firebird oraz kilka prog­ramów narzędziowych, poszukuje beta-testerów najnowszej wersji programu IBReplicator. Poszukiwani są testerzy korzystający z serwerów baz danych Firebird lub InterBase oraz Oracle. Testowana wersja prog­ramu IBReplicator wspiera natywną dwu­kierunkową replikację między bazami Firebird, Oracle i InterBase.

Chętni do testowania proszeni są o kontakt z Paulem Beachem.

Firebird na dysku SSD

Jeden z użytkowników serwera Firebird zamienił dysk SCSI na dysk SSD. W efekcie okazało się, że na przykład:

• na dysku SCSI realizacja dużego zapytania trwała około 8 sekund; to samo zapytanie na dysku SSD trwało około 4 sekundy;
• w przypadku silnego obciążenia serwera (ponad 1000 połączeń!) to samo zapytanie na dysku SCSI trwało około minutę, a na dysku SSD — nadal tylko 4 sekundy.
  

Duże bazy danych Firebird

Dmitry Kuzmenko informował już o różnych testach serwera Firebird. Ostatnio przeprowadził test działania serwera Firebird w przypadku dużych baz danych. Opisał go w tym artykule. W podsumowaniu artykułu autor podkreśla dwa wnioski:

1. Firebird niewątpliwie potrafi obsługiwać wielkie bazy danych. Na odpowiednim sprzęcie jest możliwe utworzenie bazy o wielkości 32 TB. Firebird obsługuje taką bazą z taką samą wydajnością jak mniejsze bazy danych (np. 1 TB lub mniejsze).
2. Firebird wykazuje się dobrą skalowalnością i małym obciążeniem systemu. Baza o rozmiarze jednego terabajta została utworzona na zwykłym komputerze biurkowym. Taki komputer ma wystarczającą moc do wykonywania ogólnych zapytań na takiej bazie danych. Jeżeli nie pobieramy milionów rekordów, to czas realizacji zapytań jest taki sam jak dla znacznie mniejszych baz danych (10 do 15 GB).

Przy okazji autor wymienia kilka firm, w których używany jest serwer Firebird, a bazy danych mają obecnie rozmiar od 200 do ponad 450 GB.

Wydajność Firebird w Internecie

Niedawno informowałem o testach wydajności protokołu lokalnego w systemach wieloprocesorowych, które zrealizował i opisał Dmitry Kuzmienko. Tym razem pragnę poinformować o kolejnych testach wydajnościowych serwera Firebird.

Adriano dos Santos Fernandes w swoim blogu opisał swoje eksperymenty, w których badał wydajność serwer Firebird działającego w sieciach z dużym opóźnieniem między wysłaniem żądania i otrzymaniem odpowiedzi (takich jak Internet). Celem było badanie wpływu tych opóźnień na wydajność protokłu stosowanego przez Firebird do wymiany informacji między serwerem i aplikacją kliencką.

Na stronie Firebird Tracker można nie tylko zgłaszać błędy, ale również propozycje usprawnień serwera. Można rónież głosować, które z usprawnień są najważniesze. Im więcej głosów zostanie oddanych, tym szybciej danym problemem zajmą się programiści projektu. Jedną z propozycji jest usprawnienie protokołu sieciowego używanego przez Firebird.

Protokół lokalny w systemach wieloprocesorowych

Dmitry Kuzmienko w swoim blogu opisał ciekawe doświadczenie, w którym testowany był serwer Firebird SuperServer 1.5 działający w systemie Windows. Jak wiadomo, ta wersja serwera zawsze jest przypisana do jednego z procesorów (standardowo jest to procesor numer 0). Na tym serwerze wykonywana była kopia bazy danych, wykonywana przy pomocy następującego polecenia:

gbak -b -g db.fdb db.fbk

Podczas testów okazało się, że jeżeli stosowane jest lokalne połączenie, to szybkość wykonania kopii bazy danych zależy od tego, na którym procesorze wykonywany jest program gbak. Jeżeli zarówno serwer jak i program gbak działały na tym samym procesorze, to w testowanym systemie wykonanie kopii bezpieczeństwa przykładowej bazy (plik bazy danych zajmował 3,8 GB) trwało 9 minut i 22 sekundy. Natomiast jeżeli oba programy działały na różnych procesorach, wtedy to samo działanie trwało aż 15 minut 41 sekund.

Jeżeli zamiast połączenia lokalnego zastosowano połączenie przez TCP/IP, to w obu przypadkach wykonanie tego samego działania trwało tylko 4 minuty i 10 sekund.

Wniosek jest oczywisty: nigdy nie należy stosować połączeń lokalnych. Zamiast tego lepie stosować połączenia przez TCP/IP (przynajmniej w przypadku Fiebird SuperServer 1.5; inne wersje nie były jeszcze testowane pod tym kątem). Jeżeli baza danych jest na lokalnym komputerze, to jako serwer można użyć albo localhost, albo adres 127.0.0.1.