Binnenkort vervangt Tweakers.net een deel van de code achter de categoriepagina's van de Pricewatch. Dit zou geen zichtbare wijzigingen op moeten leveren, maar wordt wel bewust stapsgewijs ingevoerd. Voor hen die niet in het technische verhaal geïnteresseerd zijn in het kort wat er verandert: aan de werking van de Pricewatch verandert niets, alleen de snelheid waarmee de categoriepagina's worden gegenereerd gaat omhoog. Mocht er ergens wel iets anders werken, dan is dat waarschijnlijk juist een bug. Als je twijfelt, vraag het gerust in ons Pricewatch-forum.
Tweakers.net probeert continu de performance van de website te verbeteren. In de afgelopen paar jaar hebben we aan de serverkant Memcached in gebruik genomen, diverse stukken PHP-code (herhaaldelijk) geoptimaliseerd, databasequeries verbeterd of zelfs door caching overbodig gemaakt en nog diverse andere tweaks uitgevoerd. Aan de clientkant hebben we ook niet stil gezeten met diverse css sprites, een apart image-domein en nog een reeks optimalisaties van de javascript- en de html-structuur.
Ondanks dit alles bleef de performance van de zwaarste categoriepagina's in de Pricewatch ons een doorn in het oog. We streven naar pagina's die server-side binnen 0,1 seconde klaar zijn. Dat klinkt weinig, maar de browser kan doorgaans pas daarna wat nuttigs doen met de gegenereerde content. Een vliegende start is dan een stuk prettiger dan eerst al een tijdje op onze servers te hebben moeten wachten. De langzaamste categoriepagina's van de Pricewatch kosten serverside zelfs meer dan 1 seconde. Dat is niet alleen slecht voor onze trots, het is ook domweg een belemmering voor het vlot kunnen gebruiken van de Pricewatch.
De schoonmaak van de categorieën en de almaar groeiende hoeveelheid producten en specificaties heeft dat probleem alleen maar versterkt. Ondanks onze positieve ervaringen met PHP werd duidelijk dat hiermee geen significante winsten meer te halen zijn. Althans, niet zonder sterk op de functionaliteit, onderhoudbaarheid en flexibiliteit in te boeten. PHP gooit na een pageview alle net verwerkte data weer weg, en moet bij een nieuwe pageview al die data dan ook weer opnieuw ophalen of opbouwen.
Om die reden hebben we een engine ontwikkeld die in het geheugen van de servers actief kan blijven, zonder steeds opnieuw allerlei data op te moeten bouwen en weer nodeloos weg te gooien. Door al geruime ervaring met het platform viel de keus op een door onszelf in Java geschreven 'middleware'. Hiermee vormen we een laag tussen de database en PHP, die de filtering, sortering en paginering van productdata op zich neemt en dan de weergave ervan aan onze bestaande PHP-code overlaat.
De implementatie is bewust opgezet met het hergebruik van diverse Java-componenten en een sterke scheiding tussen de bestaande weergavecode en de nieuwe engine in gedachten. We hebben een Servlet ontwikkeld die intern met normale GET-requests kan worden aangesproken en alle benodigde data (een paar honderd MB) domweg in het ram-geheugen houdt. Om die engine te laten weten dat data ververst moet worden stuurt onze PHP-backend berichtjes via ActiveMQ. Omdat er erg veel data moet worden weergegeven, blijven de Pricewatch-categorieën ondanks significante snelheidswinsten (de huidige worst-case pagina's worden mogelijk tot wel 8x sneller) - toch tot de traagste pagina's van onze site behoren. Wel schept deze nieuwe engine ruimte voor verdere verbeteringen, waar we die met onze bestaande engine in PHP nauwelijks meer zagen.
In eerste instantie laten we zowel de oude als de nieuwe engine parallel draaien. Daarbij sturen we in het begin slechts 10 procent van de categoriepagina's via de nieuwe engine, en als alles goed werkt verhogen we dat stapsgewijs in de loop van volgende week tot 100 procent. Als het goed is merken bezoekers hier niets van, behalve dan dat de bewuste pagina's wat sneller moeten worden. We kunnen uiteraard bij het testen van de code van alles over het hoofd gezien hebben, dus mocht je een bug vinden, dan horen we het graag en als je twijfelt, vraag het ons dan.
)
)
