Za napisanie czegoś w tym temacie zabierałem się dobre kilka lat 
Uznawałem do tej pory, że lepiej nie wdawać się w długie dyskusje tylko dalej robić swoje i po swojemu. Jednak coraz częściej spotykane, wręcz euforyczne komentarze na temat różnych gotowych rozwiązań w PHP skłaniają mnie do dodania łyżki dziegciu do tej beczki miodu…
Bez dwóch zdań, PHP to lider w tematyce tworzenia stron www. Za popularnością idzie również wzrost aplikacji open source, których w świecie PHP jest zatrzęsienie. Gdyby tak na nie wszystkie spojrzeć to można byłoby dojść do wniosku, że tworzenie stron www stało się bajecznie proste i bardzo szybkie, przecież dla każdego elementu strony mamy setkę różnych darmowych rozwiązań. Tylko czerpać garściami…
Szybko się jednak okazuje, że nie ma tak różowo. Bez względu na to czy mówimy o rozbudowanych systemach CMS czy o frameworkach to zawsze powtarzają się te same główne problemy:
- Wydajność
- Zbyt dużo elementów, których nie potrzebujemy a które są uruchamiane…
- … natomiast nie ma tego co dla nas jest najważniejsze lub jest ale nie spełnia naszych wszystkich oczekiwań
- Obciążające mechanizmy, które mają za zadanie dostosować aplikację do wszystkich popularnych serwerów, rozwiązań itd. a Tobie nigdy się nie przydadzą
- Musisz się uczyć nowego oprogramowania, czasami jest tyle zasad, komend i funkcji do zapamiętania, że przybiera to rozmiary małego języka programowania
Oczywiście lista wad zależy od naszych potrzeb i oczekiwań. Przy malutkim projekcie mało kto zwraca uwagę na wydajność. Przy typowym projekcie bez żadnych szczególnych wymagań zadowolimy się gotowymi modułami, które są dostarczone razem z CMS’em. I tak dalej… Z drugiej strony czy potrzebujemy wytaczać tak ogromne działa jak np. Drupal do strony jakiejś firmy gdzie będzie maksymalnie 10 podstron? I jak często projekty, które tworzysz są tak typowe, że zadowalasz się gotowymi modułami do CMS’a i nic już w nich nie musisz zmieniać?
Nie byłbym obiektywny gdybym widział w gotowych rozwiązaniach tylko same wady. Podstawowe zalety to:
- Dobra (przeważnie) dokumentacja
- Duża społeczność gdzie wielu służy Ci pomocą gdy masz problem i jednocześnie możesz szukać pracownika/współpracownika, który nie zgubi się w Twoich projektach bo korzysta z tego samego oprogramowania
- Sporo gotowych rozwiązań, których można używać lub się na nich uczyć
- Bezpieczeństwo
- Łatwość programowania
Jak widać, gotowe rozwiązania mają się czym bronić.
Dokumentacja, jaka by nie była to i tak jest lepsza od tej, którą Ty masz na starcie w swoim autorskim rozwiązaniu (a nie masz żadnej póki sobie jej sam nie stworzysz).
Społeczność i spore grono już „wyszkolonych” pracowników to też zaleta. Chociaż z tymi specjalistami to też nie jest tak różowo bo najczęściej brakuje takich, którzy już umieją dobrze sobie radzić z danym narzędziem i trzeba ich i tak douczać. A nawet jak są to się cenią…
Gotowe moduły to fajna rzecz. Niestety i tutaj jest się do czego przyczepić. Często są źle zaprojektowane, niechlujnie napisane, powodują zwiększone obciążenie, mają w sobie furtki dla włamywaczy a na ich podstawie możemy się jedynie nauczyć jak NIE programować. Nie będę jednak tak krytyczny, zdarzają się prawdziwe perełki a duża część trzyma poziom.
Bezpieczeństwo: z jednej strony błędy są szybko wychwytywane przez społeczność i developerów, z drugiej główny kod Twojej strony, tzw. „silnik” jest dostępny dla każdego i każdy teoretycznie może tam wyszukać lukę lub skorzystać z gotowej instrukcji jeżeli na czas nie załatałeś strony oficjalną łatką. Jednocześnie jednak CMS’y i frameworki najczęściej mają mechanizmy, które pilnują programistę aby nie potworzył furtek dla włamywaczy a w Twoim własnym oprogramowaniu sam się musisz pilnować lub pisać samemu mechanizm zabezpieczeń. Jeszcze inaczej podchodząc do tematu, w Twojej aplikacji może być luka ale jest niewielkie prawdopodobieństwo, że ktokolwiek na nią trafi i ją wykorzysta bo nikt nie ma Twoich kodów źródłowych Chociaż to nie jest oczywiście najlepsze z możliwych podejście do bezpieczeństwa…
Z łatwością programowania to już jest bardzo różnie… Takie są ogólne zasady powstawania gotowych narzędzi: ułatwiać życie programiście. Nie zawsze jednak cel jest osiągany. Nie da się jednak zaprzeczyć, że wraz z gotowymi rozwiązaniami dostajemy często moduły np. do łatwego testowania i debugowania naszych aplikacji. We własnych projektach jest z tym dużo gorzej.
Czas na kilka przykładów z życia. Pierwszy raz na blogu odniosę się do mojej ponad rocznej pracy z systemem Drupal. Nie byłem z tego wyboru jakoś wielce zadowolony chociaż rozumiałem argumenty dlaczego go wybrano w firmie. Nasz największy projekt od dnia startu do pierwszej wersji beta pochłonął kilka miesięcy pracy dwóch programistów. Dodajmy uczciwie, że cały czas uczyliśmy się tego CMS’a. Efektem była całkiem sympatyczna aplikacja i kilkadziesiąt naszych autorskich modułów. Nie wszystko jednak wyglądało tak jak powinno… To co zaliczyłbym do wad:
- Miesiące nauki a i tak co chwila napotykaliśmy na problemy (a chyba tacy głupi nie jesteśmy… )
- Niektóre rzeczy napisalibyśmy w godzinę ale głowiliśmy się kilka dni jak to ugryźć w Drupalu przez narzucone przez niego ograniczenia
- No właśnie, ciągle ograniczenia i ograniczenia. Jasne zasady i standardy są dobre ale nie można przesadzać…
- Wydajność… a raczej jej brak
- Co z tego, że jest dużo gotowych rozwiązań skoro i tak wiele z nich musieliśmy poprawiać i dostosowywać do swoich potrzeb
Odniosę się tylko do wydajności bo cała reszta jest raczej jasna (a w szczegóły wchodzić nie ma sensu bo to nie wpis o Drupalu). Nie wiem dokładnie jak obciążony był serwer naszą aplikacją ale z pewnością bardzo i od początku były z tym problemy. Gdy pierwszy raz sprawdziliśmy ile zapytań do bazy danych generuje strona główna to mało nie spadłem z krzesła. Ponad tysiąc dwieście! Specjalnie napisałem słownie żeby nie było wątpliwości, że się nie pomyliłem Po optymalizacjach wyszło ponad 700. W Drupalu były włączone standardowe mechanizmy cachowania itp. Nie wiem czy i jak sobie z tym poradzili, wkrótce potem zająłem się innymi sprawami. Te liczby są porażające… Odnosząc się do moich autorskich rozwiązań strona główna nasztomaszow.pl generuje dziennie kilkadziesiąt zapytań do bazy. Dziennie! Kilkadziesiąt! I to bez względu na to jak duży ruch jest na stronie z racji sprytnego systemu cachowania. Poza nawiasem dodam, że standardowy system cachowania w Drupalu jest oparty o… bazę danych. Nie wiem czemu tak, może ja się nie znam i tak jest najwydajniej
Po tamtych doświadczeniach wiedziałem już, że mój następny projekt oprę o własne rozwiązania. Tak się składa, że NaszTomaszow.pl (a o nim właśnie mowa) można śmiało porównywać z opisywaną aplikacją w Drupalu. Obie mniej więcej odpowiadają za to samo – za prowadzenie/obsługę portali miejskich. O liczbie zapytań do MySQL strony głównej już pisałem. Niestety nie pamiętam już jakie wyniki generował XDebug dla witryny w Drupalu natomiast praktycznie goła instalacja tego CMS’a generuje się u mnie w średnio 700ms. Jak na tym tle wygląda mój system? Stronę główną NaszTomaszow.pl parser wypluwa w około 45ms. Czystą instalację w 15ms.
Zrobiłem inne testy*. Sprawdziłem jak szybko generują się strony we frameworku Yii (podobno bardzo wydajny), przetestowałem system forum IPB i CakePHP. Wiem, że to nie jest jakaś super reprezentatywna grupa ale są to raczej popularne skrypty a ja zrobiłem testy tylko z ciekawości a nie aby badać cały rynek 
Oto wszystkie wyniki:
- Yii (przykład blogu z oficjalnej paczki) – średnio 650ms
- forum IPB (konfiguracja z NaszTomaszow.pl, forum puste) – średnio 420ms
- CakePHP (czysta instalacja, tuż po wypakowaniu z oficjalnej paczki) – średnio 790ms
- Drupal (malutka, prosta stronka, baza praktycznie pusta) – średnio 700ms
- Mój system (na podstawie aktualnej wersji plików i bazy NaszTomaszow.pl) – 45ms
- Mój system (czysta instalacja) – 15ms
Czy więc odradzam korzystanie z gotowców? Nie, zdecydowanie nie. Sam przecież czasami stawiam coś na Drupalu a ten blog oparty jest o WordPress’a. Warto poznać popularne rozwiązania open source, chociażby po to żeby móc mówić o ich wadach. Przy pracy z nimi zdobędziesz też wiele doświadczenia i odkryjesz ciekawe rozwiązania wielu problemów. Czasami ich wybór jest jedynym słusznym rozwiązaniem.
Ten artykuł jest bardzo lakoniczny, może nawet ktoś uzna, że amatorski. Nie chciałem porównywać konkretnych systemów, głosić jedynej słusznej teorii i nawracać niewiernych. Chciałem przypomnieć Ci, że nic nie zastąpi zdrowego rozsądku. Pogódź się z tym, że nie ma idealnych narzędzi. Zawsze to Ty musisz się wykazać znajomością problematyki i przewidzieć na jakie problemy możesz się natknąć oraz wykazać jakie rozwiązania będą efektywniejsze i spełnią Twoje założenia. Czasami potrzebna jest ekstremalna wydajność, czasami najważniejszy jest czas oddania projektu, innym razem masz wieloosobowy a może nawet międzynarodowy zespół. Czynników, które powinny wpływać na Twoją decyzję co do wyboru oprogramowania są dziesiątki.
Przypominają mi się w tej chwili stare wojny np. programowanie strukturalne versus obiektowe. Zawsze to co nowe podbijało szybko serca programistów, przychodził jednak czas opamiętania i rozsądek podpowiadał wtedy starą prawdę: stosuj wedle zapotrzebowania.
* Wszystkie testy były banalnie proste. Uruchomiony XDebug, wyniki odczytywane za pomocą WinCacheGrind, kilkanaście prób i wyciągnięta średnia.
EDIT 14.06.2010
Postanowiłem dzisiaj sprawdzić jak wydajnościowo mają się dwa frameworki, którymi jestem szczególnie zainteresowany. Oto uzupełnienie powyższej listy:
- Symfony (przykładowa paczka Sandbox) – średnio 680ms
- Zend Framework (oficjalne aplikacje demo) – średnio 365ms
Takiego właśnie wyniku Symfony się spodziewałem. Słyszałem narzekania na jego wydajność. Paczka Sandbox to, o ile dobrze przeczytałem, wstępnie skonfigurowane Symfony. Na tle Drupala, który po instalacji ma już wiele gotowych elementów do zaoferowania nie wygląda to imponująco (chociaż po ponad rocznej pracy z Drupalem i pięciu minutach w dokumentacji Symfony chyba w tym drugim, jako programista, czułbym się lepiej ).
Testując Zend Framework skorzystałem z gotowych aplikacji demo, które znalazłem w paczce. Zdarzały się dużo lepsze czasy niż powyżej zaprezentowana średnia (poniżej 200ms a nawet poniżej 50ms) ale powiedzmy sobie szczerze, ile może trwać wyświetlenie jednego formularza? Dlatego wybrałem dwie czy trzy trochę bardziej wymagające wersje demo i na nich oparłem wyniki testu. Ciekaw jestem jak wyglądałyby wyniki np. przy jakimś prostym systemie newsów.
Jak zmienić IP w Multimedia Polska? 
Blog przede wszystkim o Internecie i mojej pasji jaką jest tworzenie stron www. Ale nie ograniczam się do jednej tematyki, piszę o wszystkim o czym mam ochotę :-)