Development-round-up - iteratie #3

In de eerste twee weken van augustus hebben we alweer de derde Scrum-iteratie afgerond. Dit keer zijn er 49 tickets opgelost. Daarvan is 'helaas' het grootste deel van technische aard of voor intern gebruik, dus de .plan is daarom ook vrij kort

Social buttons

Direct bij het introduceren van de social buttons werden we er op gewezen dat ze niet onder .plans stonden, dat hebben we bij deze rechtgezet en ze ook gelijk maar onder meukupdates gezet. Voor de duidelijkheid, ze kunnen nog steeds uitgezet worden.

Verder waren er wat bugjes met Facebooks like-button: zo werkte deze niet zo best in IE7 en IE8 en verscheen de tekst 'Like' ineens in het Nederlands. Helaas werden deze vooral door Facebook zelf veroorzaakt, maar ondertussen zijn ze ook weer opgelost.

Jobs

Deze iteratie is er wat tijd besteed aan de integratie van Jobs met de rest van de site. Bij forumtopics kunnen nu, net als bij nieuws, relevante vacatures worden getoond. We hebben gelijk de koppelingen waarop dat gebeurde wat geactualiseerd, dus hopelijk is de relevantie ook een stukje beter dan voorheen.

Pricewatch

In de pricewatch is de plek van de 'filter reset'-knop van onder het formulier naar bovenaan verhuisd. Verder kan er nu gesorteerd worden op meervoudige specificaties, die was in het verleden nog niet uitgewerkt omdat dit een nogal complexe sortering oplevert. Hoe sorteer je bijvoorbeeld 'eSATA', '2x eSATA, 2x USB 2.0' en '2x USB 2.0' met elkaar? Daar hebben we nu wel een antwoord op verzonnen, waardoor een en ander nu in ieder geval gesorteerd wordt. Die sortering zal vast niet altijd even logisch zijn, maar dat is nou eenmaal het nadeel van zulke complexe gegevens

Sessie-opslag/MongoDB

Ruim een jaar geleden verhuisden we de opslag van de sessies van MySQL naar MongoDB. Hoewel we nog steeds achter die keuze staan, bleek het toch ook wat nadelen te hebben. MongoDB kan wat minder goed overweg met data die relatief snel ook weer verwijderd wordt. En hoewel we veel trouwe bezoekers hebben, wordt het gros van de nieuw aangemaakte sessies maar één keer gebruikt. Er zijn uiteraard meerdere redenen waarom die sessies onnodig aangemaakt worden: veel zullen aan bezoekers en robots uitgedeeld worden die onze cookies niet opslaan en dus bij elke pageview als nieuwe bezoeker te zien zijn, maar ook als we naar ip's kijken komt een groot deel voor langere tijd niet meer terug.

Op dagbasis gooiden we daarom zo'n 200.000 sessies weg van bezoekers die een week lang niet teruggekeerd zijn na hun eerste pageview. Het totaal aantal sessies dat we momenteel in de database hebben schommelt zo rond de vier miljoen. Die verwijderopdracht was een ander aspect waar MongoDB niet heel goed tegen kon, hoewel veranderingen aan collections op zich wel los staan van leesacties erop, was het uiteindelijk toch een blocking operatie. Aangezien die handeling zo'n tien seconden duurde, leverde dat merkbare vertragingen op.

Om deze onnodige vulling en belasting van MongoDB te verhelpen slaan we nu de nieuw aangemaakte sessies eerst in Memcached op. Mocht iemand toch terugkeren, dan schrijven we de sessie pas weg in de meer permanente opslag van MongoDB.

De oplettende bezoeker zal merken dat we die informatie in de id van de sessie verwerken en dat de eerste paar bytes nu permanent oplopend zijn. Die laatste wijziging zorgt er voor dat nieuw aangemaakte sessies in principe niet meer op een willekeurige plek in de database terecht komen, maar altijd ergens aan het eind.

Reacties (20)

[GlowMouse]

'Wij' maken pas een sessie aan als we weten dat de bezoeker cookies ondersteunt: bij het eerste bezoek krijgt hij een init-cookie, en pas als hij een request doet met dat cookie erbij krijgt hij een echte sessie. Misschien een idee?

[ACM]

Dat doen we nu effectief ook maar dan dus in memcached. En met de aanvullende controle dat wij zeker weten dat het inderdaad dezelfde initialtie was en de datavulling van de eerste stappen (zoals devicegrades etc) dan al geregeld hebben. En op deze manier hoefden we eigenlijk geen aanvullende code te wijzigen (er is altijd een geldige sessie, dat ie evt vanuit memcached kwam is verder niet relevant dan)

De hoeveelheid sessies op zich was ook niet zo'n probleem, maar vooral het hoge percentage sessies dat weer weggegooid moest worden, en memcached doet dat een stuk efficienter dan mongodb uberhaupt kan.

[Reactie gewijzigd door ACM op 24 juli 2024 05:58]

[Hmmbob]

Als we het dan toch over het sessiebeheer hebben :

Persoonlijk zou ik het nog steeds erg prettig vinden als ook de gelezen Frontpage-items in de sessie terecht komen. Wat ik bedoel is dat als je op PC1 (werk?) een FP artikel leest, deze op PC2 (thuis?) ook niet meer rood gemarkeerd wordt, wat nu nog wel zo is.

Vergelijkbaar met de werking van het forum dus. Ideetje?

[Reactie gewijzigd door Hmmbob op 24 juli 2024 05:58]

[Niet Henk]

