Krótki techniczny wywiad z Piotrem Karwatką odpowiedzialnym za kod nowej wersji blogfroga.

N: Jakie frameworki były brane pod uwagę przed przystąpieniem do pisania nowego BlogFroga i dlaczego został wybrany CodeIgniter?

PK: Po ostatecznym wyborze PHP 5 jako platformy, myślałem o kilku popularnych zrębach – m.in. Zend, Agavi, Cake PHP. Czynnikiem decydującym o wyborze CI okazała się jego szybkość i mały narzut (wygrywał wszystkie benchmarki jakie udało mi się wtedy wyszukać). CodeIgniter nie jest tak kompleksowym rozwiązaniem jak inne dostępne biblioteki – ale odbieram to jako jego zaletę. Programista otrzymuje pomoc w rozwiązaniu większości powtarzających się problemów, a jednocześnie nadal ma dużą kontrolę. Przy blogfrog.pl CI wystarczył w zupełności do implementacji frontowej strony – dopisać należało tylko kontrolki cacheujące (wykorzystałem Zend_Cache ze względu na jego dużą elastyczność) oraz dodać obsługę logowania użytkowników której CI domyślnie nie obsługuje.

N: Co zostało użyte do napisania backendu (robot) i dlaczego?

PK: Do pisania robota wykorzystałem niektóre z bibliotek wchodzących w skład Zend_Framework (tj. Zend_Cache, Zend_Feed), obsługi bazy danych PDO oraz indeksu wyszukiwania SPHINX Search. W pierwszej wersji blogfrog korzystał z parsera MagpieRSS – w nowej postawiłem na Zend – wydaje mi się dużo bardziej elastycznym rozwiązaniem oraz bardziej stabilnym – nie ma też problemu z uzyskaniem supportu. PDO jest powszechnie uważane za najszybszą bibliotekę do obsługi baz danych w PHP – po pracy nad spiderem wydaje mi się, że to prawda Zend_Cache pomaga spiderowi natomiast nie pobierać wiele razy tych samych danych, co jest szczególnie ważne przy dużej ilości feedów do sprawdzenia – wybór ze względu na elastyczność i stabilność/wsparcie rozwiązania. Co do indeksu wyszukiwania początkowo chciałem użyć Lucene w implementacji Zenda. Niestety okazało się, że jest to rozwiązanie strasznie wolne, głównie przez implementację w czystym PHP. Dlatego skorzystałem ze Sphinx Search. Silnik ten potrafi indeksować do 10MB tekstu na sekundę, a średnie wyszukiwanie trwa 0.001 s Dodatkowo autor sphinxa zapewnia niesamowity support tego rozwiązania – przy jego pomocy wraz z administratorem rozwiązaliśmy problem m.in. z NFS w ciągu… 2 godzin. Myślę, że nikt inny nie zapewniłby nam takiego wsparcia, które jest potrzebne przy serwisach o krytycznej dostępności.

N: Jak CI sprawdza się w zakresie wydajnościowym? Ile serwerów obsługuje ten projekt?

PK: CI sprawdza się bardzo dobrze, ponieważ ma mały narzut. Wąskie gardło tego rodzaju serwisów to operacje bazodanowe – które staram się cacheować. Blogfrog jest utrzymywany aktualnie na 2 serwerach połączonych w mini cluster i zostaje mu spory zapas mocy. Głównym problemem wydajnościowym nie była strona główna tylko robot – który musi zapewniać świeże notki na stronę. Robot był projektowany i pisany z myślą o minimum 10 000 blogów. Przeskanowanie 2000 blogów zajmuje aktualnie ok 1. minuty – a mam jeszcze kilka pomysłów jak to można przyspieszyć. Myślę, że najważniejsze to pamiętać o wydajności od samego początku projektowania, a potem podczas programowania i ciągle testować wybierane rozwiązania – wtedy głowa nie będzie bolała

N: Bogatszy o wiedzę nabytą podczas pisania BlogFroga możesz poradzić innym programistom na co warto zwrócić uwagę?

PK: Warto spoglądać na problem z różnych perspektyw i zadawać samemu sobie “trudne pytania” – jeśli coś nie korzysta z wielowątkowości do przyspieszenia działania – pytanie dlaczego i co stanie się gdy z tego skorzystamy; co z cachem itd.
Aby system działał optymalnie nie można przypominać sobie o wydajności na końcu – trzeba o niej pamiętać na każdym kroku i optymalizować co tylko się da (oczywiście gdy to coś już działa). Dobrze jest posługiwać się metodą “pocisków smugowych” w tworzeniu oprogramowania tego typu – pozawala łatwiej trafić w potrzeby użytkowników. Warto stawiać na proste rozwiązania które zapewniają nam to co potrzebujemy, a nie więcej

