[PL] GET.NET w Łodzi 2017

TL;DR

Polski Piątek: o polskim community, o tym co u nas w trawie i w technologii piszczy, a także o innych rzeczach wszelakich.

GET.NET

22 kwietnia 2017 odbyła się kolejna odsłona konferencji GET.NET w Łodzi. Miałem przyjemność przedstawić tam moją ostatnią prezentację The Only Thing That Matters, w nowej, nieco zmodyfikowanej formie. Jak zwykle w przypadku GET.NET, obsługa prelegenta stanęła na wysokim poziomie.

Sama prezentacja to prawie 50 minut treści. Udało mi się zebrać feedback od 10 osób. W większości bardzo pozytywny. Czekam na wyniki ankiet!

Jak zwykle uczestniczyłem jako słuchacz tylko w kilku prezentacjach. Najciekawszą, która zaintrygowała mnie możliwościami nowego podejścia, była prezentacja Krzysztofa Cieślaka pokazująca niezwykle ciekawy projekt o nazwie Fable, kompilujący F# do JavaScriptu używając do tego Babela. Z webem niestety nie miałem dawno do czynienia, ale posiadanie możliwości pisania swojego kodu w F#, np. funkcji dispatchujących w Redux wyglądało niesamowicie.

SII, dzięki za zaproszenie i możliwość prelekcji. Do rychłego zobaczenia!

ProtobufRaw vs protobuf-net

TL;DR

I’m working currently on SewingMachine, an OSS project of mine, that is aimed at unleashing the ultimate performance for your stateful services written in/for Service Fabric (more posts: here). In this post I’m testing further (previous test is here) whether it would be beneficial to write a custom unmanaged writer for protobuf-net using stackallocked memory.

SewingMachine is raw, very raw

SewingMachine works with pointers. When storing data, you pass an IntPtr with a length as a value. Effectively, it means that if you use a managed structure to serialize your data, finally you’ll need to either pin it (pinning is notification for GC to do not move object around when it’s pinned) or have it pinned from the very beginning (this approach could be beneficial if an object is large and has a long lifetime). If you don’t want to use managed memory, you could always use stackalloc to allocate a small amount of memory on stack, serialize to it, and then pass it as IntPtr. This is approach I’m testing now.

Small, fixed sized payloads

If a payload, whether it’s an event or a message is small and contains no fields of variable length (strings, arrays) you could estimate the maximum size it will take to get serialized. Next, instead of using Protobuf-net regular serializer, you could write (or emit during a post-compilation) a custom function to serialize a given type, like I did in this spike. Then it’s time to test it.

Performance tests and over 10x improvement

Again, as in the previous post about memory, the unsafe stackallock version shows that it could be beneficial to invest some more time as the performance benefit is just amazing . The raw version is 10x faster. Wow!

protoraw_vs_proto

Summary

Sometimes using raw unsafe code improves performance. It’s worth to try it, especially in situations where the interface you communicate with is already unsafe and requiring to use unsafe structures.

Top Domain Model

It looks like a new series is going to be published on this blog!

I received some feedback related to the recent series making your event sourcing functional. Posts in this series will be loosely coupled and more-less self-contained. The topic that will connect them is modelling your domain, aggregates, processes towards models that are useful, not necessarily correct. We’ll go through different domains & different requirements and we’ll try to focus not on the created model (it’s just an exercise) but rather on the modelling approaches and practices.

Put on your modeller’s gloves and safety glasses. It’s about time to crunch a few domains!

 

[PL] Eksperymenty małe i duże

TL;DR

Polski Piątek: o polskim community, o tym co u nas w trawie i w technologii piszczy, a także o innych rzeczach wszelakich, jak na przykład o eksperymentowaniu.

Jak?

W ciągu ostatniego pół roku udało mi się przeprowadzić kilka eksperymentów. Każdy z nich był ograniczony:

  1. w czasie (próbuję coś przez miesiąc, pół)
  2. w kosztach (nie wydam 100000 na samochód aby zobaczyć jak się jeździ, ani nie powiem w domu, że teraz coś testuję i nie ma mnie przez miesiąc)
  3. efektach ubocznych (eksperymentem dla mnie nie jest jedzenie 10 czekolad dziennie – to głupota).

Jednym z moich eksperymentów było niejedzenie słodyczy przez miesiąc. Eksperyment zakończył się dobrym wynikiem. Słodyczy nie jadłem przez miesiąc, i już nie będę jadł. Jeżeli na konferencji, na której nie ma kanapek/sałatek a tylko ciastka, zjem jedno, dwa. Natomiast nie mam już ciągów słodyczowych. Koszt eksperymentu jest ujemny: nie kupuję słodyczy. Efekt uboczny: prawdopodobna redukcja tkanki tłuszczowej. Ojej ojej, co ja z tym zrobię 😛

Kolejnym, wstawanie o 5:45 a nie o 6:00 po to, aby zawsze móc poćwiczyć przed pobudką najmniejszego z domowników i nie mieć problemów z “niewyrabianiem się”. Eksperyment zakończony sukcesem w pierwszym tygodniu. Koszt: męczenie się podczas ćwiczeń, na które zawsze jest czas. Skutki uboczne: trochę lepsza kondycja i siła.

Kolejnym, są Polskie Piątki. Sprawdzam siebie, czy potrafię pisać o rzeczach mniej technicznych i Was, czy chcecie czytać o takich tematach.

Po co?

Nie wiem jak zareaguje moje ciało, umysł, otoczenie dopóki czegoś nie zmienię. Więc zmieniam, w ograniczonym zakresie (czas/koszt/efekty uboczne) i patrzę co z tego wychodzi. I tyle. Nie wszystko wyjdzie, nie wszystkiego się podejmę, ale sprawdzanie i korelacja efektów po, daje ciekawe wyniki.
Nie jestem tak dobrym eksperymentatorem jak Tim Ferris, który żyje ze swoich 4 godzin.  Jednocześnie mogę powiedzieć, że eksperyment z robieniem eksperymentów ma jak na razie pozytywne konsekwencje. I ten właśnie, postaram się przekuć w nawyk. A Ty, jak testujesz siebie?

ThreadStatic vs stackalloc

TL;DR

I’m working currently on SewingMachine, an OSS project of mine, that is aimed at unleashing the ultimate performance for your stateful services written in/for Service Fabric (more posts: here). In this post I’m testing whether it would be beneficial to write a custom unmanaged writer for protobuf-net, instead of using some kind of object pooling with ThreadLocal.

ThreadStatic and stackalloc

ThreadStatic is the old black. It was good to use before async-await has been introduced. Now, when you don’t know on which thread your continuation will be run, it’s not that useful. Still, if you’re on a good old-fashioned synchronous path, it might be used for object pooling and keeping one object per thread. That’s how protobuf-net caches ProtoReader objects.

One could use it to cache locally a chunk of memory for serialization. This could be a managed or unmanaged chunk, but eventually, it would be used to pass data to some storage (in my case, SewingSession from SewingMachine). If the interface accepted unmanaged chunks, I could also use stackalloc for small objects, that I know how much memory will be occupied by. stackalloc provides a way to allocate some number of bytes from the stackframe. Yes, it’s unsafe so keep your belts fastened.

ThreadStatic vs stackalloc

I gave it a try and wrote a simple (if it’s dummy, I encourage you to share your thoughts in comments) test that either uses a ThreadStatic-pooled object with an array or a stackallocated and writes. You can find it in this gist.

How to test it? As always, to the rescue comes BenchmarkDotNet, the best benchmarking tool for any .NET dev. Let’s take a look at the summary now.

local_vs_threadstatic.png

Stackalloc wins.

There are several things that should be taken into consideration. Finally block, the real overhead of writing an object and so on and so forth. Still, it looks that for heavily optimized code and small objects, one could this to write them a bit faster.

Summary

Using stackallocated buffers is fun and can bring some performance benefits. If I find anything unusual or worth noticing with this approach, I’ll share my findings. As always, when working on performance, measure first, measure in the middle and at the end.

How does Service Fabric host your services?

TL;DR

Service Fabric provides an amazing fully automated hosting for any number of services with any number of instances each (up to the physical limits of your cluster). But how are these hosted? What if you have more partitions than nodes?

Structure recap

When building an app that is meant to be hosted in Service Fabric you build an… app. This application might consist of multiple stateful and stateless services. The application is packaged to a… package that, when uploaded to the cluster as an image, provides an application type. From this, you can instantiate multiple application instances. Let me give you an example.

Application “Bank” consists of two services:

  1. “Users”
  2. “Accounts”

When build with version “1.0.0” and packaged, it can be uploaded to the SF cluster and is registered as “Bank 1.0.0”. From now on you can instantiate as many banks as you want within your cluster. Each will be composed of two sets of services: “Users” and “Accounts”.

Services, stateful services

When defining stateful services, these that have a built in kind-of database (reliable collections, or SewingSession provided by my project SewingMachine) you need to define how many partitions they will have. You can think of partitions as separate databases. Additionally, you define the number of replicas every partition will have. That’s done to ensure high availability. Let me give you an example.

  1. “Users” have the number of partitions set to 100 and every partition is replicated to 5 replicas (let’s say P=100, R=5)
  2. “Accounts” are configured with P=1000, R=7

Imagine that it’s hosted on a cluster that has only 100 nodes. This will mean, that on every node (on average) system will place 5 replicas of “Users” and 70 replicas of “Accounts”. It’s a valid scenario. Once some nodes are added to the cluster, replicas will be automatically moved to new nodes lowering the saturation of previously existing.

What if a node hosts more than one replica of one service, how are they hosted? Moreover, how do the communicate, as there’s only one port assigned to do it?

Cohosting to the rescue

Currently, all the replicas are hosted within the same process. Yes, although 5 “Users” instances will be created, they will all be sitting in the same AppDomain of the same process. The same goes for 70 “Accounts”. You can check it on your own by obtaining the current process ID (PID) and AppDomain.Current and compare. This reduces the overhead of hosting as all assemblies and static resources (assemblies loaded, static fields, types) are shared across replicas.

One port to rule them all

By default, when using native Service Fabric communication listener, only one port is used by an endpoint. How is possible that the infrastructure knows how to route messages to the right partition and replica? Under the hood, when opening a communication listener, replica registers the identifier of the partition it belongs to and its replica number. That’s how, when a message arrives, Service Fabric infrastructure is capable of sending the message to the right communication listener, and therefore, to the right service instance.

Summary

Now you know, that all replicas of partitions of the same service on one node are cohosted in the same process and that Service Fabric infrastructure dispatches messages accordingly to the registered partition/replica pair.

[PL] zdobywanie wiedzy i kompetencji dziś

TL;DR

Polski Piątek: o polskim community, o tym co u nas w trawie i w technologii piszczy, a także o innych rzeczach wszelakich.

Za 15 lat

Jeżeli ktoś, podczas moich studiów, powiedziałby mi, że za 15 lat będę mógł uczęszczać w Warszawie codziennie na inny meetup związany z technologią, powiedziałbym, że to czyste żarty (wyraziłbym się bardziej dosadnie). I nawet, jeżeli cały czas jestem oszołomiony ich liczbą, to jest to przyjemne oszołomienie.

Poza dużą liczbą wydarzeń, charakteryzują się one też dużą różnorodnością. Mamy:

Jest tego naprawdę, zarówno pod względem liczby, jak i formy bardzo dużo. I dobrze!

Elitarność

Zdobywanie wiedzy traci na elitarności. I nie chodzi o to, że sama wiedza jest “gorsza”. Po prostu dostęp do niej jest coraz bardziej powszechny i coraz więcej zależy od jednostki, od Ciebie. Masz chęć i siłę poświęcić 2 godziny dziennie aby pouczyć się Go? Idziesz na meetup, rozmawiasz z ludźmi, oglądasz prezentacje, idziesz na szkolenie, kodujesz i zdobywasz wiedzę. I już.

Chęć

Pozostaje tylko jedno. Twoje chęci, zapał, wytrwałość, siła i kilka innych zasobów, którymi musisz się wykazać. To jak, wykażesz się? 🙂