Alternatieven voor Java's ThreadLocal om objecten te hergebruiken

Door ACM op dinsdag 17 november 2015 19:25 - Reacties (10)
Categorie: Development, Views: 2.746

Soms zijn objecten relatief 'duur' om te maken, in vergelijking tot hun runtime-performance. Bekende voorbeelden in Java zijn NumberFormat en DateFormat. Ze zijn zo duur om te maken omdat ze onder andere eerst de 'huidige' Locale opzoeken en zich vervolgens zo configurere dat ze correcte formats opleveren voor die taal. Als dat eenmaal gebeurd is, is de aanroep van format() vrij snel gebeurd.
In Tweakers gebruiken we de NumberFormat erg veel in onze "Java-engine".
Objecten hergebruiken
Bij dat soort objcten zou je liever niet voor elke aanroep van format() eerst een nieuw object maken. Idealiter zou je één keer een NumberFormat-object maken en die steeds hergebruiken. Dat is vooral effectief als je veel cijfers in mooie leesbare formatting wilt genereren.
In Java is het dan ook een heel gebruikelijke performancetip om NumberFormat en dergelijke te hergebruiken. Als je maar één thread gebruikt is dat ook een heel makkelijk advies om op te volgen; je kan dan domweg je formatter in een class-property bewaren of eventueel zelfs een static object ervoor aanmaken.

En dat bewaren van een object helpt ook echt, in een eenvoudige JMH-benchmark bleek dat steeds een nieuw NumberFormat-object aanmaken en daarna één cijfer formatten op zo'n 1,8 miljoen formats per seconde uitkwam. Dat klinkt heel veel, maar als je dat vergelijkt met een hergebruikt object dan valt het toch tegen. Met één object aanmaken in totaal en steeds daarmee formatten kwam de test namelijk uit op ruim 39 miljoen formats per seconde uit, ruim twintig keer zoveel.

Overigens is het hergebruiken van objecten lang niet altijd de moeite waard. De JVM kent aardig wat optimalisaties om kleine, kortlevende objecten zeer snel aan te maken en weer te verwijderen. Doe het dus alleen als je denkt dat het echt wat toevoegt.
Hergebruik bij meerdere threads
Gebruik je echter meerdere threads, dan wordt het een stuk lastiger. Als de interne state van een object verandert, dan is het object in principe niet thread safe. Als je ze dan toch in meerdere threads tegelijk gebruikt, dan levert dat onvoorspelbaar gedrag op. Dit geldt onder andere voor NumberFormat en DateFormat, maar er zijn natuurlijk veel meer objecten waar dat relevant voor is. Het idee van een object-property of een static object werkt hier daarom niet zomaar, dan kan je niet garanderen dat dat object slechts door één thread (tegelijk) gebruikt wordt.

Om objecten toch thread safe te kunnen hergebruiken is er in Java een standaardtechniek ontwikkeld. Dat is de ThreadLocal. Die zorgt ervoor dat er voor iedere thread een uniek object wordt gemaakt en dat dat object vervolgens binnen die thread steeds hergebruikt wordt. Dit heeft wat overhead ten opzichte van direct hergebruiken, maar in de praktijk is het bijna even snel. Het kwam in diezelfde benchmark uit op bijna 33 miljoen formats per seconde met één thread en met vier en acht threads (op een vier-core machine zonder hyperthreading) op ruim 130 miljoen formats per seconde.
Nadeel van ThreadLocal in webapplicaties
Helaas heeft het gebruik van ThreadLocal voor webapplicaties een groot nadeel: het is een gebruikelijke bron van geheugenlekken. Dat is iets dat vrij specifiek voor webapplicaties geldt en niet voor reguliere applicaties, je hoeft je dus niet direct zorgen te gaan maken.
De reden dat het die geheugenlekken veroorzaakt hangt samen met de manier waarop de meeste application servers, waaronder Tomcat, applicaties en classes inladen. Dat doen ze met een losse ClassLoader.
Het gaat wat te ver om dat hier helemaal uit te leggen, maar het komt er op neer dat Threads gedeeld worden door meerdere webapplicaties en dat de webapplicaties een eigen ClassLoader (en dus geheugen) voor de eigen klassedefinities hebben. Als je vervolgens een ThreadLocal gebruikt, wordt de klassedefinitie van de objecten daarin vastgehouden binnen die algemene Thread. En doordat die klasse-definitie wordt vastgehouden wordt effectief dat hele stuk geheugen (inclusief alle klassedefinities voor de webapplicatie) vastgehouden. En dat blijft dan dus ook in de heap aanwezig nadat je de applicatie hebt undeployed.

