T.net browser-stats per versie 2011

Door ACM op zaterdag 2 april 2011 15:53 - Reacties (30)
Categorie: Browsers, Views: 6.330

Ik vroeg me af wat nu, kort na de introductie van Firefox 4, Internet Explorer 9 en Chrome 10 de verhouding van die nieuwste varianten is.

Kortom, ik ben wat gaan klussen met de cijfertjes van 'visits' van afgelopen vrijdag (1 april) en Google's chart API en kwam op onderstaand plaatje uit. De binnenste ring geeft van de grootste browsers aan wat hun aandeel was. En in de buitenste ring zijn dan de meest gebruikte belangrijkste versies daarvan getoond. Bij alle browsers behalve Internet Explorer zijn er behoorlijk wat 'onbelangrijke' sub-versies samengevoegd onder 'other' (bij Firefox bijna 90 en bij Chrome zelfs bijna 240!).

Browser visits verdeling 1 april 2011

Zoals je daarin redelijk goed kan zien is het relatieve aandeel van respectievelijk Firefox 4.0 en Chrome 10 veel hoger dan Internet Explorer 9. Ik heb niet de indruk dat de eerste of laatste nou minder aandacht in het nieuws heeft gekregen. En hoewel Microsoft claimt dat Firefox en Chrome auto-update en daardoor een 'oneerlijk' scheef beeld krijgen, is dat simpelweg niet waar voor Firefox.
Kortom, het lijkt ook hier weer uit te volgen dat gebruikers van Firefox, Chrome en Opera veel actiever bezig zijn met hun browser-versie dan Internet Explorer.

OS- en Browserstatistieken 2010

Door ACM op donderdag 6 januari 2011 11:53 - Reacties (16)
Categorie: Browsers, Views: 4.985

Na een half jaartje stilte nu toch maar weer een update over wat voor browsers de bezoekers van Tweakers.net tegenwoordig gebruiken.

Het is saai aan het worden, maar Chrome is domweg doorgegroeid ten koste van Internet Explorer en Firefox. Als je de huidige lijnen interpoleert lijkt het erop dat er de komende weken geen enkele browser nog boven de 30% zit, maar dat IE, Firefox en Chrome alledrie tussen de 20 en 30% gaan bewegen.
De rest gebruikt dan vooral Safari, naast de trouwe schare Opera-gebruikers. Voor de rare piek in bezoekers (maar niet in pageviews) in september van Chrome heb ik geen verklaring, wellicht een fuck-up van Google Analytics met hun herkenning van Chrome of domweg met de cijfers.

Hier de ontwikkeling van de weekstatistieken:
Bezoeken per browser per week 2011-01-06
Bij de bezoeken blijft IE in totaal nog wel de grootse, maar zijn IE en Firefox beide duidelijk al langere tijd dalende.

Pageviews per browser per week 2011-01-06
Bij pageviews is Firefox al heel lang de grootste, maar verliest net als IE flink gebruikers aan met name Chrome en in mindere mate Safari. Sterker nog, wij zien door de grote onderlinge verschillen de losse IE-versies als losse browsers. En als je het zo bekijkt is Chrome nu de tweede browser op Tweakers.net.

Bij de Operating Systems beginnen de mobiele devices zichtbaar te worden in de grafiek. Althans, de lijntjes die tegen de X-as geplakt zitten beginnen er een beetje los van te komen. Met respectievelijk 2,18% en 1,47% van de bezoeken zijn Android en iPad nou de grootste twee. Symbian heb ik maar niet opgenomen en iPhone was aan het begin van het jaar de grootste, maar is sinds de introductie van de iPad (en waarschijnlijk de iPhone-app) nauwelijks meer gegroeid. En staat daardoor nu met 1,21% op de derde plek van de mobiele OS-en. In januari 2010 deed de iPhone namelijk al 0,96% van de bezoeken, terwijl Android nog maar op 0,24% zat en de iPad op 0% (die lijn begon pas in April).

Bezoeken per OS per maand 2011-01-06
Zoals te verwachten is Windows Vista nog verder weggezakt. De nieuwe Windows 7-gebruikers komen nog altijd bij zowel XP als Vista-gebruikers vandaan.

Pageviews per OS per maand 2011-01-06

