Tag Archives: imbit

IMBIT performance test (ii)

Dit weekend mocht ik nog eens een IMBIT performance test doen. Dezelfde experimentele setup, alleen een hele andere omgeving: een VPS met een Intel Xeno 2.4 GHz CPU Quad Core architectuur, 512MB RAM en CentOS 4 (*kwijlt). Een hele andere wereld als mijn 1,8 Ghz Windows XP laptop dus.

Kijk even mee naar de resultaten en wees versteld:

Scenario 1: Het onderscheid tussen content en geen content

Scenario 2: 1000 requests voor 10, 50 en 100 clients

De resultaten zijn significant beter; vaak drie keer zoveel zelfs. Echter als er 100 requests gelijk voorkomen, zijn de resultaten nog steeds mager en schommelen ze rond de 1 requests per seconde, met de front page als bottleneck (0,86).

De conclusies die ik hieruit uit trek, is dat het vooral de CPU is die bij intensieve belasting door PHP lijdt. De hoeveelheid werkgeheugen heeft niet zo’n impact; om er nog eens op te wijzen: de server beschikte slechts over 512MB RAM, terwijl er in de andere computer 2GB stak. MySQL neemt hoe dan ook het meeste geheugen intensief. Lees meer in deze LAMP performance studie, die deze resulaten bevestigen.

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.

Een CMS aanwenden of op maat schrijven?

Voor je aan een project begint, dienen er talrijke assumpties gemaakt te worden. Wat zijn de vereisten? Welke ontwikkelingsmethode wordt er aangewend? Is het project haalbaar binnen tijd en budget? Is de infrastructuur beschikbaar? Bij het ontwikkelen van de IMBIT website werd al deze problematiek reeds behandeld. Een issue die echter meer tijd in beslag nam, is of wij zelf alle programmatuur op maat zouden schrijven oftewel een CMS, meer bepaald Drupal zouden aanwenden.

De IMBIT site moet eigenlijk een geïntegreerd platform vormen inclusief forum, kalender, nieuwsbrief en een blog. Bovendien moet dit alles SSO zijn en gebaseerd zijn op user-levels.

Redenen die werden aangehaald om gebruik te maken van een CMS zoals Drupal zijn de volgende.

  • Drupal is modulair opgebouwd; biedt modules aan om een forum te integreren en beschikt over een ingebouwd kalender systeem.
  • De vereiste dat er user-levels configureerbaar moeten zijn wordt ook mooi ingevuld.
  • Drupal is rijp: er staat een enorme actieve community achter. Alles is goed gedocumenteerd.
  • Het is eenvoudig te beheren: het kost geen moeite om zelf de presentatie laag vorm te geven (themes).

Nochtans is er besloten om gedeeltelijk op maat te schrijven. Voor het forum wensen we gebruik te maken van phpBB3, voor de blog WordPress. Verder hebben we onze gepersonaliseerde user table. Dit betekent dat registreren op de website hoort te gebeuren, evenals het single sign-on aanmelden.

Maar waarom dan geen Drupal of een andere CMS gebruiken? Laat het duidelijk zijn dat we het wiel niet willen heruitvinden. Een reden is rechtlijnig met het concept van Vendor lock-in, namelijk dat je afhankelijk bent van hun platform. Stel dat ze het hele concept over een andere boeg gooien. Gans nieuwe structuur en database model bijvoorbeeld. Tja, dan kan dat, misschien geen geld, maar wel veel moeite kosten. Alleen bij commerciële firma’s die Open Source producten zijn gaan aanbieden, zoals RedHat en MySQL of zelfs Movable Type, vormt dit op zich een minder ernstig gevaar. Bij zulke bedrijven is het vanuit commercieel oogpunt immers belangrijk dat oudere systemen compatibel zijn met nieuwere.

Keuzes dienen gemaakt te worden, en ook het op maat schrijven heeft zijn nadelen. Een nadeel dat je hebt bij het schrijven van je eigen code, is dat je het goed moet documenteren opdat volgende generaties developers begrijpen wat er precies gebeurt. Ook hier werd over nagedacht en daarom zal alle code volgens phpDocumentor gedocumenteerd worden. Een ander nadeel is dat we de taxonomie van de verschillende gebruikersrechten zelf gaan moeten implementeren. Dat is niet eenvoudig, maar het biedt wel de volle 100% controle en dat is, vooral op langere termijn, van cruciaal belang. Ook is het zo dat zowel WordPress als phpBB3 beschikken over voldoende functionaliteit, zodat deze geen upgrade meer nodig hebben. Op die manier kunnen wij eigenlijk volledig onafhankelijk en gecontroleerd opereren.

De fundamenten zijn gelegd

Zo, de kogel is door de kerk. De eerste vergadering van IMBIT, waar ik al zo wild over schreef, is een feit. Ik moet zeggen, het kriebelde wel wat en ik was dan ook heel benieuwd. Uiteindelijk werd er méér dan aan mijn verwachtingen voldaan.

Ondanks de relatieve povere opkomst van 20 mensen, twijfel ik er niet meer aan dat het iets gaat worden. Alles werd nog eens tot in de puntjes uitgelegd waar we nu naar toe willen. De verantwoordelijken en werkgroepen voor Legal & Finance, Event Management, Public Relations, International Exchange, Media en Website werden één voor één samengesteld en er werd voor het eerst gesocialized. Ik heb tegen de meeste mensen wel iets kunnen zeggen en heb het gevoel dat iedereen er de volle 100% tegen aan wil gaan.

Uiteindelijk is de knoop doorgehakt en engageer ik me voor de website, maar (nog) niet als eindverantwoordelijke. Het is de bedoeling dat we een platform gaan bouwen bestaande uit forumsoftware, een gesofisticeerd profielensysteem en events. Dat dient dan geïntegreerd te worden tot één geheel. Hoe we het zullen aanpakken, daar zijn we nog niet over uit maar we gaan gretig gebruik maken van Open Source projecten zoals phpBB. Het platform moet alle functiegebieden gaan ondersteunen dus moet er ook efficiënte communicatie zijn over alle groepen heen. Het is vooral dat laatste, samen met het teamwork dat een grote uitdaging is.

Het staat allemaal nog wel in zijn kinderschoenen, maar de fundamenten zijn gelegd en de bouw kan beginnen. Eerst twijfelde ik over een aantal zaken zoals international exchange omdat het me te ambitieus leek. Toen men sprak over het netwerken met verschillende overkoepelende organisaties, lijkt niets meer onmogelijk en kunnen we misschien zelfs docenten laten overvliegen om over een bepaalde actuele problematiek binnen de beleidsinformatica te spreken. Jammer is wel het beperkte aanbod van buitenlandse academische opleidingen die het profiel van business & IT combineren.

Ik kan er nog lang over doorgaan, maar we staan er en ik zou althans fier zijn, dat over tien jaar de organisatie nog steeds operatief is, dat beleidsinformatica een erkende, aantrekkelijke richting is en dat wij kunnen zeggen dat we daar een significante bijdrage in hebben. Grondleggers, David en Kim hebben dat samen met de coördinatie van professoren Verelst en Mannaert goed gedaan!