Dzisiejszy wpis będzie zapisem moich dywagacji na temat używania frameworków w małych projektach, tak dla odmiany. Chciałbym poruszyć tę kwestię, gdyż wydaje się to być dosyć duży problem. Oprę się na danych pochodzących z małej aplikacji opartej na Zend Frameworku oraz stronie Linux.Eazu.pl(projekt zawieszony, ponieważ treść odnosi się do już dosyć starej wersji Ubuntu). W pierwszym przypadku dane nie będą się różnić zbytnio od pomiarów na „czystym” Zendzie, w drugim zaś wszystko napisane zostało obiektowo, z użyciem systemem szablonów praktycznie identycznym, jak ten z mojego artykułu pod tytułem „(Bardzo) prosty system szablonów”. Różnicą w obydwu aplikacjach jest typ zastosowanej bazy danych, gdyż w Zendzie oparłem się na MySQLu, a w poradniku o Linuksie na SQLite. Mimo wszystko nie zrobi to wielkiej różnicy, kiedy zobaczymy różnicę w danych.
Pomiary
Zastanawiając się nad zasobożernością Zend Frameworka w porównaniu do aplikacji pisanych od podstaw, postanowiłem wykonać dwa pomiary: użycia pamięci i czasu wykonywania się skryptu. Testy robione były na różnych serwerach, lecz ten słabszy(z aplikacją ZF) nie był w ogóle obciążony, więc fakt ten nie „gra tutaj dużej roli”. Obydwa posiadają podobną konfigurację, która, według mojego rozpoznania, nie spowodowała widocznego sfałszowania wyników. W obydwu przypadkach PHP był uruchamiany w trybie FastCGI na Apache’u. Poniżej zamieszczam dane, które uzyskałem. Oczywiście są one uśrednione na podstawie wielu żądań.
Aplikacja na Zend Frameworku
Użycie pamięci: 1700 kB
Czas wykonywania: 550 ms
Linux.Eazu.pl
Użycie pamięci: 190 kB
Czas wykonywania: 7,5 ms
Jak widać różnica jest znaczna. O ile ilość używanej pamięci w dzisiejszych czasach możemy praktycznie pominąć, o tyle czas zajętości procesora jest już bardzo ważny. Warto jeszcze dodać, że Zend ładuje do pamięci ponad 120 plików.
Wahania ekonomiczne
Jak widzimy powyżej, serwer, w przypadku użycia aplikacji opartej na Zend Frameworku, będzie obciążony dużo bardziej. Wiele osób mi powie, że no dobrze, ale praca z frameworkami jest dużo wydajniejsza pod względem czasu pracy nad projektem. Oczywiście, wszystko się zgadza w przypadku dużych projektów, ale możemy coraz częściej zauważyć fakt używania ich w projektach pokroju wizytówek. W takim przypadku wręcz śmiało mogę użyć stwierdzenia, że tworzenie chociażby, już wspomnianych przeze mnie, wizytówek na frameworkach się nie opłaca. Spójrzmy chociaż na pewien prosty przykład: istnieje sobie na rynku firma, która tworzy klientom wizytówki, które utrzymuje na swoim serwerze. Zastanówmy się teraz: co się im bardziej opłaca: użyć frameworka i na jednym serwerze „postawić” znacząco mniejszą liczbę stron, czy jednorazowo poświęcić kilka dni na niezbyt trudną pracę i osiągnąć ten sam efekt przy większej oszczędności zasobów i w efekcie pieniędzy? Myślę, że odpowiedź na to pytanie jest prosta. Z drugiej strony ktoś może mi zarzucić: „no tak, ale przecież np. Zend Framework jest rozwijany przez wiele osób, mamy wtedy mniejsze szanse na bugi w Naszym projekcie”. Fakt jest faktem, że może w większych aplikacjach może to być kluczowa kwestia, aczkolwiek w małych i prostych projektach szansa na tego typu błąd jest naprawdę mała.
Średnie i duże projekty
Sprawa ma się inaczej w przypadku dużych i średnich projektów. Tutaj kwestia „użyć czy nie użyć” frameworka nie jest taka prosta. W takim wypadku musimy się porządnie zastanowić, czy to się Nam po prostu opłaca. W przypadku, kiedy nad kodem będzie pracowało wiele osób, raczej wyboru nie mamy, gdyż gotowy framework Open Source daje Nam solidną i udokumentowaną platformę, która znacząco zmniejszy koszty stworzenia gotowej aplikacji. Niestety nie da się wyznaczyć stałej granicy, kiedy przestaje się Nam opłacać korzystanie z frameworka, gdyż każdy projekt jest specyficzny.
Notka
Powyższy artykuł oczywiście jest tylko moją subiektywną opinią. Chętnie poznam Wasze zdanie na ten temat.
 | Za ten artykuł podziękowano 0 raz(y). Chcesz i Ty ? |
4 Comments
A co jeśli będziesz chciał za jakiś czas powiększać i rozbudowywać tak prostą stronę? Najpierw dojdzie konieczność pisania własnych funkcji obsługi Web Services, później dojdzie obsługa SMTP i IMAP, potem klasy do tworzenia i walidacji formularzy, itp itd.
Warto pomyśleć o przyszłości, zanim się zacznie pisać w czystym PHP – by potem nie musieć dalej się męczyć w czystym PHP i wszystko pisać od początku, lub by nie przepisywać aplikacji od nowa.
Btw. do małych projektów wykorzystuję Yii PHP Framework.
„O ile ilość używanej pamięci w dzisiejszych czasach możemy praktycznie pominąć, o tyle czas zajętości procesora jest już bardzo ważny ”
Przejrzalem watki na blogu i zainteresowalem sie nim jednak dziwi mnie to odwazne stwierdzenie z Twojej strony. O zasoby pamieci jak najbardziej trzeba dalej dbac wyobraz sobie niezoptymalizowany skrypt PHP ktory buduje listy rekordow, podlicza ilosc kategorii danych rekordow gdy uzwa sie mysqla i natywnych funkcji/petli do pobierania danych jedna sesja moze na chwile obciazyc serwer nawet na kilka-kilkanascie MB, na zwyklych serwerach hostingowych wykancza to caly limit (8-16 MB) i w efekcie jest ona niedostepna dla innych uzytkownikow i na VPS z iloscia pamieci 256-512 MB przy wiekszej liczbie odwiedzajacych rowniez.
Co do sensownosci uzywania frameworkow (i jakich konkretnie warto uzywac) przy malych projektach pisanych od poczatku liczylem na wieksze zglebienie sie w problem jak kiedys bardziej sie rozpiszesz chetnie przeczytam :)
Moim zdaniem używanie fm nawet w małych projektach nie jest czymś złym. Pozwala na szybkie postawienie strony i późniejszy łatwy jej rozwój. Obciążenia nie są aż tak ogromne, mechanizmy cache dostępne praktycznie w każdym fm zniwelują obciążenie serwera. Tak więc – uważam, że nie ma nic złego w używaniu fm w małych projektach.
Może do małych projektów stosować prostsze fm, np CodeIgniter albo Fuel. Wszystko zależy od perspektyw rozwojowych projektu, wytaczanie takiego działa na mały projekt nie ma sensu.