Tag Archives: drupal

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.

10 fundamental differences between WordPress and Drupal

Nowadays, WordPress, the blogging platform, offers some pretty advanced features such as static page caching, the media library, widgets and user management. Where to draw the line with a full blown CMS such as Drupal for instance? These platforms are not only both written in PHP, they also are more or less based upon the MVC platform.

So, that makes a comparison valid and therefore I would like to briefly address 10 differences between Drupal and WordPress, which I believe are worth knowing. The list below is certainly not written to prove which platform is best (that just depends on your requirements), nor is it an exhaustive list of the differences. It is rather an attempt to show the discrepancy from a technical perspective and a functional point of view.

  1. First of all, Drupal is a Content Management System. It is designed to handle multiple situations: you could build an e-commerce site, but also a blog or corporate website for instance. Although WordPress can (I do not agree with some that say it is a CMS) be used as a CMS, it is still a state-of-the-art publishing platform and is specifically targeted at weblogs. Drupal is much more complex and has much more features.
  2. As a result of the previous, the average end user will be okay with WordPress because it is far more simple, easy and user friendly (e.g. the admin interface which is much more intuitive). You also may need some reasonable understanding of Drupal to be able to hack into it. Due to Drupal its complexity, you are more likely to suffer from scalability problems (e.g. Allowed PHP Memory Size exhausted).
  3. Both platforms breath extensibility: you are able to add functionality to the core. Drupal works with modules, while wordpress makes use of plugins. The difference is that modules are more straight-forward and more advanced. To give an example: Drupal uses built-in paging and access control can be specified seperately. Thus, I would say that plugins are a lightweight version of the Drupal modules.
  4. WordPress is designed to only work with the MySQL database. On the contrary, Drupal works with a database abstraction layer which allows the platform to connect with basically any database.
  5. WordPress ships with Akismet by default, a spam filtering service that is free for personal use. Drupal also has its own spam filter which is called Mollom. The difference is that the latter relies on context analysis and CAPTCHAs.
  6. Both platforms allow to override the look and feel using template files. WordPress has its own template tags. Templates in Drupal can also be parsed using template languages such as Smarty, PHPTAL and PHPTemplate. WordPress does not currently support this.
  7. Blocks in Drupal allow you to have content in different parts of a page. You have the ability to configure blocks from the admin panel. WordPress also lacks this functionality.
  8. WordPress is built around posts, pages, comments, links, categories and tags. Drupal has a uniform structure called nodes. You could think of nodes as objects, with the same underlying data structure. They can represent a blog post, a recipe, a news item, a story, an article etc. Developers can add features like ratings, comments, geolocation information and so on.
  9. Although Drupal is highly customizable, the WordPress community has much more themes and plugins available. However, because WordPress releases a new version every once in a while, third party plugins are version dependable.
  10. WordPress.com is an online community, where everyone can have their own blog. The idea is that anyone should be able to publish on the web without hosting the blog yourself. Of course, Drupal has no such thing, because the concept of Drupal is quite different as stated before.

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.