Web 3.0: het semantische web

Ik ben helemaal niet akkoord met Marc Benoiff, CEO van salesforce.com, als hij voorspelt dat PaaS het nieuwe web, oftewel web 3.0 is. Oké, het is maar een buzz word, maar het zou hem wel goed uitkomen. Wie zou er immers niet samen met zijn bedrijf willen worden geciteerd als de term web 3.0 valt? Het is een beetje zoals web2.0 advocaat Tim O’reilly. Hij had het over de business revolutie in de computer industrie (met tegenreacties van Tim Berners Lee), naar het internet. Voor O’reilly is web 2.0 nu juist zijn business geworden. Zal het ook zo uitdraaien voor Benoiff en zijn web 3.0? Kijk even mee naar het filmpje om een idee te krijgen over Force.com.

Conclusie die ik trek: SaaS is meer een uitloper van web 2.0; het huidige, sociale web, waarin iedereen kan participeren, creëren en innoveren en waarbij bedrijven transparant moeten zijn om te concurreren. Thema’s als wiki’s, weblogs, forums en REST/JSON API’s zijn er kenmerkend. SaaS sluit gewoon aan bij de evolutie in netwerkarchitectuur, gaande van mainframes, naar client/server en, hopelijk voor Salesforce.com naar, Cloud Computing. Bovendien, deze ideeën bestaan al veel langer en liggen aan de basis van Google’s en SETI@home‘s succes. Wat Salesforce.com nu doet, is er voor zorgen dat de bedrijfssoftware ook in de cloud terecht komt. Het drukt de kosten en het is nog eens goed voor het milieu ook!

Het probleem van het huidige web (web 2.0), is dat informatie ontzettend gefragmenteerd is. Hoe nog synchroniseren? Ik lijk te verdwalen in het eindeloze labyrint van de web services. Begrijp me niet verkeerd, ik zeg niet dat het een slechte zaak is, dat informatie verspreid is. Het is gewoon een kwestie van de totale afwezigheid van relevantie, betekenis en kwaliteit in het hedendaagse web gebeuren. Google is al jaren marktleider door zijn superieure zoektechnologie, maar bij Google draait het meer om kwantiteit dan kwaliteit. Hoe hard ze het ook proberen. Gaat dat spelletje nog lang voort duren? Zijn de gebruikte algoritmen nog wel efficiënt genoeg, of is Google ten prooi gevallen van SEO marketeers?

Het toekomstige web (lees web 3.0) is daarom volgens mij (net zoals voor vele anderen, trouwens) het semantische web. En ofschoon er in deze tijden zoiets bestaat als microformaten, is er nog veel werk aan de winkel. Waarom maakt het gesloten Facebook bijvoorbeeld geen gebruik van XFN?

Initiatieven zoals Dataportabiliteit (niet Facebook Connect, Google Friend connect of Myspace Data Availability) of OpenID is waar we naartoe moeten. Daarnaast heb je bijvoorbeeld ook Yahoo, die met Searchmonkey en BOSS een vooraanstaande rol speelt in het semantische web.

Waar het dus op neer komt, is dat we intelligente en kwalitatieve systemen nodig hebben, die ons helpen te synchroniseren en het web meer toegankelijk maken. Dat is, net zoals voor iedereen, de taak van Salesforce.com.

Web 2.0: kwantiteit, web3.0: kwaliteit.

IMBIT performance test

Bij IMBIT hebben we talrijke stakeholders: de gewone leden en partners per functioneel domein, met daarnaast nog onze sponsors en alumni. Als partner bij Website Management is het mijn taak om het platform op te zetten. Het systeem is enerzijds een bron van informatie voor geïnteresseerden, maar het uiteindelijke doel is een interactieve community waarbij iedereen zich engageert en betrokken voelt. Het platform moet ons in staat stellen om onze activiteiten beter uit te kunnen voeren (organiseren, plannen en coördineren).

Een optimale communicatie is alleen maar mogelijk als het systeem ook daadwerkelijk beschikbaar is. Het is dan ook vanzelfsprekend, voor we het nieuwe platform lanceren, de performantie te testen. Als het platform schaalbaar, snel, stabiel en betrouwbaar is, dan komt dat de interactie alleen maar ten goede.

We gebruiken het krachtige en modulair uitbreidbare Drupal. Het is algemeen geweten dat Drupal performant is. Nochtans vereist het IMBIT platform 52 modules (107 MySQL tabellen!). Het is misschien wel eens goed om dat te benchmarken. Tenslotte, door de software te benchmarken kunnen we ook een beter inzicht krijgen in de hardware vereisten.

Drupal beschikt over een onontbeerlijke devel module, uitermate bruikbaar tijdens het ontwikkelen. Ten eerste biedt het een inzicht in het geheugen gebruik (de PHP Memory Limit). Het vorige systeem had slechts een PHP Memory Limit van 16MB, waardoor de forum module vaak het boeltje deed crashen. Bovendien konden wij dit niet zelf instellen, omdat het een shared hosting account betrof. We zijn dus sowieso aangewezen op een dedicated oplossing zoals VPS, waardoor we zelf ook meer de touwtjes in handen zullen hebben. Gedurende het configureren van de modules, lag het geheugen verbruik gemiddeld tussen de 16 en 21MB. Voor de stress test werkten we met een geheugen limiet van 64MB, terwijl de max_execution_time en de max_input_time op 120 seconden werden afgesteld. Voor MySQL werd caching afgezet: SET GLOBAL query_cache_size = 0;

Een andere nuttig gebruik van de devel module is dat je er experimentele content mee kan genereren. Een realistische set-up voor de toekomstige IMBIT, is de volgende:

  1. 500 users
  2. 5,000 nodes
  3. 10,000 comments
  4. 250 terms
  5. 15 vocabularies

Samen met de initiële forums, gebruikers, talrijke rollen en permissies werden deze data gebruikt om de set-up te benchmarken met ab op de Apache webserver. Op elke pagina worden in de rechterkolom de meest recente reacties, de meest recente- en actieve topics, en een kalender weergegeven. In de linkerkolom staat een search box en menu, al naar gelang de rechten die de gebruiker heeft. De front page (met 10 laatste berichten), een node pagina en de contact pagina werden getest. Authenticatie werd ook standaard toegepast.

De performance test werd uitgevoerd op een Intel Celeron 1,8 Ghz machine, met 2GB RAM en WAMP architectuur. We onderscheiden twee verschillende scenario’s.

In scenario 1wordt de situatie content versus no content besproken. Het is duidelijk dat naarmate er meer content is, het aantal requests per second significant lager ligt. Bij 100 requests vind ik toch dat, het aantal requests dat er verwerkt kan worden per seconde, bijzonder laag ligt (1 request per seconde?!).

In scenario 2 wordt het aantal clients variabele gesteld. Ik onderscheid 1000 requests, waarbij het aantal clients gradueel verhoogd wordt van 10 tot 50 en tenslotte 100.

Hoe meer clients actief en hoe minder requests zij doen, hoe hoger het aantal requests per seconde zal zijn.
Gegeven dat de experimentele set-up vrij plausibel is voor IMBIT en gegeven dat een gebruiker je maar 3 seconden geeft (alors c’est fini), ga ik de situatie met argus ogen bekijken. Ligt Drupal en zijn modules of de schaalbaarheid van MySQL aan de basis van de zeer magere resultaten?

Voorlopig is de kwestie nog niet zo zorgwekkend. De volgende stap is om dezelfde test nu uit te voeren en te optimaliseren op de VPS, kijken welke queries veel tijd in beslag nemen en daaruit de nodige conclusies te trekken.