Dat geheugenlek met ThreadLocals is op zich goed te voorkomen, maar in het kort komt het advies daarbij er op neer op het direct weer verwijderen van het object nadat de request is afgelopen. Op die manier bespaar je dan uiteindelijk wel wát keren dat je dure objecten opnieuw worden aangemaakt, maar niet zoveel als idealiter mogelijk is. Belangrijker nog is dat het vereist dat de code die het einde van je request afhandelt ook nog even rekening houdt met allerlei zaken die elders (misschien wel in je template-engine) spelen.
Alternatieven voor ThreadLocal
In onze webapplicaties vond ik het niet erg mooi om allerlei 'kennis' van de interne processen nog in de afhandeling van het einde van requests te verwerken. Bovendien voelt het ook vreemd om de code zo aan te passen dat zo'n langlevend object uiteindelijk toch maar voor enkele tientallen of een paar honderd format's gebruikt wordt.
Object pool
Een veelgebruikte techniek om 'dure' objecten te bewaren en te kunnen hergebruiken is een Object pool. Daarbij maak je enkele instanties van je klasse aan en bewaar je die op een centrale plaats. Vervolgens kan er elke keer als er zo'n object nodig is eentje gereserveerd worden en kan het aan het einde van de werkzaamheden weer teruggegeven worden.
Deze aanpak is onder andere erg gebruikelijk voor verbindingen met databases en andere databronnen. Daar heet het dan vaak een Connection Pool. Doordat het geen relatie met de Threads heeft is er verder geen sprake van dat type geheugenlek.

Er zijn vele Object pools te vinden. Ik heb een aantal ervan in JMH-benchmarks omgezet. Dat ging om eenvoudige zelfgeschreven varianten met queues of om generieke Object-poolimplementaties. De queues waren allemaal gebaseerd op de standaardimplementaties van Java, zoals de ConcurrentLinkedQueue, de ArrayDeque in combinatie met synchronization of locks en de ArrayBlockingQueue. De pools bestonden uit een voorbeeld op de Semaphore, de Apache commons Pool, de Fast object pool en een idee voor een Lock free pool.

<iframe src="//charts.tweakzones.net/kpFFR/1/index.html" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" webkitallowfullscreen="webkitallowfullscreen" mozallowfullscreen="mozallowfullscreen" oallowfullscreen="oallowfullscreen" msallowfullscreen="msallowfullscreen" width="600" height="400"></iframe>

Op de Fast object pool na hadden alle implementaties als nadeel dat ze significant trager werden naarmate er twee of meer threads actief werden. En in vergelijking met de ThreadLocal was het sowieso dramatisch, de snelste implementatie bij één thread kwam nog op een redelijke 21 miljoen formats per seconde; maar bij vier threads was de snelste slechts 17 miljoen. Dat is vooral slecht vergeleken met de 130 miljoen die bij ThreadLocal mogelijk was. Het was zelfs vrij slecht in vergelijking met domweg steeds een nieuw NumberFormat-object aanmaken, die zat met vier threads op 6,4 miljoen formats per seconde.
Blijkbaar is het principe van Object pool toch niet zo geschikt voor dit soort objecten, waarbij het 'echte werk' (de format-aanroep) slechts heel kort duurt.
Objecten per Thread bewaren
Aangezien de Object pools nogal tegen vielen, ben ik een ander idee gaan uitwerken. Er lijkt niet echt een naam voor te bestaan, maar uiteindelijk heb ik een soortgelijke constructie als de ThreadLocal gemaakt. Het belangrijkste verschil is dat de objecten nu niet meer 'in' de Thread worden opgeslagen. Dat heeft als groot voordeel dat als de webapplicatie stopt, dat dan ook alle objecten vrij gemaakt kunnen worden en de geheugenlek niet meer voorkomt.

De objecten worden domweg in een Map<Long, T> opgeslagen, waarbij T het te bewaren object is en de Long de identifier van een Thread representeert. Uiteindelijk heb ik daar diverse implementaties voor gemaakt. Dat ging om ConcurrentHashMap, ConcurrentSkipListMap, Trove4J's TSynchronizedLongObjectMap, Google's Guava Cache, ConcurrentLinkedHashMap, Caffeine's Cache.

In de praktijk bleek met name de standaard ConcurrentHashMap van Java erg goed te presteren. In onderstaande grafiek is ter referentie ook weer het aanmaken van losse objecten per format meegenomen.

<iframe src="//charts.tweakzones.net/JyuPo/1/index.html" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" webkitallowfullscreen="webkitallowfullscreen" mozallowfullscreen="mozallowfullscreen" oallowfullscreen="oallowfullscreen" msallowfullscreen="msallowfullscreen" width="600" height="400"></iframe>
Zelf uitproberen?
Als je zelf wilt kijken hoe een en ander presteert, dan kan je op onze github-repository de code bekijken en clonen. Je kan uiteraard ook in je eigen clone benchmarks toevoegen als je een goed idee hebt, dat volgens jou (nog) beter presteert dan de ConcurrentHashMap of de ThreadPool.
Als je denkt dat (een deel van) de benchmarks verkeerd zijn geïmplementeerd, hoor ik dat natuurlijk ook graag.
Over de benchmarks
De benchmarks zijn gedraaid met Java's Microbenchmark Harness. De cijfers zijn verzameld op een Intel Core i5-4690 met vier cpu-cores en een kloksnelheid van 3,5GHz (met pieken door Turbo Boost naar ruim 3,8GHz). Dit systeem draait op Windows 10.

