Nie ukrywam, że notka została zainspirowana ostatnim postem na The Daily WTF. Podobną sytuacje mieliśmy całkiem niedawno w pracy.
Jako project lead
systemu CMS wego, mam dość napięty harmonogram i całość mocy przerobowych firmy jest przeze mnie zaangażowana w rozwój tegoż systemu właśnie. W związku z tym, kiedy pojawił się klient, który wymagał indywidualnego rozwiązania, zadecydowano, że zlecenie zostanie outsource'owane, a realizacja przebiegnie poza firmą.
Nie byłoby w tym nic dziwnego, gdyby nie fakt, że po kilku dniach dowiedzieliśmy się, że aplikacja zostanie zbudowana w oparciu o eZ publish — system bardziej enterprise'owy niż statek kosmiczny bohaterów Star Treka. Wcześniejsze doświadczenia z refaktoryzacją aplikacji budowanych na eZ bynajmniej nie przepełniały mnie optymizmem, ale byłem mimo wszystko dobrej myśli — co prawda, już raz zdarzyło mi się przepisywać aplikację oryginalnie opartą na rzeczonym środowisku na wersję standalone, bo wydajność okazała się kwestią krytyczną, ale z całą pewnością w ciągu ostatniego roku eZ się rozwinął. Niczym Bogusław Wołoszański, powinienem teraz powiedzieć tego dnia nie mogli jeszcze przypuszczać, że już za dziesięć dni, w biurze obok, odbędzie się spotkanie, które odwróci bieg historii.
W dziesięć dni później pojawił się bowiem wdrożeniowiec, specjalista od pewnego systemu, którego domena macierzysta mówi wszystko (easy? no!). Rzeczona aplikacja została zbudowana w czasie, który nazwano rekordowym
(choć jej oparcie na frameworku typu Cake z pewnością zaowocowałoby skróceniem tego czasu, jak i oszczędzeniem nam kolejnych kłopotów, ale o tym za chwilę). Przyszedł czas na prezentację. Przygotowania chyżo ruszyły, a specjalista — niczym rączy rumak — wyrwał z kopyta i zatrzymał się na najbliższym słupie. Okazało się bowiem, że nasza wersja PHP jest zbyt nowa. eZ nie działa z PHP5 i tyle, żadna siła boska ni świecka do kooperacji go nie zmusi. Co prawda, wymaga MySQL5, ale parsera oczekuje prehistorycznego.
W 24 roboczogodziny później (Qwiat, jako admin, się specjalnie nie nudzi i bez takich kwiatków), system został uruchomiony. I dnia trzeciego zobaczył Pan, że aplikacja klika i było to dobre.
Chciałoby się powiedzieć, że wszystko śmiga,
ale byłoby to wyjątkowo niecelne sformułowanie. Strony serwisu potrzebują około sekundy na wyświetlenie. Pod jednym warunkiem — że znajdują się w cache. Jeśli się jednak przedawnią, na radość podziwiania kilkudziesięciu linijek HTML przyjdzie nam czekać dokładnie 35 sekund. Na serwerze, gdzie znajduje się kilkaset serwisów, w tym znacznie bardziej skomplikowane rozwiązania, które — bez użycia cache dla danych z bazy — radzą sobie w dobrze poniżej pół sekundy.
Cóż na to można zaradzić? Wdrożeniowiec zalecił instalację eAcceleratora i rekompilację MySQL z parametrami podanymi na stronie eZ publish.
Pewnie, a potem zakup dedykowanego serwera. eAccelerator przyspieszył proces generowania strony o całe 3 sekundy, druga sugestia trafiła wprost do /dev/null. Ale czegóż można się spodziewać po aplikacjach z enterprise
w sloganie marketingowym?
Zapomniałem wspomnieć, że w sytuacji, gdzie wszystkie vhosty mają ustawiony limit pamięci na nie więcej niż 12 8 MB, nasz system na eZ z rozkoszą poprosił o 50 MB żeby się w ogóle uruchomić. Boję się sprawdzać, jak wygląda diagram przepływu sterowania w kodzie, ale na usta ciśnie się cytat z komentarzy do wspomnianego posta na The Daily WTF:
It forgets the steps where it prints an image of the transactions and then scans them on a desktop to get the wood border.
Technorati Tags: ez cms software web enterprise