zaczynamy kolejny miesiąc – więc na dobry początek taka trochę ciemniejsza tapetka. oczywiście znowu deviantart.
Author: depesz
tuningowanie aplikacji bazodanowych korzystających z postgresa – kontynuacja
tak jak już d- mi zauważył pojawiła się druga część podpowiedzi nt. tunintowania aplikacji – napisana oczywiście przez josha berkusa.
w tej części podpowiedzi:
- delete jest kosztowny
- używanie prepare/execute dla wywoływania zapytań w pętli
- używanie connection-pool'i (buforów połączeń?)
najważniejszy post na blogu
pewien facet, niejaki mike stopforth, w artykule na lokalnym (z naszego punktu widzenia, bo dużym u nich) portalu w rpa, napisał, że jego cele do osiągnięcia w życiu to …
i tu była lista 3 punktów o których sam napisał, że sę z różnych powód niemożliwe.
na pierwszym miejscu była przejażdżka (kierowanie) aston martinem.
nie dziwię mu się – też bym chciał 🙂
niecałe 2 tygodnie później dostał maila w którym justin divaris z aston martina zaproponował wypożyczenie astona db9 na cały dzień.
co było dalej – opisywać nie chcę – chętni przeczytają wpis na blogu mike'a. ogólnie – przejechał się. był super-szczęśliwy i przy okazji poczynił kilka interesujących uwag nt. podejścia do człowieka w astonie w porównaniu do ferrari, lamborghini, bmw czy amg. warto przeczytać choćby po to by móc sobie poprawić humor.
eclipse – ide dla twardzieli
ogólnie nie lubię javy. natomiast jest dla niej coś co mi się podoba – ide eclipse. ma sporo plusów, i mimo, że nabijam się z niego w firmie, dostrzegam w nim sporo plusów.
niestety. ide to jest mocno modularne i aby miało sensowną funkcjonalność trzeba naściągać pluginy, testować czy działają i ogólnie bawić się z tym.
do teraz.
istnieje taki projekt który nazywa się “easy eclipse“.
idea projektu jest prosta: wybierzemy zastosowanie, pod to zastosowanie spaczkujmy to co trzeba. i udostępnijmy gotowe do działania, skonfigurowane, o-pluginowane środowisko.
przykłady zastosowań:
- expert java
- desktop java
- server java
- mobile java
- plugin warrior
- lamp
- php
- ruby on rails
- python
- c/c++
każde z zastosowań generuje trochę inną paczkę, np. paczka “lamp" zawiera:
- eclipse jako taki
- eclipse tools
- java jre
- eclipse java development tools
- anyedit tools
- eclipse util plugins
- color editor
- web tools editors
- html tidy
- amateras html and xml editor
- quantumdb
- php eclipse
- simple test for php
- pydev
- ruby development toold
- radrails
- eclipse perl integration
całośc w paczkach dla windows, macos'a i linuksa. gotowe. tylko podgrzać (rozpakować) i używać.
piątek trzynastego?
firma ubezpieczeniowa aa, ustami swojego pracownika, kevina sinclaire'a, poinformowała, że po gruntownym przebadaniu sprawy, to nie piątek trzynastego jest najbardziej pechowym dniem.
niezależnie od rozmaitych przesądów i wierzeń, statystycznie najgorszym dniem jest poniedziałek, 27-ego. na szczęście najbliższy taki dzień jest dopiero sierpniu 2007. może warto na ten dzień wziąść urlop i nie wychodzić z domu?
BUG w postgresie :)
heh
wykryłem pierwszego poważnego buga w postgresie 🙂
w 8.2rc1 jest bug który wykłada postgresa (segfault, sig 11) przy vacuumowaniu indeksów gin 🙂
w sumie szkoda – bo giny są niesamowicie szybkie – ale i dobrze, bo bug namierzony to bug zniszczony. i mogę się chwalić, że przyczyniłem się do poprawienia stabilności postgresa 🙂
tapeta na dziś
deviantart – dla tych co chcieliby tapety z przesłaniem:
tuningowanie aplikacji bazodanowych korzystających z postgresa
josh berkus, osoba dosyć znana w światku postgresowym, opublikował na swoim blogu pierwszy (z serii?) wpis nt. tuningowania aplikacji.
wpis zawiera wstęp teoretyczny i 3 hinty.
hinty sa proste:
- nigdy nie używaj wielu małych zapytań gdy jedno większe załatwiłoby sprawę.
- grupuj wielokrotne insert/update/delete w pojedyńcze operujące na większej ilości danych, lub gdy sie nie uda – w transakcje.
- rozważ zastosowanie bulk-loadingu (copy) zamiast serii insertów.
wstęp teoretyczny jest także istotny, ale ani tego ani dokładnego uzasadnienia hintów tłumaczyć nie będę – przeczytajcie sami.
request tracker “rządzi”
część z was zna może rt (request trackera). tym którzy nie znają wyjaśnię – jest to jeden z najlepszych (albo najlepszy) system do zarządzania zgłoszeniami/błędami. mamy instalację rt. instalacja jest sporawa: > 50000 ticketów, 160 kolejek, około 150-200 nowych ticketów dziennie. instalacja chodziła kiedyś na postgresie (wersja 7.2) ale działała wolno i przenieśliśmy na mysql'a (4.1). i zaczęła działać szybciej. ostatnio dowiedziałem się, że rt po przeniesieniu z postgresa 7.4 na 8.1 działa dużo szybciej, więc stwierdziliśmy, że zrobimy testy. postawiliśmy testowe rt, wgraliśmy mu produkcyjną bazę. po czym odpaliliśmy testy z użyciem fajnego narzędzia: tsunga. kolega który robił testy (hi, filip 🙂 zrobił scenariusz testowy:
- wejście na stronę logowania
- zalogowanie (i wyświetlenie strony głównej)
- wejście w losową kolejkę
- wyświetlenie losowego ticketu
- wylogownie
łącznie 5 ekranów. zrobił (filip) testy. mysql – 15 sekund. postgres 8.1. – 30 sekund. postgres, ale z dodatkowymi indeksami podpowiedzianymi przez jakiegoś znajomego – 17 sekund. no cóż. kiepsko. nic to. patrzymy co dalej. i tu pojawia się gwódź programu. kto z was zganie ile zapytań do bazy danych wykonało rt po przejściu 100 razy scenariusza testowego (czyli łącznie 500 stron wygenerowane). no? chętni? 1000? 2500? 5000? nie. prawdziwa ilość wykonanych zapytań to: 145937! czyli prawie 300 zapytań *na stronę*! nic dziwnego, że to wolno działa. filip ma napisać (może już napisał?) do best practical z prośbą o wyjaśnienia. ciekawe czy czegoś się dowiemy …
tapeta na dziś
po wczorajszej tapecie, dziś pora na coś lżejszego 🙂 nadal deviantart, ale z naciskiem na art 🙂