Bij de pageviews doen de mobiele OS-en nog een stuk minder mee. Zoals wel te verwachten was zijn het vooral korte bezoeken.
Met de wildgroei aan Android-tablets en straks een nieuwe iPad zullen in beide grafieken in 2011 de lijntjes voor die twee vast flink door blijven groeien. Wat de iPhone gaat doen is minder duidelijk.

DDoS-stats van 27 december

Door ACM op dinsdag 28 december 2010 12:17 - Reacties (15)
Categorie: Tweakers.net, Views: 5.065

Gisterochtend werden we aangevallen met een DDoS-aanval. Het was zo te zien een vrij standaard aanval, waarbij men probeerde continu nieuwe verbindingen naar onze webservers te openen.
Dat is niettemin een behoorlijk lastige aanvalsvorm om goed af te slaan en zorgde er dan ook voor dat de site in het begin van de aanval toch wat minder goed bereikbaar was.
Gelukkig wist onze, begin dit jaar aangeschafte, ddos-appliance de boel behoorlijk goed tegen te houden, waardoor de overlast toch redelijk beperkt bleef. En die appliance houdt uiteraard ook allerlei statistieken bij, dus bij deze een kort overzichtje :)

Tijdens de piek van de aanval, even voor 12:00 uur, kregen we zo'n 80Mbit aan inkomend verkeer, waar we normaal tussen de 5 en 10Mbit zitten. De piek was overigens wel vrij kort, waarna de aanval gestaag afnam. Onderstaand grafiekje laat dat mooi zien. De pieken rond 11:45u, 14:45u en later zijn onderhoudstaken, die horen niet bij de DDoS.

Riorey Link utilization 2010-12-27

Overigens is de aanval nu nog steeds niet helemaal weg. Aan het begin deden we (naar schatting) richting de 120.000 aanvallende packets per seconde, na een uur zat dat op zo'n 90.000 en nu is dat nog slechts zo'n 1200. Ons normale verkeer bestaat op dit moment uit ongeveer 7000 packets/seconde.

Het aandeel "vervuiling" is daardoor nog steeds wel vrij hoog. Gistermiddag was het ongeveer 90%, nu nog steeds 5% van het totale verkeer en 50% van de "tcp syn's". Het verloop van het totaal kan je vrij goed zien in dit plaatje.

Riorey Packet pollution 2010-12-27

In totaal leverde dat sinds 11:52u gisterochtend 1.442.375.536 tcp/ip-packets onze kant op. Daarvan waren 1.432.525.268 gemarkeerd als onderdeel van de aanval, ruim 99,30% dus. Die packets waren goed voor 96.590.347.964 bytes (net geen 90GB) en ook daarvan was een groot deel aanvallend; 95.909.389.716 bytes oftewel 99,29%.

Optimizing applications and why sampling profilers for java fail en

By ACM on Thursday 11 November 2010 20:55 - Comments (15)
Category: Development, Views: 10.791

Today I found out why sampling profilers for Java applications don't necessarily yield correct results. As an introduction, I start with some general text about discovering performance issues for (web)applications :)

If you pay attention to the performance of your site, you can commonly find points in your code that can be optimized to reduce run time of your application. At Tweakers.net we keep an eye on the site's performance. We (try to) find and optimize slow pages and the overall (perceived) speed of the site. And as you probably know, we did that way before Google started to use page speed as a component of their ranking ;)

Like many players in this world, we also found parts of the code that couldn't easily be optimized much further in either the database, the php-code or the apache-webserver.
Depending on the situation we took different approaches to optimize that: We started using memcached to reduce the number of queries and processing involved with fetching common data. We introduced a message queue in our set-up, allowing asynchronous execution of certain parts of the code. We installed reverse caching proxies, completely eliminating most repeated php-processing involved with semi-dynamic images. And we started using our "pricewatch engine", a internal "service" written in Java to exploit its better performance, more advanced memory management and ability to keep lots of data efficiently in memory.

All those ideas came from some form of profiling. A lot of the optimizations involved reduce or replace queries to our mysql-databases. Choosing which to optimize is mostly a matter of digging through logs, common sense and earlier optimization experiences. That reasonably works well, but only gets you so far. The tools, specifically designed for this, I've used so far for identifying which queries require optimization didn't seem to help much. It is very common for us to see a query being fast in most cases, but with some parameters being relatively slow. Apart from that, we see occasional, but major, slowdowns in queries that are normally very fast. Both situations aren't handled too well by such generic tools.