–

Piotrku dzięki za poświęcenie czasu na odpowiedź. Ktoś ma jakieś pytania? Zapraszam do komentarzy.

Muszę się spieszyć – Marcin wraca jutro z urlopu, a ja już od 2 tygodni obiecuje mu, że napisze coś o zicherce na blogu Jak widać strasznie opornie idzie mi to blogowanie, ale do rzeczy.

O zicherce było już trochę w necie, choćby na PiO lub Antywebie więc postaram się dostarczyć wam nieco innych informacji. Jako, że to podobno jest devblog (średnio mi to wychodzi) to będzie trochę technicznych aspektów tego projektu.

Pomysł na serwis mieliśmy jeszcze w ubiegłym roku. Ja myślałem o serwisie mojego miasta (Tychy), a Marcin o społeczności Katowic. Szybko doszliśmy do wniosku, że Tychy i Katowice to trochę za mało, a tworząca się Silesia dała nam motywację do objęcia zasięgiem całego śląska i zagłębia. Silesia to ponad 2 miliony mieszkańców, a całe województwo śląskie liczy ich 5 milionów.

Serwis zaczął powstawać gdzieś w okolicach lutego-marca (sam już nie pamiętam dokładnie) lecz niestety wszystko tworzyło się dosyć opornie, głównie z powodu pracy na odległość oraz braku konkretnej, zapiętej na ostatni guzik listy funkcji serwisu. W tworzenie zicherki zaangażowane były 3 osoby, każdy z nas w międzyczasie miał masę innej roboty i tym sposobem projekt tworzony “po godzinach” zyskiwał już nie dni i tygodnie, a niestety miesiące

Technicznie: zicherka działa na autorskim frameworku (php5) Marcina, wykorzystuje JavaScriptową bibliotekę jQuery, ma wbudowany cache wielu elementów serwisu. Chwilowo stoi to na serwerze z Apache ale plany są takie aby docelowo to przenieść na Lighttpd albo Nginxa. Panel admina (dla sportu ) jest pisany w django (Python), jednak mamy wrażenie iż ten, swoją drogą bardzo dobry, framework jest nieco przereklamowany. Z naszych obserwacji wynika, iż musielibyśmy rozszerzyć “na dzień dobry” co najmniej połowę modułów z django (zaczynając od sesji, a kończąc na takich drobnostkach jak paginacja) aby dojść do funkcjonalności jaką nam zapewnia nasz framework w PHP. W każdym razie migracja na django jest możliwa, aczkolwiek zależna od tego co się będzie działo z serwisem w najbliższych miesiącach (rozwój, inwestycje).

Funkcyjnie: jest to serwis o wiele bardziej rozbudowany niż przytaczany często jako przykład wrocek.pl. Sporą różnica jest choćby system edycyjny, który można porównać z tym z wiki (edycja przez wielu użytkowników, przywracanie poprzednich wersji wpisu w przypadku pomyłki lub wandalizmu), czy choćby zaczątki personalizacji (wyszukiwanie grup, ludzi, miejsc i wydarzeń zbieżnych z zainteresowaniami użytkownika). W przygotowaniu są kolejne funkcje, których nie znajdziecie w innych tego typu serwisach

Co dalej? Przede wszystkim poprawienie znalezionych błędów obecnej wersji; wprowadzenie funkcjonalności, która jest już napisana i czeka na przetestowanie; poprawienie wyglądu, użyteczności wg. potrzeb użytkowników; znalezienie poważnego inwestora (zgłosiło się kilka firm, prowadzone są trudne rozmowy).

Brak notek oczywiście jest spowodowany moją codzienną ciężką pracą nad kilkoma nowymi serwisami. Właściwie robie 4 nowe serwisy na raz bo podstawa jest wspólna.

Jak na razie skończyłem pisać tego wrednego session-handlera, za którego brałem się “od dupy strony”. Sesje są oparte na MySql, w bazie trzymam sobie standardowe dane o userze i dane sesyjne. Muszę tu jeszcze dopisać obsługę botów ale to taki bajer na przyszłość. Całość daje mi przynajmniej 2 pytania do bazy (jeden SELECT/jeden INSERT lub UPDATE), raz na 100 wywołań odzywa się funkcja _gc (garbage collector) i kasuje stare sesje. Dodatkowo jeden SELECT sprawdza kto jest online ale szkoda pytanka na taką bzdurę więc to będę sobie keszował co np. 10 minut. Ogólnie na pojedyńczą podstronę wychodzi w sumie 4-6 pytań i mam nadzieję, że nie zajadę tym hostingowego MySqla przy początkowych 3k-5k UU dziennie (potem przesiadka na dedyka więc to będzie zupełnie inna bajka).