"Er zijn genoeg alternatieven voor banners!" Nou, welke dan?

Door ACM op zondag 25 maart 2012 23:15 - Reacties (40)
Categorie: Tweakers.net, Views: 7.973

In de diverse discussies over advertenties, die elke zoveel tijd weer opnieuw beginnen, wordt regelmatig door bezoekers gesteld dat er alternatieven zijn voor die opzichtige flashbanners. Net weer in een mailwisseling met een gebruiker.

Hoewel we in de praktijk al aardig op zoek zijn met ons "Non-spot" advertentieteam, blijft er in de regel toch teruggegrepen worden naar (flash)banners die in meer of mindere mate opzichtig zijn. Over het algemeen geldt tenslotte; hoe groter, hoe meer geld het ons oplevert (en hoe strengere regels we hanteren).
Voorbeelden van die non-spotuitingen zijn trouwens zaken als het mogen testen van de HTC One X en de wervingsactie van de KLPD. "Helaas" worden bij dat soort campagnes alsnog gewone banners geplaatst om de speciale pagina's aan te jagen.

Het is in deze blog niet mijn bedoeling om weer allerlei discussie over hoe erg flash- en html5-banners zijn op te rakelen. Dat er gebruikers zijn die zich er aan storen (en/of ze blokkeren) weten we uiteraard al lang :)

Waar ik vooral benieuwd naar ben, is hoe men durft te stellen "er zijn genoeg alternatieven" zonder dan ook met bruikbare voorbeelden te komen. Ik heb zelfs wel eens iemand zien stellen - toen ik er over doorvroeg - dat ik dat zelf maar uit moest zoeken, want het was tenslotte niet zijn verantwoordelijkheid dat Tweakers.net geld verdient. Op zich had die bezoeker natuurlijk gelijk met die stelling, maar ga dan niet eerst stellen dat je betere manieren weet en dan niks toelichten...
Donaties
Er zijn natuurlijk al allerlei manieren die we hebben gezien, een van de meest genoemde is het donatiesysteem. Wikipedia is dan een veelgebruikt voorbeeld, maar die vergelijkging gaat niet op. Vergeleken met Wikipedia hebben wij namelijk heel veel personeel voor de bezoekers die we bedienen. Zelfs als we de mensen die met marketing en sales bezig zijn niet meetellen zitten we al op ruim 30 man aan personeel dat direct voor Tweakers.net werkt. Daar komt dan uiteraard nog een rits mensen die indirect voor Tweakers.net werken bij (zoals P&O, finance, de facilitaire dienst, etc) en de sales- en marketingmensen.

Ik ga geen cijfers voor de inkomsten en uitgaven noemen. Maar als je voor het gemak aanneemt dat die 30 mensen een modaal inkomen krijgen en dan 1,5x zoveel kosten dan als ze aan loon krijgen, dan kan je zelf wel uitrekenen hoeveel donaties van 10cent of 1 euro we dan moeten krijgen. Probeer dan nog te schatten hoeveel van de circa 3 miljoen bezoekers die we bereiken ook daadwerkelijk jaarlijks zal gaan en blijven doneren... Als je ziet hoeveel moeite het Wikipedia kost, dan verwacht ik niet dat Tweakers.net een kans heeft om ook maar in de buurt van de loonkosten te komen :)

Bovendien heeft het vziw ook nog allerlei lastige juridische haken en ogen. Ook varianten met micro-betalingen zien we niet zitten, voor zover er uberhaupt al van dat soort systemen van de grond zijn gekomen.
Een donatiesysteem levert in onze ogen dus een te onbetrouwbare - en met onze bezoekersaantallen waarschijnlijk ook te lage - inkomstenstroom op. Maar dat kunnen we natuurlijk verkeerd zien.
Abonnementen
Er wordt ook wel gesteld dat we meer abonnementen zouden willen (of moeten) verkopen. In werkelijkheid bieden we die eigenlijk meer als een dienst aan, dan dat wij er echt signficant aan verdienen. Als we een met de banners vergelijkbare hoeveelheid inkomsten uit abonnees willen halen zullen we er niet een paar honderd, maar tienduizenden moeten zien te verkopen... Of we moeten er veel meer geld voor gaan vragen.