For our php code it is the same story. Its mostly common sense and very raw profiling using timers. A profiler like xdebug simply introduces way to much overhead (i.e. the "observer effect") to be used in production. Some other tools have evolved nowadays, but they're normally quite costly and I'm not very convinced they help us much in identifying actual bottlenecks. That's mainly because of the simple notion that most of the php-time is spent waiting on resources. In the cases where php was actually a hot spot, it was normally relatively easy to find. The ones we didn't find are probably not too important, as we've no real complaints about our website's performance.

We've also rewritten parts of our code in Java. A Java server application normally has much better performance and the ability to cache large amounts of data with very low latency. I.e. serializing and unserializing data to and from memcached into php is very costly compared to what we do in Java. That is one of the reasons our category pages in the pricewatch are still much faster than before the switch, even though we added several new features and the amount of products and specifications has grown over time.
Finding hot spots in Java code is much harder than in php. Due to compilation and the required restarting of services the overhead of introducing a timer somewhere is very high compared to a properly set up php test site. And to make matters worse, by restarting and/or introducing timing code you may impact the performance of your code much more than with php or sql; the JVM's hot spot optimization in Java is not very easy to predict for normal developers.

Luckily, for Java there are a bunch of profilers available that can be connected to (live) programs to introduce light weight collection of timing data. There are basically two types; sampling profilers and instrumenting profilers. Sampling profilers simply wait a bit, take a snapshot of the call trees and do the same thing again untill stopped. Instrumenting profilers use Java's dynamic code abilities to alter methods of selected classes to add some tiny bit of data collection code at the start and end of a method body.
The instrumentation variant has a major drawback; it introduces a huge overhead that severly impacts the way the JVM will do its work. Basically you're simply profiling a different application. To prevent this overhead, most profilers allow you to select which classes and/or methods should get instrumentation code and which not. This has the advantage of having much less overhead, but may prevent you from detecting a actual hot spot.

The sampling profiler does not have this disadvantage. The only disadvantage most people are aware of is that it may not sample often enough to actually capture very short method calls. But given enough time and a sufficiently small sampling interval, basic statistics suggests that shouldn't be much of a problem. As I can simply re-play the access logs (40M entries currently readily available for me) from our Tomcat application servers, its easy to pound a test environment with hours worth of requests.
Still, the sampling profilers I used didn't necessarily produce hot spot lists I agreed with. And I didn't really understand why. After many thousands of requests to Tomcat, you'd expect it to be able to collect numerous samples and thus easily pinpoint actual hot spots. But it doesn't always work that way.

According to this study it has to do with the fact that profilers don't really sample at the given intervals and at the same time should more randomly distribute the intervals. The intervals are more of a guide for when to take a sample, the actual samples seem to be taken at the next "yield point" (i.e. a point in the executable code at which the JVM allows preemptive switching to another thread). Ironically, those yield points are optimized by the JVM for better performance, potentially keeping them out of the hot spots in your code... The randomization issue also has to do with the yield points. When you switch at an exact interval, you are in sync with any other regular interval in the JVM or OS including thread schedulers. And, annoyingly, even the sampling profilers introduce a bit of an observer effect to the application (they do have to collect the data and such), albeit a much smaller one than those for the instrumentation profilers.
Given all that, you can't really trust the current Java profilers (I know of) too well. This makes it actually quite hard to optimize details in your code as you may not really know which methods are really consuming your cpu time. The general parts of your code (higher up the call-tree) are probably identified mostly correctly, so you will still get a sense of where to look.

I don't really have a solution for any of these issues, but I'd appreciate anyone's opinion or hint for proper tooling on any of the platforms discussed here. For now, its mostly still common sense and a bit of an art to optimize a application ;)

Aanbevolen producten in de Pricewatch

Door ACM op vrijdag 25 juni 2010 21:25 - Reacties (8)
Categorie: Pricewatch, Views: 4.568

