woensdag 27 oktober 2010
Wordt lid van NLCMG
Het lidmaatschap van de Nederlandse Computer Measurement Group (NLCMG) geeft toegang tot alle bijeenkomsten.
Om lid te worden van de NLCMG stuurt u een mailtje naar secretariaat@nlcmg.nl.
In dat mailtje vermeldt u uw naam, (factuur)adres, e-mail, telefoonnummer organisatienaam, en de tekst "ik wil lid worden van de NLCMG, en schrijf mij in als leverancierslid/overig lid."
Leveranciers zijn organisaties die vooral hardware en/of software verkopen, dan wel oplossingen met een grote hardware of software component. Overigen zijn bijvoorbeeld werknemers van kennisinstellingen, internetproviders, adviseurs, en IT afdelingen van niet-leveranciers.
De kosten van het lidmaatschap bedragen 100 Euro per jaar voor leveranciers, en 50 Euro per jaar voor overigen (inclusief BTW). Het lidmaatschap gaat per kalenderjaar. Wie nu inschrijft en betaalt telt als lid voor 2011 en krijgt het lidmaatschap voor 2010 gratis.
U kunt zich ook aanmelden voor de volgende bijeenkomst op 10 november.
Zie event op LinkedIn
p.s. deze blog verhuist naar www.nlcmg.nl
maandag 25 oktober 2010
10 november
(overigens, deze blog verhuist naar http://www.nlcmg.nl/volgende-bijeenkomst, ga naar de RSS feed).
Our industry does not support the concept of transaction. Or does it?
Teneinde het risico van slechte performance te reduceren worden vele performance analyses van transactie verwerkende systemen uitgevoerd. Het gaat daarbij om de user experience en de transactie is daarbij centraal uitgangspunt. Het is opvallend hoe weinig verband de technologie houdt met de transactie. Wil je er meetgegevens over verzamelen dan kom je bij gekunstelde technieken als tagging en bizarre meetprocedures uit. Daarnaast kom je zelden een transactieverwerkende applicatie tegen waarbij de uitgevoerde transacties worden geteld. Ze hebben zelfs geen identificatie. Toch hebben we dit soort informatie hard nodig als we de performance van een systeem willen verklaren en voorspellen. Een saillant voorbeeld zijn de moderne webapplicaties. Daarbij kan het uitgevoerde werk geregistreerd worden in een http-log. Geen transactie in te vinden, wel een berg http requests, maar wat hebben we daar aan?
Er zijn vele aspecten die bovenstaande vraag oproepen. Een daarvan betreft het bepalen van het transactievolume.
In de presentatie wordt een voorbeeld behandeld waarin een http log succesvol kon worden geanalyseerd en de geheimen van de transacties prijs gaf. Voorts wordt getoond wat dat oplevert en onder welke condities soortgelijke analyses mogelijk zijn. Daarnaast wordt behandeld waaraan een transactielog minimaal moet voldoen.
dinsdag 14 september 2010
Volgende NLCMG bijeenkomst 10 november
Locatie, sprekers, e.d. staat nog niet vast, dus neem deel aan de discussie via de NLCMG groep op LinkedIn.
maandag 30 augustus 2010
NLCMG opgericht!
Dank aan alle aanwezigen, en voor hen die er niet bij konden zijn: hopelijk tot de volgende keer.
dinsdag 24 augustus 2010
Lokatie EMC Nieuwegein. Edisonbaan 14b, 3439 MN Nieuwegein
(let op: niet naar het Eerste Lijns Medisch Centrum gaan)
Programma
16:00 Inloop en koffie
16:15 Welkom bij NLCMG door Peter van Eijk (Digital Infrastructures)
16:30 Welkom door Remco Donkers (EMC). Presentatie door EMC
16:45 “Waarom laat Twitter publiekelijk zien wanneer hun API niet werkt?” door Stan van de Burgt (WatchMouse)
Twitter heeft een publieke statuspagina laten maken, die laat zien wanneer de twitter APIs werken of niet (http://dev.twitter.com/status). Waarom deed Twitter dat, en wat zijn inmiddels de ervaringen?
17:00 “Mijn mailserver werkt niet hard genoeg” Leo Collard (Tools2Perform)
Als de mailserver te veel belasting heeft is dat niet goed en moet je ingrijpen. Op maandagochtend is dat echter een bekend probleem. Maar wat nu als je mailserver op maandagochtend niets staat te doen? Ook dat zou tot alarm moeten leiden. Self-learning monitoring leert van het historische gedrag van systemen zodat afwijkingen daarvan aanleiding geven tot alerts. In de praktijk kan dit tot 90% van de alerts reduceren. In de voordracht enkele praktijkcases.
17:15 “Wat kost het als de website down is?” door Peter van Eijk
Hoe bepaal je de kosten van website downtime, en daarmee de waarde van de website? Bij een energieleverancier is op basis van een analyse van klantprocessen de businessschade in kaart gebracht. Daarmee kunnen gerichte verbeteracties worden gestuurd. Niet de hele website is namelijk even belangrijk.
17:30 Pauze en netwerken, met koffie en fris
18:00 “Datakwaliteit en zwarte zwanen” door Frank van der Eijden (Zelfstandig Professional)
Hoe helpt de theorie van Nassim Taleb (bekend van de “Black Swan”) om kwaliteitsproblemen van gegevens tot een aanvaardbaar niveau terug te dringen? Frank van der Eijden presenteert een case uit de publieke sector waarbij massale verwerking van digitaal aangeleverde gegevens kwalitatief verbeterd werd.
18:15 “mBrace voor performance engineering” door Hans Geul (Contentional)
mBrace is een methode voor het verklaren en voorspellen van de applicatie performance. De presentatie gaat in op de modellering en toepassing in een concrete case.
18:30 Afronding en bespreking van het vervolg, o.l.v. Peter van Eijk
18:45 Netwerken met pizza en fris
vrijdag 30 juli 2010
NLCMG meetup
dinsdag 18 mei 2010
Een event voor de NL CMG community.
Reden om aan een event te gaan werken.
We hebben al vertegenwoordigers van een paar belangrijke bedrijven in dit speelveld, en verschillende daarvan hebben hun medewerking aan een event toegezegd.
Van deze groep hoor ik graag ideeën over hoe we zo’n event verder kunnen vormgeven. Naar mijn idee kunnen we een aantal presentaties gebruiken, bijvoorbeeld een paar mooie case studies. Er zal verder ruimte moeten zijn voor informele contacten. Tenslotte willen we natuurlijk ook aandacht voor de verdere formalisering van de community, maar dat komt later wel.
Laat uw fantasie los, kom met ideeën, suggesties en onderwerpen om er een mooie bijeenkomst van te maken. Vergeet niet om dit ook door te sturen naar andere relevante kennissen en organisaties.
P.s. Wat zou een mooie dag zijn?
dinsdag 13 april 2010
Verschillen tussen business en IT
Voor het beheren van technologie is samenwerking nodig tussen business en IT maar deze gaat vaak stroef. Hoe komt dit eigenlijk en hoe kunnen we hier mee omgaan? Hieronder een situatie waarin de communicatieproblemen duidelijk naar voren komen.
“Een bekende uitspraak van IT`ers is: ‘Als de kastjes maar zoemen en de lampjes groen zijn’. Wanneer de kastjes zoemen en de lampjes groen zijn, gaat IT er vanuit dat de dienst werkt en dat de kwaliteit van de techniek optimaal is. Dit terwijl alleen bevestigd is dat de afzonderlijke elementen werken. Wanneer er vervolgens veel telefoontjes bij de business binnenkomen dat de dienst niet goed werkt, is er een probleem. De lampjes zijn immers groen bij IT dus deze zal de problemen ontkennen.”
In dit artikel worden een tweetal verschillen tussen business en IT uitgelicht waardoor samenwerking wordt bemoeilijkt.
Focus
Een IT-afdeling is gefocust op kostenbeheersing en een Business afdeling is gefocust op genereren van de inkomsten. Dit leidt er toe dat business en IT praten in verschillende termen en werken met verschillende doelen wat communicatie bemoeilijkt.
Cultuur
De medewerkers van een IT afdeling worden vaak getypeerd als ‘nerd’ en hebben zeer specifieke diepgaande kennis over techniek. Dit leidt bij de IT`ers tot het denken in systemen, netwerken, programmeertalen en protocollen. De medewerkers van de businessafdeling zijn veelal vlotte, verbaal vaardige personen met kennis van marketing, bedrijfsmodellen en –processen en inzicht in de wensen van de klant. Business en IT mensen zijn vaak verschillende mensen met verschillende kennis en interesses.
Dit zijn natuurlijk niet alle verschillen tussen business en IT. Wanneer je meer voorbeelden of verschillen weet te benoemen graag reacties in de comments!
woensdag 31 maart 2010
Tips voor capaciteitsplanning van Flickr
In totaal staan er meer dan vier miljard foto’s op Flickr en daar komen elke minuut zo’n 5000 foto’s bij. Om deze groei in goede banen te leiden is er een goede capaciteitsplanning nodig. Hiervoor verantwoordelijk is John Allspaw, Operations engineer van Flickr.
Op basis van zijn ervaringen bij Flickr heeft John een boek geschreven. In dit boek staan een groot aantal tips en trucks uit de praktijk van capaciteitsplanning. In deze post worden een aantal van deze tips uitgelicht.
Veiligheidsfactor
Elke infrastructuur heeft een limiet aan pagina’s die het kan serveren. Zoek met behulp van goede tools, metrieken en complete, gedetailleerde data deze limieten. Bereken deze limieten op basis van data uit de productieomgeving om het plafond accuraat te kunnen berekenen. Bedenk daarnaast tevens een veiligheidsfactor. Het plafond min de veiligheidsfactor is de eigenlijke grens die je zou moeten hanteren. John stelt dat 15% een goede veiligheidsfactor is. Deze factor kan vervolgens incidentele pieken in de vraag opvangen.
Voorspellen
Maak gedetailleerde voorspellingen van de capaciteit van de infrastructuur door verschillende gebruiksdata te combineren en gebruik te maken van statistische modellen. Het product hiervan moet de tijd zijn dat de huidige infrastructuur nog vooruit kan.
Dashboard
Maak een mooi dashboard waarop resterende capaciteit en het resterend aantal dagen voordat er actie nodig is. Dit helpt jezelf, collega`s en management om inzicht te krijgen in de capaciteit zonder direct in de data te hoeven duiken.
Lopende bottleneck
Er is altijd een bottleneck. Het oplossen van een bottleneck leidt alleen tot een verplaatsing ervan. Focus dus niet alleen op de bottlenecks maar bekijk de infrastructuur als geheel.
Zet onderdelen uit
Wees voorbereid om onderdelen uit te schakelen wanneer het capaciteitslimiet wordt bereikt. Bij Flickr zijn er 140 items die uitgeschakeld kunnen worden om de belasting van de servers te verlagen. Dit geeft je handgrepen tijdens panieksituaties.
Je ontkomt niet aan verstoringen
Aan verstoringen ontkom je niet dus zorg dat je hierop voorbereid bent. Als verstoringen optreden zorg dan dat je de bezoekers een mooie pagina kan laten zien met een nette boodschap. Vertel je bezoekers tevens wat er aan de hand is, dat wordt over het algemeen gewaardeerd.
vrijdag 26 maart 2010
LinkedIn groep
In de LinkedIn groep worden ook links naar interessante andere sites en nieuwsitems geplaatst. Deze blog blijft wel actief, omdat dat voor een groter publiek (en nieuwkomers) interessant is.
Meldt je dus aan bij de LinkedIn groep!
donderdag 11 februari 2010
IT business alignment
De kwaliteit van die componenten is natuurlijk best uit te drukken in getallen. Denk daarbij aan de benuttinggraad van een server of netwerkverbinding. Het zal duidelijk zijn dat een te hoge benutting kan leiden tot vertraging in de dienstverlening. Maar hoe hoog is te hoog voor de business?
De kwaliteit van de business is bijvoorbeeld te meten door naar klanttevredenheid te kijken. Maar wanneer wordt de klant of gebruiker ontevreden als de applicaties steeds langzamer gaan lopen of regelmatig uitvallen? Klanttevredenheid laat zich moeilijk vertalen naar technische prestatie-eisen.
Daarom kijken we steeds vaker naar applicatie prestaties, in plaats van technische prestatie. De responstijd van de dienstverlening in interactie met de gebruiker is een maat (of metric) die zowel door de business als door de techniek begrepen kan worden. Dat is dus een goede kandidaat om de business IT alignment mee vorm te geven.
Zie voor meer achtergrond over application performance management en manieren om het in te richten mijn artikel De inrichting van service level agreements in ketens, verschenen in ITSMF Jaarboek IT beheer, 2002.
donderdag 4 februari 2010
Logo voor NLCMG
vrijdag 22 januari 2010
Performance problemen in de praktijk
Een jaar of wat geleden werd ik betrokken bij een personeelsinformatiesysteem dat tijdens de uitrol steeds trager werd, maar niet voor alle soorten gebruik. De applicatie kende een PC deel, dat over het netwerk met servers communiceerde. Bij het intakegesprek bleek men al verschillende hypotheses voor het probleem te hebben, maar geen daarvan verklaarde alle verschijnselen.
Onze aanpak was toen om systematisch alle bronnen van performance problemen op te sommen: de desktop, het netwerk en de servers. Voor elk van deze hypotheses richtten we een meting in. Dat klinkt trouwens makkelijker dan het is.
Conclusie uiteindelijk: er waren inderdaad twee problemen. Door onhandig programmeren werd steeds een hele tabel over het netwerk naar de PC gestuurd. Dat werd trager naarmate de uitrol vorderde, omdat die tabel steeds groter werd. Verder was de software aan de PC kant gewoon erg veeleisend. Uiteindelijk moest de applicatie flink worden herschreven.
woensdag 20 januari 2010
Meten van Web 2.0 toepassingen
WatchMouse heeft vandaag een nieuwe dienst gelanceerd die laat zien hoe verschillende van deze API's het doen. De dienst heet api-status.com, en de Twitterstoring van vandaag is te zien op deze pagina.
donderdag 7 januari 2010
Performance en capaciteit als business probleem
We zijn op zoek naar goede en meer gedetailleerde voorbeelden van dat soort problemen. Die zijn immers de reden voor het werk dat we doen. Als we dat dan weten kunnen we beter uitleggen hoeveel moeite we ervoor moeten doen. Een aardige inleiding in het opzetten van business cases voor goed software performance management is te vinden in deze paper.
Graag hoor ik waar u mee bezig bent op het gebied van computer prestaties. Gebruik de commentaar mogelijkheid!