Gezien de reacties van bezoekers in dergelijke discussies en naar onze eigen inschatting gaat ook dat niet werken. We verwachten niet dat er - buiten degenen die er nu al een hebben - nog veel andere bezoekers bereid zijn om te betalen voor deelname aan de community van en het bekijken van de content op Tweakers.net. We zijn uiteraard de huidige abonnees dankbaar voor hun steun, maar zien het niet gebeuren om wat voor abonnementsstructuur dan ook werkend te maken voor heel Tweakers.net.
Als je in de vorige alinea aan het rekenen was gegaan; onze abonnementen kosten nu 15 euro per jaar, je kan ook hier dus uitrekenen hoeveel we er moeten verkopen :P

Zolang we de content of andere onmisbare site-delen niet achter een betaalmuur gooien, zullen gebruikers niet heel erg gemotiveerd zijn er een aan te schaffen. En als we dat wel doen gaan er ook veel gebruikers op zoek naar een alternatief dat gratis is gebleven.
Welke alternatieven zijn er dan?
Ik weet het eigenlijk niet, maar moet daarbij zeggen dat het ook niet echt mijn verantwoordelijkheid is. Ik ben meer iemand die van de zijlijn toekijkt naar zowel wat de bezoekers zeggen als wat wij intern doen, maar ik ben niet heel actief betrokken bij de onderzoeken die marketing en sales uitvoeren.
Er zijn uiteraard allerlei interessante ideeen die voor bepaalde niches werken verzonnen, maar welke zouden er ook voor Tweakers.net werken? Er is vast van alles met gamification mogelijk, maar tegelijkertijd is iedereen ondertussen vast ook de vaak niet geheel optionele in-app uitbreidingen in de diverse mobiele en online games zat...

Wie een goed idee (of een vraag) heeft mag het zeggen, we horen het namelijk graag :)

En als jij een briljant idee hebt maar ons het niet gratis wil geven is daar ook vast over te praten. Tweakers.net is tenslotte geen non-profit organisatie (en zal dat ook niet worden), dus op een andere, betere manier inkomsten gaan genereren mag ook best een investering vereisen.

Dit blog is bedoeld als een opening voor discussie over alternatieven voor advertenties. Ik weet dat flashbanners soms ruk zijn, dus dat hoef je niet te benadrukken. Dat gezegd hebbende, ze leveren ons vooralsnog een aardige duit op, dus ze zullen niet zomaar afgeschaft worden. Tenzij er dus een echt werkbaar alternatief is.

Serverkeuzes bij Tweakers.net

Door ACM op maandag 5 maart 2012 22:13 - Reacties (22)
Categorie: Tweakers.net, Views: 7.572

Elke keer als we nieuwe servers presenteren in een .plan of ander artikel wordt daar door gebruikers op uiteenlopende manieren op gereageerd. De meesten vinden het uiteraard coole hardware en laten dat weten, maar een enkeling neemt de moeite vragen te stellen of opmerkingen te plaatsen.
En dat waarderen we zeer, daarom heb ik de moeite genomen de keuzes en redenaties hieronder nog een keer samen te vatten. En wederom, voor vragen en opmerkingen staan we nog steeds open. We hebben zelfs wel eens onze keuzes aangepast naar aanleiding van opmerkingen van lezers maar dat geven we uiteraard niet toe! :P
Waarom niet in de Cloud?
Aangezien de Cloud en het gebruik van virtualisatie in is, wordt daar uiteraard naar gevraagd. Daar wordt o.a. bij gesuggereerd dat het goedkoper zou zijn, eenvoudiger te schalen is/meer capaciteit beschikbaar maakt, minderkost, betere uptimes biedt en nog wel meer positieve punten. Bij deze loop ik de belangrijkste drie punten even langs.
Uptime
Zowel Amazon als Microsoft hebben bewezen dat ze wel degelijk down kunnen gaan.
Dus de uptime is niet per se beter dan die van onszelf, die zit namelijk sinds mei 2011 op bijna 99.9% met in totaal minder dan 9 uur downtime. Daarbij werd meer dan de helft van die "downtime" veroorzaakt door een nachtelijke storing waardoor pageviews vertraagd werden. Dat werd op zich wel terecht als "down" geregistreerd, maar de site werkte in werkelijkheid nog wel gewoon. Zo'n probleem had zich ook bij een Cloud dienst kunnen voordoen, aangezien het niks met de onderliggende hardware had te maken :)
Uitval door server- en netwerkhardware was dus nog zeldzamer.
Schaling
Of een applicatie goed of slecht schaalt hangt vooral af van de applicatie en diens onderdelen zelf af. Niet alle delen van een website kunnen even eenvoudig geschaald worden. Denk daarbij onder andere aan relationele databases, zware processen en pagina's en bestandssystemen. En als die software dus niet geschikt is om op veel langzame in plaats van weinig snelle CPU's te werken, dan gaat je dat op zijn minst een hoop tijd (en dus geld) kosten om dat aan te passen.
En inderaad, de software van Tweakers.net is er niet voor ontwikkeld. Dat betekent niet dat het niet zou werken met een schaling in de breedte, maar wel dat er gegarandeerd een aantal pijnpunten in zullen zitten.

Zeker met de ontwikkeling van de hardwareperformance van de afgelopen tien jaar was het voor Tweakers.net geen enkel probleem om domweg verticaal te blijven schalen. En met de introductie van SSD's in databaseservers hebben we ook het veranderen van de moeilijkst te schalen software weer een behoorlijke tijd kunnen uitstellen. Sterker nog, ik voorzie voor zeker de komende drie jaar weer geen reden om de SQL-server in de breedte te gaan schalen.

Bovendien zorgt schalen in de breedte er niet voor dat iedere losse pageview of query snel is. Alleen maar dat je er veel tegelijk aan kan. En wij willen ook graag de indivuele pageviews snel hebben. Naast een stukje imago blijkt ook dat het beter is voor je pageviews en gebruikerstevredenheid. Uiteraard wordt een groot deel van de performance bepaald aan de browserzijde, maar we willen ook de serverzijde niet zomaar vertragen.
Lagere kosten
Momenteel wordt tweakers.net effectief beheerd door slechts 1 systeembeheerder. We denken niet dat we met minder dan dat toe kunnen :P Afgezien daarvan zit je natuurlijk met aanschafkosten, elke keer dat we dat weer berekenen blijkt dat de totale huurkosten voor een VM hoger zijn dan een vergelijkbare dedicated server; een Amazon EC2 High Memory instance (als primaire MySQL-server) kost je circa 26000 dollar over drie jaar, daar kopen wij makkelijk 3 of 4 vergelijkbare servers voor... Daarbij hebben wij uiteraard wel de mazzel dat ons rack en stroomverbruik heel goedkoop is. Maar tenzij je dat soort machines niet continu nodig hebt, is het aanzienlijk duurder om ze in de Cloud te huren.
Waarom zulke dikke hardware?
Ook wordt vaak gesuggereerd dat we overdreven dikke hardware kopen en met veel minder toe zouden moeten kunnen. Dat klopt. Althans, meestal... Doordat we geen gebruik maken van Cloud-diensten (en zelfs als we dat zouden doen) kunnen we niet zomaar in een paar seconde even wat meer capaciteit erbij inzetten. We moeten de hardware dus aanschaffen met voldoende capaciteit voor de komende drie jaar. Bovendien moeten ze de pieken aan kunnen, de dalen lukt met bijna elke server wel ;)

Tijdens de weggeefactie van Diablo 3 key's in februari, ontstonden een paar hele hoge pieken. In onderstaand plaatje zie je dat er ineens 2x zoveel pageviews waren tijdens wat normaliter al de piek van de dag is. Op dat soort pieken kopen we onze hardware in, niet op de belasting van de nacht of zelfs dag ervoor of erna :)

Tweakers.net pageviews op 21 februari

Op hetzelfde plaatje zie je trouwens tussen 14u en 15u een ander fenomeen waarom we zoveel overcapaciteit per server plannen. Doordat er wat werkzaamheden met onze netwerkswitches waren, lagen tijdelijk 3 van de 4 webservers eruit. En dat ging eigenlijk nog best goed, de piek van een uur later had ie niet aangekund, maar het normale verkeer had ie weinig moeite mee.

Verder geldt uiteraard ook hier de opmerking over verticaal vs horizontaal, sommige software is nou eenmaal eenvoudiger verticaal te schalen dan horizontaal. En bovendien zie je het verticaal direct voor elke pageview terug. Uiteraard is er een grens waar de ROI van een nog dikkere cpu zeker niet meer terug komt en we zoeken die ook per configuratie gevoelsmatig weer op; we hebben geen tijd en mankracht voor uitgebreide benchmarks met diverse configuraties, dus we zullen eerder "iets te zwaar" dan "iets te licht" aanschaffen :)
Naast de dikke hardware is er uiteraard ook nog "veel" hardware. Dat doen we vooral om redundantie in te bouwen, we streven er naar om van alles minstens 2 stuks te hebben, zodat er een uit kan vallen kan zonder direct grote en vooral langdurige invloed op de site te hebben.

Alternative search engines have lousy crawlers en

By ACM on Thursday 1 December 2011 00:08 - Comments (7)
Category: Tweakers.net, Views: 10.800

There are a few alternative search engines arriving every year. All claim some distinctive features, most try to be some alternative to the big players either as a whole or for a specific niche. Yacy is one of the latest that saw a public announcement, although it was around for much longer.

As a publisher, we see one very common denominator; they're generally lousy crawlers. Especially compared to Googlebot and Bingbot. Tweakers.net offers over a million "articles" (forum topics, news articles, reviews, etc). Many of those pages have links to tweak some aspects of the current view (sorting, paging, filtering). On top of that, we offer links to specific finer grained information, like a direct link to a comment on a article or topic.

So while we offer over a million articles, we've in the order of a hundred million unique links on our site. We don't need, nor want, all those urls treated as important and/or distinct pages on our site. I.e. we don't want, nor need, to have those url's followed, they're there for our visitors but not very usefull for search engines. We generally don't even see those urls as a different page and the particular content will have been indexed via some other (more important) link anyway.
So to steer the crawlers, we mark them with rel='nofollow' and add a line to our robots.txt if possible. Apart from having popularised and generally obeying these markers, Googlebot and Bingbot offer additional tools to reduce this problem. For instance, Google allows you to specify how GET-parameters should be interpreted, so they know how to treat links with them.

Yes, we're one of the publishers that use the rel=nofollow to actually just mark url's to be ignored from the link-graph. We don't really care about all its added bonuses that used to be there, like the 'pagerank'-skulpting. We just really don't want or need those url's to be indexed, saving "them" and us processing time and leaving room for crawlers to actually spend time to index the parts we do want them to index.

The new crawlers generally lack (full) support for those aspects to steer crawlers, even the more basic aspects. Its not uncommon for them to:
  • Ignore nofollow on links or in metatags
  • Ignore noindex in metatags
  • Partially or fully ignore the robots.txt
  • Fail to fully understand the robots.txt
  • Fail to limit their amount of requests to some decent value
  • Fail to understand how relative links work in combination with a base href (untill a few years ago Google didn't understand that too well either)
  • Fail to understand that links are given in html, and should thus be correctly decoded (i.e. no & in urls)
  • Not offer any insight in why our pages are being crawled
With that in mind, we are fairly quick to decide to block entire search engines. Either by blocking the ip addresses or adding some lines to our robots.txt. Given its behavior, it wouldn't suprise me if we're going to block Yacy (for now) as well... I've already seen it do requests to url's blocked via our robots.txt and it doesn't seem to understand nofollow too well. We don't mind being indexed by robots, but we do if they do it incorrectly and/or inefficiently.

Advertenties op Tweakers.net: een paar mythes en misvattingen

Door ACM op vrijdag 8 april 2011 11:45 - Reacties (97)
Categorie: Tweakers.net, Views: 42.019

In de loop der jaren heb ik de nodige bannerdiscussies op Tweakers.net meegemaakt. Ik ga hier niet proberen te ontkennen dat die dingen irritant kunnen zijn. Maar er zijn ook gewoon wat misvattingen en mythes rond banners, zowel in het algemeen als op Tweakers.net. Daar heb ik er een aantal van verzameld en wat uitleg bij gegeven :)

Als ik er niet op klik, levert het jullie toch niks op, dus kan ik 'm net zo goed blokkeren?
Een belangrijke mythe met banners is dat bezoekers vaak denken dat banners alleen geld opleveren als er op geklikt wordt. Er zijn in de advertentiewereld vijf afrekenmodellen: CPC, CPS, CPA, CPM en Fixed Fee.

Bij CPC wordt er inderdaad per klik betaald, dit model wordt veel bij bulkadvertenties gebruikt. O.a. Google's Adsense gebruikt dit model veel. Op Tweakers.net wordt dit model nauwelijks bij de gewone advertenties gebruikt, behalve Adsense hebben we verder geen bulkadvertenties. Dit model wordt verder wel het meest in de pricewatch gebruikt.

CPS en CPA zijn aan elkaar verwant, hierbij betaalt de adverteerder pas als er wat verkocht wordt of een handeling gedaan wordt (bijvoorbeeld inschrijven op een nieuwsbrief of evenement). Het grootste nadeel hiervan is uiteraard dat de inkomsten sterk afhangen van hoe goed de adverteerders zelf te werk gaan. Bovendien ben je vaak afhankelijk van een tussenpartij die de bron van een aankoop moet zien te traceren naar de goede partij.
Het grootste voordeel is dat de inkomsten 'per keer' vaak behoorlijk hoog zijn. Soms is dat een vast bedrag, soms een percentage van het aankoopbedrag en soms gecombineerd. Daar staat uiteraard tegenover dat het aantal 'keer' dat het gebeurt doorgaans nogal laag is :) CPS wordt met sommige klanten in de pricewatch gebruikt, verder komt het in principe niet voor op Tweakers.net.

De meest gebruikte modellen voor "display advertising" (aka banners) bij Tweakers.net zijn CPM en Fixed Fee. Bij de eerste wordt er voor elke duizend vertoningen een bedrag afgerekend. Fixed Fee wordt vooral gebruikt voor de meer complexe uitingen, zoals een dag lang een "site takeover", of als er vanuit Tweakers.net veel inspanning bij komt kijken. Uiteraard kunnen de diverse modellen ook gecombineerd worden, zoals een vast start bedrag aangevuld met CPM of CPM gecombineerd met CPC, CPS of CPA.

De mythe is dus maar gedeeltelijk waar. Bij de meeste banners die je op Tweakers.net en veel andere sites ziet worden de inkomsten juist bepaalt door de vertoningen. Zelfs bij fixed fee, want dat vaste bedrag is doorgaans deels afgesproken op basis van een verwacht aantal vertoningen. Als een bezoeker op een advertentie klikt levert dat ons vaak juist niets extra's op.

Adsense is daarbij een verhaal apart, dat combineert CPC-uitingen met CPM- en CPA-uitingen. De inkomsten daarvan zijn overigens relatief laag tov de "display" uitingen en we gebruiken expres de grafische uitingen van Adsense niet doordat die vaak lelijk/storend zijn en we daar nauwelijks invloed op hebben.

Ik kijk er toch niet naar.
Ik heb hier geen referenties naar wetenschappelijk onderzoek bij, maar voor zover ik weet word je over het algemeen (onbewust) toch nog wel een beetje beïnvloed door advertenties. Zelfs als je denkt er niet naar te kijken. Dus heeft het voor de adverteerders ook dan zin dat de advertenties bij jou in beeld komen.

Als ik 'm download, maar niet weergeef, is het toch ook goed?
Het komt voor dat gebruikers voorstellen om een plugin te gebruiken die de banners wel downloadt, maar niet weergeeft. Hoewel dit op korte termijn wellicht werkt, zullen adverteerders er niet heel blij van worden en waarschijnlijk uiteindelijk minder hoge bedragen per vertoning gaan willen betalen.

Jullie hebben toch zat bezoekers, dus wat maakt het uit dat ik banners blokkeer?
Als iedereen zo denkt... :P

Ik bepaal zelf wat ik op mijn scherm krijg!
Dit is natuurlijk geen mythe en ook geen misvatting. Het is absoluut waar dat de bezoeker uiteindelijk zelf bepaalt wat er op zijn scherm verschijnt. Dit wordt echter vaak genoemd als verweer tegen het in de algemene voorwaarden opgenomen stukje over dat wij mensen mogen blokkeren als ze onze advertenties actief weren. En in die context geldt natuurlijk ook het omgekeerde: wij mogen zelf bepalen of en in welke vorm we iemand de site willen laten zien :)
In de regel doen we daar overigens niet zo moeilijk over. Er moet aardig wat gebeuren voor je een ban krijgt.

Zonder bezoekers, geen Tweakers.net
Wederom geen mythe. Het is absoluut waar dat Tweakers.net alleen overleeft doordat het bezoekers heeft. Maar het is vooral irrelevant in de bannerdiscussies: er zijn nou eenmaal inkomsten nodig om de uitgaven te dekken. En de uitgaven zijn nodig om bezoekers aan te trekken en/of terug te laten keren.

Je kan toch een abonnement nemen? / Jullie proberen ons een abonnement op te dringen.
Bezoekers wijzen elkaar vaak onderling op het bestaan van het 'bannervrij abonnement' zodra er een opmerking over de advertenties komt. Dat abonnement bieden we uiteraard aan voor diegenen die Tweakers.net wel inkomsten gunnen, maar geen banners willen zien.
Desalniettemin doen wij weinig moeite om gebruikers een abonnement te laten nemen, we beseffen ter dege dat iemand niet elke site die hij bezoekt geld wil geven. En zelfs 15 euro/jaar is dan uiteindelijk best veel. Bovendien is het voor ons maar de vraag of dat meer oplevert dan we met bannervertoningen aan diezelfde bezoeker zouden verdienen. Als iemand een jaar lang één banner per dag ziet zitten we break-even met 4,1 cent per vertoning. En dan negeer ik nog het feit dat van die 15 euro nog de btw af moet en een deel bij de betaaldienst blijft hangen :)

Die servers moeten natuurlijk ergens van betaald worden. Die servers/de bandbreedte wordt toch gesponsord? Jullie werken toch met vrijwilligers?
Drie punten die op zichzelf geen mythe zijn, ze zijn zelfs grotendeels waar. Alleen de servers worden al jaren niet meer gesponsord. Maar de onderliggende mythe is dat er blijkbaar nogal eens gedacht wordt dat Tweakers.net weinig kosten heeft of dat servers en bandbreedte de grootste post zouden zijn. In werkelijkheid ligt dat wat anders. Tweakers.net heeft - ondanks een actieve groep vrijwilligers - momenteel ook ongeveer 45 mensen in dienst.
Als we voor het gemak aannemen dat ze gemiddeld genomen 'modaal' verdienen (33.000 euro per jaar bruto) en dat er 50% overheadkosten zijn dan kom je al op ruim 2 miljoen euro per jaar aan personeelskosten... Dat is dan ook met afstand de grootste kostenpost, ik geloof dat servers pas op de derde of vierde plek komen. Dus het klopt dat servers geld kosten, maar als dat de enige of hoogste post was, dan hadden we met veel minder advertenties toegekund :P

VNU moet natuurlijk geld verdienen... / Tweakers.net is heel erg commercieel geworden
De eerste is kortweg waar, maar het wordt vaak als een equivalent voor de tweede gepresenteerd of met een hele negatieve toonzetting gesteld. Tweakers.net is helemaal niet "sinds kort" commercieel en ook is het mijns inziens niet "meer commercieel geworden". Maar Tweakers.net is natuurlijk wel "groter" geworden, waardoor het misschien wat meer naar voren komt.
Tweakers.net is echter al jaren commercieel, er wordt al jaren geprobeerd meer inkomsten te vergaren dan dat er uitgaven zijn; er wordt dus al jaren geprobeerd winst te maken. En met 'al jaren' bedoel ik dan in ieder geval al sinds ik in januari 2002 aangenomen werd, niet pas sinds de overname door VNU in 2006 :)

Door de overname door VNU is het veel erger met banners geworden.
Er wordt wel eens een causaal verband gesuggereerd tussen "de overname" en dat het erop lijkt dat advertenties geleidelijk aan steeds vaker voorkomen en/of steeds groter worden. Dat er steeds meer advertenties op Tweakers.net zouden staan is volgens mij niet waar, maar dat ze steeds groter worden waarschijnlijk wel.
Wat hier een mythe aan is, is dat dat door VNU veroorzaakt zou zijn. Voor zover ik kan nagaan is dit domweg de ontwikkeling van "de markt" en zou dit ook gebeurd zijn als Tweakers.net niet overgenomen was. Kijk maar naar Fok, zij zijn bijna even oud als Tweakers.net, maar niet overgenomen door een derde partij en vertonen een vergelijkbaar (of erger?) beeld met steeds grotere/opdringerigere banners.

Dan weigeren jullie die banner toch gewoon? / Waarom die grote advertenties, die kleine banners/tekstbanners vind ik niet erg?
Dit is een lastige. We zouden graag irritante advertenties weren, sterker nog, dat gebeurt ook geregeld. Het is niet ongebruikelijk dat voorstellen van klanten helemaal niet of slechts in afgezwakte vorm uiteindelijk bij de bezoekers op hun scherm komen. Maar het blijft natuurlijk een feit dat wij afhankelijk zijn van de vraag naar advertentieruimte. Als niemand vraagt wat wij willen bieden... dan komt er geen geld in het laatje. De adverteerders daarin opvoeden is iets wat we wel proberen, maar dat gaat via zoveel verschillende partijen en mensen, dat het maar de vraag is of de mening van de Tweakers uiteindelijk wel echt bij de beslissingsnemers bij de klant terechtkomt :/

Het is op zich wel mogelijk - met onze hoeveelheid verkeer - om vooral de kleinere advertenties in bulk neer te zetten, bijvoorbeeld via Adsense' grafische advertenties. Maar dan kunnen we het ons nog minder permiteren om kieskeurig te zijn. En ook de relevantie van de advertenties voor de bezoeker komt dan volledig in handen van zo'n derde partij. We tonen dan ook liever geen advertenties dan slechte/niet passende advertenties in grote aantallen. Dat heeft dan wel de consequentie dat de adverteerders die we krijgen wel wat meer eisen stellen.

Jullie verkopen reviews! Kijk maar naar de Heavy Rain review
Aangezien deze in de reacties hieronder aangehaald wordt, heb ik een quote van mijn eigen reactie hier nog even gekopieerd:
Het verband zit hem in het simpele feit dat het een voldoende interessant spel moest worden dat wij 'm wel wilden reviewen. En daarbij krijgen wij een embargodatum opgelegd waarvoor we geen review mogen publiceren (anders krijgen we uberhaupt geen reviewmateriaal). Sony pakt diezelfde datum natuurlijk ook om dan zo'n royale campagne te starten en Tweakers.net is een van de sites waar veel gamers komen.

Sony heeft de review niet vooraf ingezien en de redactie heeft niet de opdracht gekregen om voor Sony de review extra gunstig af te zetten. Hadden ze die opdracht wel gekregen, dan zie ik onze hoofdredacteur ervoor aan om de review - ook al is ie nog zo netjes - niet te publiceren of het cijfer er juist uit te schrappen.


Er zijn vast nog meer punten die genoemd zouden kunnen worden, maar dit waren de belangrijkste die ik kon bedenken. Als ik iets vergeten ben of verkeerd genoemd heb, dan hoor ik het uiteraard graag. Vragen en opbouwende kritiek zijn uiteraard ook welkom :)

[update]
Quote van mijn eigen reactie hieronder toegevoegd ivm 'de reviews zijn te koop'-mythe.