Nie ukry­wam, że notka została zain­spi­ro­wana ostat­nim postem na The Daily WTF. Podobną sytu­acje mie­li­śmy cał­kiem nie­dawno w pracy.

Jako pro­ject lead sys­temu CMS wego, mam dość napięty har­mo­no­gram i całość mocy prze­ro­bo­wych firmy jest przeze mnie zaan­ga­żo­wana w roz­wój tegoż sys­temu wła­śnie. W związku z tym, kiedy poja­wił się klient, który wyma­gał indy­wi­du­al­nego roz­wią­za­nia, zade­cy­do­wano, że zle­ce­nie zosta­nie outsource’owane, a reali­za­cja prze­bie­gnie poza firmą.

Nie byłoby w tym nic dziw­nego, gdyby nie fakt, że po kilku dniach dowie­dzie­li­śmy się, że apli­ka­cja zosta­nie zbu­do­wana w opar­ciu o eZ publish — sys­tem bar­dziej enterprise’owy niż sta­tek kosmiczny boha­te­rów Star Treka. Wcze­śniej­sze doświad­cze­nia z refak­to­ry­za­cją apli­ka­cji budo­wa­nych na eZ bynaj­mniej nie prze­peł­niały mnie opty­mi­zmem, ale byłem mimo wszystko dobrej myśli — co prawda, już raz zda­rzyło mi się prze­pi­sy­wać apli­ka­cję ory­gi­nal­nie opartą na rze­czo­nym środo­wi­sku na wer­sję stan­da­lone, bo wydaj­ność oka­zała się kwe­stią kry­tyczną, ale z całą pew­no­ścią w ciągu ostat­niego roku eZ się roz­wi­nął. Niczym Bogu­sław Woło­szań­ski, powi­nie­nem teraz powie­dzieć tego dnia nie mogli jesz­cze przy­pusz­czać, że już za dzie­sięć dni, w biu­rze obok, odbę­dzie się spo­tka­nie, które odwróci bieg historii.

W dzie­sięć dni póź­niej poja­wił się bowiem wdro­że­nio­wiec, spe­cja­li­sta od pew­nego sys­temu, któ­rego domena macie­rzy­sta mówi wszystko (easy? no!). Rze­czona apli­ka­cja została zbu­do­wana w cza­sie, który nazwano rekor­do­wym (choć jej opar­cie na fra­me­worku typu Cake z pew­no­ścią zaowo­co­wa­łoby skró­ce­niem tego czasu, jak i oszczę­dze­niem nam kolej­nych kło­po­tów, ale o tym za chwilę). Przy­szedł czas na pre­zen­ta­cję. Przy­go­to­wa­nia chyżo ruszyły, a spe­cja­li­sta — niczym rączy rumak — wyrwał z kopyta i zatrzy­mał się na naj­bliż­szym słu­pie. Oka­zało się bowiem, że nasza wer­sja PHP jest zbyt nowa. eZ nie działa z PHP5 i tyle, żadna siła boska ni świecka do koope­ra­cji go nie zmusi. Co prawda, wymaga MySQL5, ale par­sera ocze­kuje prehistorycznego.

W 24 robo­czo­go­dziny póź­niej (Qwiat, jako admin, się spe­cjal­nie nie nudzi i bez takich kwiat­ków), sys­tem został uru­cho­miony. I dnia trze­ciego zoba­czył Pan, że apli­ka­cja klika i było to dobre. Chcia­łoby się powie­dzieć, że wszystko śmiga, ale byłoby to wyjąt­kowo nie­celne sfor­mu­ło­wa­nie. Strony ser­wisu potrze­bują około sekundy na wyświe­tle­nie. Pod jed­nym warun­kiem — że znaj­dują się w cache. Jeśli się jed­nak przedaw­nią, na radość podzi­wia­nia kil­ku­dzie­się­ciu lini­jek HTML przyj­dzie nam cze­kać dokład­nie 35 sekund. Na ser­we­rze, gdzie znaj­duje się kil­ka­set ser­wi­sów, w tym znacz­nie bar­dziej skom­pli­ko­wane roz­wią­za­nia, które — bez uży­cia cache dla danych z bazy — radzą sobie w dobrze poni­żej pół sekundy.

Cóż na to można zara­dzić? Wdro­że­nio­wiec zale­cił insta­la­cję eAc­ce­le­ra­tora i rekom­pi­la­cję MySQL z para­me­trami poda­nymi na stro­nie eZ publish. Pew­nie, a potem zakup dedy­ko­wa­nego ser­wera. eAc­ce­le­ra­tor przy­spie­szył pro­ces gene­ro­wa­nia strony o całe 3 sekundy, druga suge­stia tra­fiła wprost do /dev/null. Ale cze­góż można się spo­dzie­wać po apli­ka­cjach z enter­prise w slo­ga­nie marketingowym?

Zapo­mnia­łem wspo­mnieć, że w sytu­acji, gdzie wszyst­kie vho­sty mają usta­wiony limit pamięci na nie wię­cej niż 12 8 MB, nasz sys­tem na eZ z roz­ko­szą popro­sił o 50 MB żeby się w ogóle uru­cho­mić. Boję się spraw­dzać, jak wygląda dia­gram prze­pływu ste­ro­wa­nia w kodzie, ale na usta ciśnie się cytat z komen­ta­rzy do wspo­mnia­nego posta na The Daily WTF:

It for­gets the steps where it prints an image of the trans­ac­tions and then scans them on a desk­top to get the wood border.

Tech­no­rati Tags: