oscarnylander - 2018-04-23 09:29 22s

@jens.hunt I for one welcome my new Microsoft overlords 🐧

erik.malm - 2018-04-23 20:11 21s

Riktigt intressant för min del @daniel.winther, finns typ en bransch-standard inom PSD2 (https://www.berlin-group.org/psd2-access-to-bank-accounts). Får gräva igenom hur nära dessa Tink ligger.

erik.malm - 2018-04-27 06:58 04s

Behöver göra mig av med ett gäng gamla hårddiskar. Vill gärna utplåna informationen på dem innan det är dags för tippen, om någon har en favorit-utility för sådant så mottages tips gärna.

oscarnylander - 2018-04-27 09:22 00s

DBAN är väl en klassiker

oscarnylander - 2018-04-27 09:51 33s

https://www.palletsprojects.com/blog/flask-1-0-released/

Flask har kommit ut med en 1.0-release! Intressant.

Flask 1.0 Released

daniel.winther - 2018-04-27 09:54 53s

woop woop! på tiden 😄 har ju funnits hur länge som helst

oscarnylander - 2018-04-27 09:56 01s

eller hur, märkvärdigt att de inte gått till 1.0 ännu

erik.malm - 2018-04-27 11:50 44s

Haha, Flask fanns till och med när jag skrev ordentligt med Python senast. Tur att jag väntade i ca 10 år så att jag inte lärt mig omogen teknik! ;) Även om jag mer tror att det här är ett fall av att hantera versioner som Linus. https://betanews.com/2018/04/16/linux-kernel-5-0/

Linus Torvalds says Linux kernel v5.0 'should be meaningless'

Following the release of Linux kernel 4.16, Linus Torvalds has said that the next kernel will be version 5.0. Or maybe it won't, because version numbers are meaningless.

oscarnylander - 2018-04-27 11:55 44s

Troligen är det så 🙂

erik.malm - 2018-04-27 11:56 07s

DBAN verkar vara precis rätt verktyg @daniel.winther

oscarnylander - 2018-04-27 11:56 27s

*@oscarnylander 😞

teo.roijezon - 2018-04-27 11:58 09s

@erik.malm @oscarnylander använd inte DBAN för SSD:er

erik.malm - 2018-04-27 11:58 19s

Förr i världen har jag låtit bash skriva från /dev/random över hela disken ett par vändor men har inte energi för det den här gången.

teo.roijezon - 2018-04-27 11:58 46s

dom har mycket intern skrivbalansering osv vilket innebär att rester kommer finnas kvar använd https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase istället

erik.malm - 2018-04-27 11:59 54s

Mmm.. Den nivå på teknik jag gör mig av med är 5200rpms diskar så inte ett problem den här vändan. Men lär vara relevant nästa gång jag kör en utrensning.

teo.roijezon - 2018-04-27 12:00 04s

ahh okej ja då borde det räcka eller bara dd if=/dev/urandom of=/dev/sdXN bs=1M ett par ggr

oscarnylander - 2018-04-27 12:01 20s

dd: disk destroyer :parrot:

erik.malm - 2018-04-27 12:01 26s

Det är min vanliga. Men det är fem diskar som kommer behöva behandlas och då slår latmasken till

teo.roijezon - 2018-04-27 12:01 32s

ahh, iC

oscarnylander - 2018-04-27 12:01 43s

koppla in alla och kör parallellt!

erik.malm - 2018-04-27 12:02 50s

Om de bara vore thunderbolt så kunde jag daisy-chaina allt! Som en hårddisk konga-line!

teo.roijezon - 2018-04-27 12:05 24s

https://www.youtube.com/watch?v=deJ9lpNBZUA

That Mitchell and Webb Look - Posh Dancing

erik.malm - 2018-04-27 12:09 35s

Jag är nöjd med hur den här diskussionen slutade. P.S. are we the baddies?

teo.roijezon - 2018-04-27 12:10 58s

tror inte vi har dödskallehattar än? Johan får ta tag i det 😛

joakoles - 2018-04-28 17:47 28s

För ett tag sedan sa jag att jag skulle informera om resultatet av prestandatest-applikationen jag skrev som skulle mäta prestandan i azure event hub (vilket kan ses som ett kafka-alternativ). Applikationen jag skrev består av två delar: En del som skriver en massa events (med samma storlek som vi skickar i produktion) till event hub och en del som läser dessa events från event hub. Skriv-delen är ett azure webjob och läs-delen är en azure function. Båda dessa delar kan skalas upp och ut som man vill. Även själva event hub’en kan skalas genom att höja antalet throughput units (TPU) och antalet partitioner (i praktiken måste man radera och skapa en ny event hub då man inte kan ändra antalet partitioner i efterhand).

Både skriv- och läs-delen hanterar intervall. Man kan då ange att varje instans ska skicka tex. 100 meddelanden per sekund under tex. 1 minut och därefter höja till 500 och därefter till 1000 meddelanden per sekund.

Läs-delen beräknar lite enkla mätdata för att ta reda på prestandan. Mätdatan lagras inte i databasen för varje event då det skulle påverka resultatet mycket. Istället lagras bara mätdatan en gång per intervall, dvs. tex. en gång per minut.

Resultatet visade att throughput blir högt om man skalar upp/ut men att latensen för en del av eventen är förvånansvärt högt trots att man skalat upp/ut (åtminstone blev jag förvånad). De flesta events går igenom event hub’en snabbt men en liten andel tar över en sekund och ibland över 5 sekunder.

Microsoft har själva gjort ett liknande test fast för ett längre flöde och fler events per sekund. Även där ser man att en andel av eventen passerar genom flödet mycket långsammare än genomsnittet. Hälften av eventen passerar flödet på mindre än 1,1 sek medan en del tar mycket längre tid: https://blogs.msdn.microsoft.com/appserviceteam/2017/09/19/processing-100000-events-per-second-on-azure-functions/

Jag vill dock inte påstå att mina mätresultat är 100% tillförlitliga. Det kan vara så att något i applikationen jag skrev är suboptimalt. Dessutom kan klockan skilja sig mellan olika maskiner i azure vilket skulle ge stor effekt på mätresultaten. Jag hörde någon berätta att det är vanligt att klockan i azure-maskiner är “korrekt tid +/- 2 sekunder” vilket innebär ett intervall på 4 sekunder. Ett förslag på workaround är att förlita sig på databas-serverns klocka för att kompensera för detta. Vid uppstart skulle applikationen (både skriv- och läs-sidan) kunna hämta tiden från db-servern för att ta reda på hur den lokala klockan skiljer sig från “sanningen” om vi definerar db-serverns klocka som “sanningen” i prestandatestet. Applikationen får då ta hänsyn till differensen däremellan. Därmed kompenserar man för skillnad i klocka på olika maskiner. Då jag bytt team har jag inte implementerat denna workaround men jag har tipsat teamet om detta.