Stacktrace

Escenic är ett norskt företag som utvecklar diverse moduler som tillsammans bildar ett Content Management System (CMS), det vill säga ett publiceringssystem eller webbpubliceringssystem. Meningen och nyttan med dessa är att de tillåter att personer utan programmeringskunskaper själva kan kontrollera innehållet på en (ofta omfattande) webbplats – det vill säga skapa nytt innehåll, redigera eller ta bort gammalt innehåll, lägga upp bilder, osv.  Det finns ett antal olika javabaserade publiceringssystem på den svenska marknaden, där de stösta utvecklas av Escenic och ett annat företag som heter Polopoly. Escenics system används idag av många dags- och kvällstidningar, bland annat Aftonbladet, Svenskt Näringsliv och Svenska Dagbladet.

Under de 1,5 år som jag arbetat med att bygga webbplatser med hjälp av Escenics CMS har jag kommit över en hel del saker som underlättar utvecklingsarbetet, men som kan vara svåra att hitta i dokumentationen. Den här artikeln är en samlingsplats för dessa tips, allt ifrån hur man underlättar uppdateringen av resursfiler till att förtydliga ett något odokumenterat API. Fyll gärna i med era egna tips!

(under utveckling..)

Tips 1: Oplacerade relaterade objekt

Varje artikel i Escenic har en så kallad relationsbox, där man kan lägga till relaterade objekt såsom bilder eller andra artiklar. För varje relaterat objekt kan man sedan välja ett fält som styr var någonstans objektet hamnar (endast i puffen, under rubriken, under brödtexten, etc). För att exempelvis hämta ut relaterade artiklar och bilder kan man sedan använda sig av taggarna och . Taggarna tar en field-parameter som specificerar vilket fält som är intressant, så att bara objekt placerade i detta fält returneras. Är field-parametern tom returneras alla objekt oberoende av placering.
För att undvika onödigt manuellt arbete vill man ofta ge alla relaterade objekt i relationsboxen en automatiskt placering – till exempel att alla relaterade objekt ska hamna länst ner i artikeln.  Detta ställer dock till problem om man vill ha olika defaultplaceringar för artiklar respektive bilder. Då vill man istället att objekten som default ska vara ‘oplacerade’ (dvs ha ett tomt fält) så att man kan behandla oplacerade artiklar och oplacerade bilder på olika sätt. Problemet med detta är dock att relation:..>-taggarna inte stöder ett sätt att bara hämta oplacerade objekt.
Som tur är finns det ett sätt att lösa detta på. Alla relaterade objekt har nämligen en getPlacement-metod som returnerar namnet på det fält där objektet är placerat. Vet man då vilka fältnamn som returneras för oplacerade objekt är man så gott som hemma. Dessa namn skiljer sig dock mellan artiklar och bilder, där artiklar får placeringen ‘related’ medan bilder får tomma strängen.

För oplacerade artiklar kan man alltså göra såhär:

<relation:articles id="relatedArticle">
    <article:use articleId="${relatedArticle.id}">
        <c:if test="${relatedArticle.placement eq 'related'}">
            // Gör något med dina oplacerade artiklar här
        </c:if>
    </article:use>
</relation:articles>

För oplacerade bilder kan man istället göra såhär:

<relation:images id="image" version="${version}">
    <c:if test="${empty image.placement}">
        // Gör något med dina oplacerade bilder här
    </c:if>
</div>

För bilder bör också observeras att fältnamnet måste skrivas med versaler om man kollar det i efterhand, oberoende av hur fälten specificerades i article-types.xml. Vill man till exempel använda bilder från ett visst fält plus alla oplacerade bilder måste man skriva något i stil med följande:

<c:if test="${image.placement == fn:toUpperCase(field) or empty image.placement}">
    ..
</c:if>

Tips 2: Cachning

Detta tips handlar om prestanda i Escenic, och riktar sig kanske framförallt till den som börjar närma sig driftsättning av en Escenicsajt.

Interna cacher och invalidering

Liksom andra CMS:er så generar Escenic väldigt mycket databastrafik i vissa situationer. Att från scratch generera t.ex. en startsida till en webbtidning med mycket bilder andra delar kan resultera i kanske 6000 databasfrågor. För att få en godtagbar prestanda så har Escenic inbyggd cachning av alla möjliga typer av objekt – artiklar, sektioner, relaterat material och mycket mer. När man ändrar på något, t.ex. texten i en artikel, så invalideras det objektet (men inget annat) i cachen så att det objektet genereras om.