In februari introduceerden we vergelijkbare producten. Door de specificaties van producten in een categorie te vergelijken kunnen we de 'euclidische afstand' tussen producten bepalen.
Vervolgens pakken we daar de beste matches uit en laten hetzelfde algoritme los op de recente bezoekersinteresse in de producten. Het idee daarachter is tenslotte dat bezoekers, die een bepaald type product zoeken, meerdere vergelijkbare producten bezoeken. En in de praktijk klopt dat ook :)

Wel bleek de afgelopen tijd dat er nogal zwaar werd gefocused op onbenullige specificaties. De specificaties die bovendien ook nog het vaakst incompleet of inconsistent ingevuld waren. Daar hebben we de afgelopen tijd nog wat aan getuned. De telefoons zijn daarbij een mooi voorbeeld omdat ze erg veel specificaties en filters kennen. Voorheen zag je allerlei telefoons waarvan het totaal niet duidelijk was waarom ze er nou eigenlijk bij stonden, terwijl belangrijke aspecten - zoals de schermgrootte, het type scherm en het OS - nauwelijks meespeelden. Nu zie je telefoons die echt behoorlijk goed vergelijkbaar zijn. Uiteraard hopen we zo de bezoeker nog beter door het doolhof van de productkeuzes te kunnen helpen.

Hetzelfde algoritme bleek ook toepasbaar op los bezoekersgedrag. Op die manier kunnen we van een individuele bezoeker proberen wat producten aan te bieden waar hij mogelijk interesse in heeft. We weten tenslotte wat hij zoal bekeken heeft en wat anderen, die diezelfde producten ook bekeken, bekeken hebben.
Als je bijvoorbeeld geintereseerd bent in de Samsung Galaxy S, HTC Desire en Google Nexus One. Dan zal het er op de pricewatch-index ongeveer zo uit kunnen zien:
Aanbevolen producten


Ik kan me goed voorstellen dat anderen ook de zilveren Desire, iPhone 4 en HTC Wildfire hebben bekeken en, inderdaad, ik heb ze nog niet bekeken. Uiteraard verschilt het gedrag met andere producten. Het is sowieso maar net hoe populair de producten zijn die je bekijkt en wat voor willekeurig gedrag bezoekers ermee hebben.

Als je bijvoorbeeld een populair fototoestel en een nas-oplossing bekijkt, ziet het er ongeveer zo uit:
Aanbevolen producten, 2e voorbeeld


Mocht je het zelf willen bekijken, hou er dan rekening mee dat er gebruik wordt gemaakt van je sessie. Oftewel, als je veel verschillende producten bekijkt zal er vanzelf een chaos ontstaan die zich vooral richt op de populairste producten (je kan uiteraard een andere browser starten om een schone sessie te krijgen). Verder kijken we voorlopig alleen naar heel recent bezoekgedrag, de afgelopen 24 uur. Hoewel ik wel verwacht dat we dat nog een stukje willen oprekken is het niet bedoeling dat we je met maanden aan bezoekgedrag blijven confronteren. Om die reden krijg je ook geen producten te zien die je reeds zelf bezocht hebt, het bestaan daarvan weet je tenslotte al.
Overigens zit er een vertraging van maximaal 5 minuten in de weergave, het is vrij kostbaar om dit helemaal on-the-fly uit te rekenen, dus een groot deel van het voorwerk wordt elke vijf minuten gecached :)
En als laatste, als je nog niks bezocht hebt, krijg je toch resultaten te zien, dan krijg je domweg populaire producten te zien, net als het blokje op de frontpage. Dit zijn tenslotte de producten waarvan we weten dat veel andere bezoekers er in geinteresseerd waren, dus deze hebben dan de grootste kans om de interesse van de bezoeker te wekken.

Ik hoor graag jullie mening over de werking en verbeterpunten van deze nieuwe functionaliteit. Echter zit ik niet zo te wachten op allerlei discussies over privacy, door de korte periode waarover we de hiervoor gebruikte gegevens bewaren zie ik geen reden je daar heel erg zorgen om te maken. Voorts worden de gegevens anoniem en enkel in massaverwerking gebruikt, de individuele gegevens gebruiken we slechts alleen om het lijstje voor de individu die te pagina bekijkt te genereren. Dus ik hoop dat we dat aspect bij deze kunnen laten voor wat het is :)