Ik ben het geheel met je eens (zelf gebruik ik mijn laptop en mijn desktop door elkaar). Ik raak regelmatig hierdoor geïrriteerd, en open dan maar gewoon alle items, alleen om het rode weg te krijgen.

Het zou natuurlijk ontzettend fijn zijn als jullie dit inderdaad ergens konden opslaan waar het accountgebonden is. Ik begrijp dat het niet het makkelijkst is, maar het verbeterd wel de user experience.

[Milly]

f5 doet ook wonderen als je de rode items weg wilt hebben

Maar Groentenboer heeft wel een goed punt inderdaad.

[Reactie gewijzigd door Milly op 24 juli 2024 05:58]

[jip_86]

Wanneer krijg je wat nu te zien mbt de gerelateerde jobs? Er zijn nu de Google Ads, de gerelateerde producten en nu dus ook gerelateerde jobs? Ik heb even snel gekeken, maar ik zie er altijd maar een van de drie staan.

[ACM]

Als er gerelateerde banen zijn krijg je die (maar dat is voor een relatief beperkt aantal forums actief). Als die er niet zijn, maar wel producten, dan krijg je die te zien (dat is meestal bij andere forums gebruikelijk). En als allebei niet beschikbaar zijn krijg je op die plek google adsense te zien.

[Misha]

Voor de goede orde: het is natuurlijk absurd om én google ads én gerelateerde producten én gerelateerde vacatures boven een topic te tonen. Je krijgt er altijd maar maximaal 1 van die drie te zien

[jip_86]

Uiteraard, ik had ookn iet anders verwacht. Maar ik was gewoon even benieuwd wanneer wie nu precies tevoorschijn zouden komen.

[Boss]

Komt er nog een optie om de social-knoppen helemaal uit te schakelen? Nu staat onder ieder artikel een regel met 'Social sharing inschakelen'. Zo blijf ik er iedere keer aan herinnerd worden dat ik bewust achterblijf bij de vooruitgang en geen gebruik maak van 'social sharing'. Dat is best pijnlijk :-) Net als andere opties die je kan in/uitschakelen kan het toch ook gewoon bij de settings komen?

[crisp]

Je bedoelt een optie om de regel 'Social sharing inschakelen' ook te verbergen dus? Dat is dus feitelijk een tweede soort voorkeur waar we niet direct in voorzien, maar waar je met behulp van custom css makkelijk zelf een oplossing voor kan verzorgen:

#socialButtons { display: none; }

[ACM]

Je kan het ook anders zien; jij hebt er bewust voor gekozen om niet allerlei amerikaanse organisaties jouw bezoekgedrag in kaart te laten brengen en je hoeft ook niet te weten hoeveel 'idioten' ook nog eens op zo'n suffe knop drukten (nota bene om artikelen die iedereen toch al via zijn rss-reader of de tweakers.net FP bekijkt te delen!)...

[djc]

Grappig dat jullie alweer van Mongo zijn afgestapt. Vraag me af of jullie ook naar Redis gekeken hebben voor de sessie-opslag? Lijkt alsof dat ook een goede fit zou zijn. (Maar IIRC gebruiken jullie al memcached voor andere caches, dus dan is dat wellicht aantrekkelijker.)

[ACM]

We zijn helemaal niet afgestapt van MongoDB We hebben alleen van de 4M sessies in totaal, er 1.4M afgehaald omdat ze nutteloos zijn om in permanente opslag te hebben.

En die 1.4M gaan nu dus eerst in memcached en bij hergebruik alsnog in MongoDB.

We willen sessies overigens in permanente opslag, bij voorkeur ook redelijk robuust. We kunnen tenslotte niet garanderen dat onze servers een jaar uptime halen en als we kunnen voorkomen dat mensen uitgelogd zijn enkel omdat wij een server moesten herstarten is dat wel fijn Redis heeft natuurlijk ook wel semi-permanente opslag, maar het document-model van mongodb sluit nog altijd beter aan op wat wij er mee doen dan de rest.

[AW_Bos]

Waarom krijgen search-bots/spiders eigenlijk een SessieID mee? Dat lijkt me toch ergens voor nodig. Ik meen dat deze op het forum al uitstonden?

[ACM]

De gene die we kennen krijgen geen sessie. Maar we gaan niet zomaar aan de hand van de useragent of het ip gokken of iets een bot is of niet, dus uiteindelijk krijgt alles waarvan we niet vooraf zeker zijn dat het een bot is wel een sessie.

Dus tenzij er een sluitende methode is om bots te herkennen, zullen wij voorzichtigheidshalve (tijdelijke) sessies aan ons onbekende bots uit blijven delen

[Reactie gewijzigd door ACM op 24 juli 2024 05:58]

[Cloud]

@djc (had reply moeten zijn...):

Eh, ze zijn niet van Mongo afgestapt hé. Sessies die nieuw aangemaakt worden worden in memcached geplaatst. Worden ze daarna nog een keer gebruikt, dan worden ze alsnog in MongoDB opgeslagen.

[Reactie gewijzigd door Cloud op 24 juli 2024 05:58]

[Chris7]

Mooie dingen, en alweer de derde roundup in korte tijd, Scrum werpt z'n vruchten af .
Trouwens wel handig die opslag via Memcatched, kan me voorstellen dat MongoDB het niet altijd even snel afhandeld. Slim opgelost dus! Ga zo door! *wachtend op #iteratie 4*

[Flowmo]

Hahaha, grappig! Staat gewoon een forumpost van mij bij jobs

[Wim Leers]

Ik weet niet wat de juiste plaats is om dit aan te vragen, maar what about feeds met daarin alle activiteiten van een gebruiker? Zoals bvb. GitHub dit ook aanbiedt.