Google-robotter spændte ben for bibliotekernes nye Drupal-sites
Mandag fik bibliotekerne i Århus og København udrullet et funklende nyt site baseret på open source-cms'et Drupal.
Det nye site luger ud i et hav søgefelter på den gamle hjemmeside, som ikke ligefrem lettede overblikket for lånerne, når de skulle søge efter bøger og låne dem gennem siden.
Sitet ligger samtidig ovenpå en helt ny databasestruktur, hvor oplysninger om bøger og andre medier fra en række forskellige tjenester samles i én databrønd, som bibliotekerne kan tilgå.
Men lanceringen af det nye site blev ikke helt uden startvanskeligheder.
Stor interesse fra brugerne af bibliotekshjemmesiderne gav mandag nedetid på omkring en halv time.
»Mandag er historisk set den dag i ugen, hvor der er mest aktivitet på bibliotekernes hjemmesider, så vi viste godt, at vi lancerede lige midt i prime time. Men mængden af besøgende overraskede os alligevel,« siger Drupal-udvikler på projektet, Mikkel Høgh, til Version2.
Samtidig med de mange besøgende fik den nye hjemmeside besøg af Google umiddelbart efter lanceringen, hvor Googles indekseringsrobotter gik i gang med at kravle hen over sitet for at kunne føje det ind under søgeresultaterne.
Mikkel Høgh kender ikke tallene i spidsbelastningsperioden, men selv mandag aften, hvor stormen var stilnet lidt af, var der stadig omkring 40 requests per sekund til webserveren. Det har tirsdag stabiliseret sig til 24 requests.
»Vi fokuserer lige nu på at få sitet til at køre hurtigere. Det tager omkring halvandet sekund per side at servere siden, og det er for meget,« siger Mikkel Høgh.
Brugte den agile metode
Han er i øjeblikket ved at teste Version2-blogger Poul-Henning Kamps cachingværktøj Varnish, der efter planen skal gøre sitet hurtigere til at præsentere siderne for brugeren ved at aflaste webserveren.
Udviklingsprojektet kører efter den agile model, og der ligger stadig rettelser af fejl og mangler og venter i horisonten.
Det gælder blandt andet problemer med reservering af tidsskrifter, som nogle gange virker, og andre gange ikke.
Med den agile udviklingsproces har udviklerne haft mulighed for at blive klogere undervejs i projektet, og bruge den nye viden i praksis.
»Samtidig har det givet os mulighed for at rulle et skridt tilbage hurtigt, hvis en idé er blevet afprøvet, men ikke har virket,« siger Mikkel Høgh.
Drupal blev oprindeligt valgt, fordi flere store internationale projekter i både det offentlige og på ngo-plan har taget CMS'et til sig. Det gælder blandt andet Amnesty og staten New York i USA, der har taget Drupal til sig på bibliotekerne, forklarer Mikkel Høgh.
Drupals åbenhed vejede tungt Men de tekniske argumenter har også vejet tungt.
»Drupal er meget minded mod at være en udviklingsplatform, og ikke bare et CMS. Den primære udfordring for os har ikke været CMS-delen, for den er forholdsvis simpel. Vi har lagt rigtig mange udviklingstimer i at få integreret databrønden og bibliotekssystemerne med Drupal, og det har vi kunnet gøre ved at udvikle moduler til Drupal, som kan snakke sammen med de forskellige tjenester,« siger Mikkel Høgh.
Ifølge Mikkel Høgh er det tanken, at flere dele af projektet på længere sigt skal kunne genbruges i andre offentlige it-projekter, som eksempelvis det digitale lydbogsbibliotek, Netlydbog.
Den gamle bibliotekshjemmeside kan i en periode stadig vælges via et link fra det nye site, hvis brugeren foretrækker det.
Mikkel Høgh fortalte om projektet under Open Source Days 2010 sammen med kollegaen Rasmus Luckow-Nielsen, der er teknisk chef hos Signal Digital.
Kommentarer (17)
Nej det er det ikke.
Jeg sider med fingrene i en af Dells R200 servere (noget af de billigste de har, starter ved 3000 kr. ca.) og den serverer lige nu >100 forespørgsler i sekundetet ved ca 10% load.
Det lugter lidt af at nogle har skrevet noget dårlig kode selvom jeg ikke kan se hvad der på et website skal kunne trække så mange ressourcer?
-
0 -
0
Det lugter lidt af at nogle har skrevet noget dårlig kode selvom jeg ikke kan se hvad der på et website skal kunne trække så mange ressourcer?
Du er velkommen til selv at inspicere koden: http://github.com/dingproject/ding
Ganske kort sagt, så sker der ganske meget på disse sider med mange eksterne webservice-kald og databaseopslag pr. side, som gør det lidt tungere at håndtere end bare flad HTML :)
-
0
-
0
Tillad mig at videreføre din metafor:
Det kommer helt an på hvilket transportmiddel (server) du har og hvad du skal fragte (data)?
-
0
-
0
Jeg går ud fra at det primært er søgning som trækker tænder ud, kan du give et indblik i hvorledes dette er organiseret, og hvor flaskehalsene er?
Jeg må indrømme at jeg ikke har tålmodigheden til at trawle koden igennem for selv at finde ud af det.
-
0
-
0
Jeg går ud fra at det primært er søgning som trækker tænder ud, kan du give et indblik i hvorledes dette er organiseret, og hvor flaskehalsene er?
Der er en række forskellige webservices involveret i en søgning (og visning af data i øvrigt):
• Scan (autocomplete/stavekontrol)
• Search (selve søgningen i databrønd)
• ADHL (andre der har lånt – anbefalinger)
• Addi (berigende information, primært forsidebilleder)
• Alma (API til biblioteksystemet Axiell DDELibra som både Århus og Københavns biblioteker bruger)
Ved en søgning vil hver af disse blive kaldt flere gange, så en enkelt søgning kan betyde 15-20 webservice kald, som bliver kaldt igennem Drupal-sitet (da der foregår diverse adgangskontrol og XML-transformation på serveren).
Der ud over skal det nok nævnes at det ikke var de 40 requests pr. sekund der fik serveren til at gå ned – det var bare hvad vi lå på senere på dagen da systemerne kørte stabilt igen.
-
0
-
0
(Jeg går ud fra antagelsen om, at man med webservices mener f.eks. SOAP requests).
Uden at gå for meget i dybden, så virker denne udtalelse
så en enkelt søgning kan betyde 15-20 webservice kald
som om man har ramt rimeligt meget ved siden af potten.
Og hvorfor
XML-transformation på serveren
Det er da at bede om problemer hvis det foregår for hver request.
-
0
-
0
Mht. typen af webservices, så er der primært tale om REST-baserede services der svarer i enten XML eller JSON. Der er dog også en enkelt SOAP.
Uden at gå for meget i dybden, så virker denne udtalelse […] som om man har ramt rimeligt meget ved siden af potten.
Ja, hvis man ikke sætter sig ind i hvorfor, så virker det unægteligt som rimelig meget.
Det skyldes til dels at nogen af de webservices vi bruger ikke understøtter at man kan spørge på mere end en bog ad gangen (det er vist kun forsiden, hvor vi ikke har fået en bulk-metode endnu), så disse pakker vi ind, så de kun kører via en enkelt AJAX-request, og Drupal så laver de mange kald på serveren.
Ellers kan du jo prøve at fyre op i Firebug på vores søgesider, og se hvad der ellers foregår af data frem og tilbage via AJAX – der er faktisk en del.
Det er da at bede om problemer hvis det foregår for hver request.
Når nu brugerens låneroplysninger fra biblioteket returneres til os i XML-format, så er vel ikke så fantastisk meget andet at gøre end at parse den, hvis vi gerne vil vise brugeren sine oplysninger.
Vi cacher selvfølgelig så meget vi kan, men i mange tilfælde er der tale om livedata, så der må man jo bare bide i det sure æble. Transformation er nok et dårlig valgt ord i sammenhængen, i det vi ikke gør andet end at hive data ud af XML'en med PHPs DOM-implementation, som er forholdsvis hurtig til formålet. Ingen XPath eller unødige krummelurer.
-
0
-
0
Afhængig af hvad performance tests viser jer kunne det måske betale sig at bruge SAX (Simple API for XML) parseren i PHP.
Den er noget mere udfordrende at bruge end DOM parseren, men den er også hurtigere. Det udfordrende er at i skal skrive den funktion, som kaldes af parseren, når parseren møder et bestemt XML tag, som i definerer.
Funktionen gemmer typisk noget tekst/et tal i en PHP variabel.
SAX parseren i PHP er i virkeligheden en C wrapper til Expat parseren: http://expat.sourceforge.net/
og denne serie af artikler fortæller hvordan man bruger
SAX parseren i PHP:
http://www.phpbuilder.com/columns/justin20000428.php3
PHP funktioner for SAX parseren:
http://www.phpbuilder.com/manual/ref.xml.php
SAX parsers vs DOM parsers performace test:
http://www.devx.com/xml/Article/16922/0/page/3
-
0
-
0
»Drupal er meget minded mod at være en udviklingsplatform, og ikke bare et CMS.«
Det er efter min mening en antagelse der må have kostet mange virksomheder store tab. Personligt har jeg været vidne til et par katastrofer med Drupal, der var baseret på denne antagelse.
Drupal markedsfører sig selv på forsiden af deres site som en "content management platform", og det er efter min mening det eneste man bør bruge Drupal til. Drupal er fin som platform til content management.
Men man skal se sig godt for, når man skal bedømme, om det man skal bygge er primært content-management, eller om der er tale om en applikation. Efter min mening lyder det som om, at der var tale om langt mere en content management i dette tilfælde.
Som framework til udvikling af applikationer er Drupal nok noget af det værste du kan vælge.
Drupal er ikke MVC.
Drupal er ikke objekt-orienteret, og drager i det hele taget ikke rigtig fordel af nogen moderne PHP features.
Drupal har ingen ORM (object-relational mapper).
Drupal kode er meget svær at debugge, og der opstår mange uforudseelige bivirkninger hver gang et modul ved brug af "hooks" forsøger at overstyre forskellige aspekter af platformens (eller andre modulers) opførsel.
Jeg kunne komme med en meget lang liste over problemer, men i det store hele, som seriøs software udvikler, har du ikke meget at hente i Drupal.
Og det er helt fint - Drupal bliver jo ikke markedsført som en udviklingsplatform, og klarer jobbet som content management system helt fint.
Men hvis du tror at Drupal er egnet til moderne software udvikling, så tænk igen. Det bliver en dyr og smertefuld lektie.
Med mindre selvfølgelig du aldrig har prøvet (eller ikke forstår) hvordan (eller hvorfor) moderne frameworks virker.
-
0
-
0
@Lars Tørnes Hansen: Tak for tippet med SAX, det vil jeg lige tage op til overvejelse…
@Rasmus Schultz:
Jeg kunne komme med en meget lang liste over problemer, men i det store hele, som seriøs software udvikler, har du ikke meget at hente i Drupal.
Jeg er da ked af at høre at du ikke betragter mig og nogen tusind andre udviklere som seriøse.
Jeg kommer nok ikke til at erklære mig enig I dine postulater, som vist primært går ud på, at fordi Drupal ikke bruger dine favorit-paradigmer inden for softwareudvikling, så er det noget bras.
Der er ingen af de problemer, som bliver beskrevet ovenfor som kunne være afhjulpet ved at bruge mere MVC, OOP eller ORM. Faktisk havde de alle tre og nok specielt ORM været en ekstra performance-byrde.
Det er helt ok ikke at bryde sig om Drupal, men dine bombastiske udmeldinger om dets uegnethed som udviklingsplatform er svære at tage alvorligt, hvis man kender lidt til hvad der foregår i Drupal-miljøet, f.eks http://openatrium.com/ http://tattlerapp.com/ http://managingnews.com/
-
0
-
0
fordi du stiller dig frem og besvarer folks (mere eller mindre velfunderede) spørgsmål. Folk skyder generelt gerne med skarpt herinde, så det er modigt, at du vælger at svare retur. Det skinner tydeligt igennem dine svar, at du bestemt er en seriøs udvikler.
Jeg har selv udviklet meget med Drupal. Jeg er på nuværende tidspunkt skiftet til Rails, ikke fordi jeg syntes at Drupal var dårligt, men fordi jeg i Rails fandt noget, der passede bedre til mit temperament.
Jeg synes at jeg med Drupal fik for meget "med i rygsækken", som jeg ikke nødvendigvis skulle bruge på det enkelte projekt. Men jeg kan jo også læse af dine svar, at det egentlig ikke er platformen i sig selv, der giver performance-issues, snarere alle de back-end kald, som skal foretages.
Hvor meget kan i tillade jer at cache data fra de enkelte systemer. Vil i kunne pre-loade disse enorme mængder af data, eller i hvert fald dem, som ikke ændrer sig så tit? (f.eks. ADDI og ADHL)
- Carsten
-
0
-
0
Jeg synes at jeg med Drupal fik for meget "med i rygsækken", som jeg ikke nødvendigvis skulle bruge på det enkelte projekt.
Jeg er også stor tilhænger af princippet om det rigtige værktøj til den rigtige opgave.
I Reveal IT (mit eget lille firma) bruger vi ud over Drupal også Django til opgaver hvor Drupals styrker ikke finder anvendelse :)
Hvor meget kan i tillade jer at cache data fra de enkelte systemer. Vil i kunne pre-loade disse enorme mængder af data, eller i hvert fald dem, som ikke ændrer sig så tit? (f.eks. ADDI og ADHL)
Ja, vi cacher ret grundigt på kald som ikke involverer live-data – her lidt statistik fra vores memcache-server:
uptime 2 days 18 hours
curr_items 512216
total_items 1145193
bytes 216.3 MB
curr_connections 9
total_connections 2122314
connection_structures 119
cmd_get 30354013
cmd_set 1258462
get_hits 24143918
get_misses 6210095
evictions 0
bytes_read 2928.85 MB
bytes_written 173576.56 MB
hit_percentage 79.54%
mem_used 0.01%
Der har med andre ord været 30 millioner cacheopslag de seneste par dage med en hitrate på næsten 80%. Det synes jeg er meget pænt :)
Regulær preloading er nok ikke realistisk – planen er at databrønden skal op på omkring 100-150 millioner poster…
-
0
-
0
Regulær preloading er nok ikke realistisk – planen er at databrønden skal op på omkring 100-150 millioner poster…
Hvorfor ikke? Det er jo før set, at Memcached kan nå størrelser på 28 Terabyte :-)
http://www.facebook.com/note.php?note_id=39391378919
- Carsten
-
0
-
0
Tilføj kommentar