Om man har en miljö med flera Escenic-instanser (t.ex. en publiceringsserver och en eller flera frontar) så måste man konfigurera instanserna så att de meddelar varandra när ett cachat objekt skall invalideras – annars får man en situation där ändringar inte ”slår igenom” på frontarna. Det finns två sätt att konfigurera detta i Escenic: ”mesh” och ”hub”, där hub är det rekommenderade sättet. Båda sätten använder RMI och finns dokumenterade i installationsguiden.

Om databasen inte skall bli överlastad är det oerhört viktigt att cacharna fungerar optimalt. Ett bra sätt att börja jobba med detta är att titta på sidan http://yoursite.com/escenic-admin/pages/performance.jsp. Där kan man se hur väl de olika cacharna fungerar. Samtliga bör ligga nära 100% cache-träffar efter en tids körande – om någon inte gör det så måste storleken på cachen antagligen ökas vilket man gör i en separat properties-fil för varje cache.

Frontcache

För att ytterligare minska lasten på systemet kan det vara idé att använda en frontcache som komplement till Escenics egna cachar. Detta är ett enkelt och billigt sätt att få installationen att klara mer last som även rekommenderas av Escenic – de har ett samarbete med det norska Varnish-projektet: http://varnish.projects.linpro.no. En frontcache sparar undan hela webbsidor och slår upp dem igen baserat på HTTP-frågan som kommer in. Normalt så ställer man in cachen så att den sparar sidan någon begränsad tid, t.ex. 60 sekunder. Det går också att få cachen att spara andra typer av filer såsom bilder vilket också kan minska lasten en del. Observera dock att Escenic inte är direkt inblandat när det gäller att ladda ner bilder – det sköter webbservern/servletcontainern.

Ju längre tid man sparar sidorna, desto mindre last blir det förstås på Escenic. En minut kan ju tyckas som en kort tid, men i digitala media måste det gå undan! Antag t.ex. att någon råkat publicera en artikel med en felstavning i rubriken – då känns en minut som en evighet att vänta för redaktionen. Det bästa vore om Escenic kunde invalidera de sidor i frontcachen som innehåller den ändrade artikeln så att ändringen slår igenom direkt.

Av det skälet har Escenic lagt till stöd för något som heter SquidInvalidationService. Denna service kan skicka ett invalidringskommando till Squid (en annan frontcache) när något på en sida har ändrats, vilket leder till att sidan renderas om nästa gång någon webbläsare vill ladda ner den. Det intressanta (och odokumenterade) i detta är att invalideringsservicen också fungerar med Varnish. Servicen konfigureras via /com/escenic/service/webcache/SquidInvalidationService. Detaljerna kring detta bör finnas dokumenterade.

Kommentarer

  • Hei

    Veldig fin artikkel!

    Det er helt klart en idé å bruke en frontcache, ja :-) For eksempel leverer Aftonbladetse 99,8% av sitt innhold fra sin Varnish cache (de bruker i dag fire cache servere, med ca 20% load). Escenic Content Engine støtter Squid, Oracle Web Cache og Varnish.

    Det er ikke riktig at bare hele sider caches. Varnish har støtte for Edge Side Includes, som gjør at man kan bestemme veldig detaljert hvilke deler av en side som skal caches, hvor lenge innholdet skal caches, etc. Ved å dele opp JSP-ene i mindre fragmenter kan man cache selv veldig dynamiske websites, også community-siter. Selv caching i 5-10 sekunder kan utgjøre merkbare forskjeller.

    ESI er en W3C-standars, og det er mer informasjon her:
    http://www.w3.org/TR/esi-lang
    http://varnish.projects.linpro.no/wiki/ESIfeatures

    Escenic Content Engine genererer automatisk alle størrelser (versjoner) av bilder automatisk. Disse bildene kan lagres på normalt vis (SAN, etc), eller bare lagres på cache-serveren. Har man f.eks. 10 millioner bilder, kan man sette opp cache-regler for å lagre genererte bilder i f.eks. 30 dager.

    Håper dette var informativt (og ikke bare reklame..), og ta gjerne kontakt hvis det er noe vi kan hjelpe med.

  • Og: ”SquidInvalidationService” har allerede fått et nytt, mer generelt navn :-)

Skriv kommentar

Du måste vara inloggad för att kunna kommentera.