Za layer bazy robi opisywane wcześniej Creole. Polubiłem je, dorobiłem mały benchmark zapytań (liczba pytań, jakich, poszczególne czasy, suma itp.).

Jesli chodzi o szablony to wybrałem polskie OPT. Są na prawdę fajne, mają wszystko czego potrzebuje no i można liczyć na polski support. To ważne bo niestety dokumentacja troche kuleje, ale jak ktoś już wcześniej pracował przy Smarty to nie powinien mieć większych problemów.

Dzisiaj musze się zająć grupami i prawami tych grup/userów. Obejrzałem sobie kilka przykładowych rozwiązań i nadal nie wiem jak to ugryźć wedle moich potrzeb. Zaraz zrobie sobie kawkę i rozrysuje sobie to na kartce. Bez tego ani rusz. Już tak mam, że jak czegoś nie widzę to potem sie gubię

Reasumując: z postepu prac jestem zadowolony aczkolwiek mogłoby to mi iść szybciej. Poza tym fajnie, że zacząłem pisać trochę obiektowo, używam klas itp. ale nadal ten kod to jest pomieszanie z poplątaniem. Jeden wielki śmietnik Grunt, że działa i dobrze, że tego kodu nie widać na zewnątrz

Niestety, przez parę najbliższych dni nie będzie notek Bardzo mocno pracuje nad nowymi serwisami, właściwie siedzę przy PHP 10-12h dziennie i nic tylko stukam i stukam. A najwięcej to czasu człowiek traci na szukanie banalnych błędów. Dzisiaj jedną rzecz napisałem w godzinę, w tym 10 minut trwało napisanie samej funkcji, a 50 minut zastanawianie się dlaczego nie działa

W tej chwili kończe pisanie własnego session-handlera opartego na bazie danych (obecnie MySQL, ale wszystko obsługuje Creole). Muszę jeszcze tylko dopisać rozpoznawanie botów ( w tej chwili działa już _read,_write, _gc oraz obsługa guesta i zarejestrowanego usera) i będzie chyba koniec. Wzorowałem się na sesjach z k4bb bo tam to wszystko jest ładnie napisane Zastanawiam się tylko na cholere mi pole user_agent i czy na pewno uzależniać sesje od jednoczesnego sprawdzenia session_id i user_ip. User_agent może by miał jakiś sens jakbym chciał kombinować uwierzytelnianiem z cookies, ale skoro wszystkim zajmie się samo PHP to chyba to pole będzie zbędne. Nie zauważyłem do czego używa go autor k4bb.

Po raz n-ty mam problem co ostatecznie wybrać na system szablonów do moich nowych (w miarę dużych) aplikacji w php.

• Smarty – za duże, za wolne, ogromna kobyła z mnóstwem niepotrzebnych bajerów, których człowiek w zasadzie nigdy nie używa.
• Smarty-light – odchudzona wersja Smarty, właściwie ma wszystko czego potrzeba i jest bardzo szybka. Niestety największym problemem jest brak czegoś w rodzaju < % no cache %>, tak aby nie “keszować” dynamicznych fragmentów stron. Pisałem w tej sprawie do Autora i dostałem odpowiedź, że taka funkcja nie jest planowana, a problem można obejść drobnym trikiem. Niestety ten “drobny” trik jest wyjatkowo uciążliwy (rejestrowanie każdorazowo funkcji do obsługi poszczególnego elementu) i nie nadaje sie do zastosowania w przypadku naprawdę dużego i dynamicznego serwisu. Szkoda. Smarty-light z powodzeniem użyłem w kilku mniejszych projektach i jestem z nich zadowolony. Jakby ktoś mądrzejszy ode mnie wiedział jak inaczej obejść ten problem to proszę o info!
• własny system – nie wchodzi w grę. Po pierwsze jestem za słaby na to, po drugie napisanie tego zajęło by mi masę czasu, a ja już muszę otwierać kolejne serwisy zamiast wymyślać coś nowego.
• Savant – nie przekonuje mnie Brak cache – trzeba użyć coś dodatkowego.
• Polskie OPT – niestety tylko PHP5, a który serwer teraz to ma? Wygląda ciekawie, przyjrze się dokładniej temu projektowi. Edit: hmm, po wstepnym przejrzeniu dokumentacji OPT wygląda wyjątkowo ciekawe. Musiałbym jeszcze dorwac jakieś testy szybkości. Niestety dokumentacja, zarówno polska jak i angielska, nie jest jeszcze pełna a strona projektu siedzi na jakimś porąbanym Mambo

Aaaa i dalej nie wiem za co się brać…