Pregled Skaffold za razvoj pod Kubernetes

Pregled Skaffold za razvoj pod Kubernetes

Pozdravljeni! Ta članek je zbirka najboljših praks, ki jih jaz in moji kolegi uporabljamo že dolgo časa pri delu na različnih projektih.

Informacije o napravi, na kateri so bile izvedene izračune:BenchmarkDotNet=v0.11.5, OS=Windows 10.0.18362
Intel Core i5-8250U CPU 1.60GHz (Kaby Lake R), 1 CPU, 8 logičnih in 4 fizične jedra
.NET Core SDK=3.0.100
[Host]: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64bit RyuJIT
Core: .NET Core 2.2.7 (CoreCLR 4.6.28008.02, CoreFX 4.6.28008.03), 64bit RyuJIT
[Host]: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64bit RyuJIT
Core: .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), 64bit RyuJIT

Job=Core Runtime=Core

ToList vs ToArray in Cikli

Te informacije sem nameraval pripraviti ob izidu .NET Core 3.0, vendar so me prehiteli, nočem krasti slave drugih in kopirati njihove informacije, zato bom le navedel povezavo do dobrega članka, kjer je podrobno opisano primerjavo..

Od sebe želim predstaviti svoje meritve in rezultate, v njih sem dodal obratne cikle za ljubitelje "C++ stila" pisanja ciklov.

Koda:

public class Bench
    {
        private List _list;
        private int[] _array;

        [Params(100000, 10000000)] public int N;

        [GlobalSetup]
        public void Setup()
        {
            const int MIN = 1;
            const int MAX = 10;
            Random random = new Random();
            _list = Enumerable.Repeat(0, N).Select(i => random.Next(MIN, MAX)).ToList();
            _array = _list.ToArray();
        }

        [Benchmark]
        public int ForList()
        {
            int total = 0;
            for (int i = 0; i  0; i--)
            {
                total += _list[i];
            }

            return total;
        }

        [Benchmark]
        public int ForeachList()
        {
            int total = 0;
            foreach (int i in _list)
            {
                total += i;
            }

            return total;
        }

        [Benchmark]
        public int ForeachArray()
        {
            int total = 0;
            foreach (int i in _array)
            {
                total += i;
            }

            return total;
        }

        [Benchmark]
        public int ForArray()
        {
            int total = 0;
            for (int i = 0; i  0; i--)
            {
                total += _array[i];
            }

            return total;
        }
    }

Hitrost delovanja v .NET Core 2.2 in 3.0 sta skoraj identični. To, kar mi je uspelo doseči v .NET Core 3.0:

Prihajamo do sklepa, da je ciklična obdelava zbirke tipa Array hitrejša zaradi svojih notranjih optimizacij in jasne dodelitve velikosti zbirke. Prav tako je treba spomniti, da ima zbirka tipa List svoje prednosti, zato je priporočljivo uporabiti pravilno zbirko glede na potrebna izračunavanja. Tudi če pišete logiko dela s cikli, ne pozabite, da gre za običajen loop, ki je prav tako lahko predmet optimizacije ciklov. Na Habr je davno že izšla članek: https://habr.com/ru/post/124910/. Še vedno je aktualen in priporočljiv za branje.

Throw

Pred letom dni sem delal v podjetju na legacnem projektu, kjer je bilo v okviru normalno obdelovati validacijo polj prek konstrukcije try-catch-throw. Že takrat sem razumel, da to ni zdrava poslovna logika delovanja projekta, zato sem se po najboljših močeh trudil, da te konstrukcije ne uporabljam. A poglejmo, kaj je narobe z obdelavo napak s to konstrukcijo. Napisal sem majhen kodo za primerjavo dveh pristopov in opravil "benchmarks" za vsako različico.

Koda:

        public bool ContainsHash()
        {
            bool result = false;
            foreach (var file in _files)
            {
                var extension = Path.GetExtension(file);
                if (_hash.Contains(extension))
                    result = true;
            }

            return result;
        }

        public bool ContainsHashTryCatch()
        {
            bool result = false;
            try
            {
                foreach (var file in _files)
                {
                    var extension = Path.GetExtension(file);
                    if (_hash.Contains(extension))
                        result = true;
                }
                
                if(!result) 
                    throw new Exception("false");
            }
            catch (Exception e)
            {
                result = false;
            }

            return result;
        }

Rezultati v .NET Core 3.0 in Core 2.2 imajo podoben rezultat (.NET Core 3.0):

Try catch zapleta razumevanje kode in povečuje čas izvajanja vaše programske opreme. Toda če potrebujete to konstrukcijo, ne smete vključiti tistih vrstic kode, od katerih ne pričakujete obdelave napak — to bo olajšalo razumevanje kode. Dejansko sistem obremeni ne toliko obdelava izjem, temveč mečevanje same napake prek konstrukcije throw new Exception.

Mečevanje izjem deluje počasneje kot kateri koli razred, ki bo zbral napako v ustreznem formatu. Če obdelujete obrazec ali kakšne podatke in jasno veste, kakšna napaka bi morala biti, zakaj je ne bi obdelali?

Ni utrpenju priporočam, da pišete strukturo throw new Exception(), če ta situacija ni izjema. Obdelava in metanje izjeme je zelo draga!!!

ToLower, ToLowerInvariant, ToUpper, ToUpperInvariant

V svojih petih letih dela na platformi .NET sem naletel na številne projekte, ki so uporabljali primerjave nizov. Prav tako sem videl naslednjo sliko: bilo je eno podjetniško rešitev z več projekti, vsak od njih pa je izvajal primerjave nizov drugače. Kaj torej uporabiti in kako to poenotiti? V knjigi CLR via C# Richtera sem prebral informacijo, da metoda ToUpperInvariant() deluje hitreje kot ToLowerInvariant().

Izvleček iz knjige:

Seveda nisem verjel in sem se odločil, da izvedem nekaj testov takrat še na .NET Framework in rezultat me je presenetil — več kot 15% povečanja zmogljivosti. Naslednje jutro, ko sem prišel na delo, sem svojemu nadrejenemu pokazal merljive podatke in njihovo dostopnost do izvorne kode. Po tem sta bila 2 od 14 projektov spremenjena za nove meritve, ob upoštevanju, da sta ti dva projekta obstajala, da obdelujeta ogromne excel tabele, je bil rezultat za izdelek več kot pomemben.

Zdaj vam predstavljam meritve za različne različice .NET Core, da si lahko vsak izmed vas izbere najbolj optimalno rešitev. Rad bi dodal, da v podjetju, kjer delam, uporabljamo ToUpper() za primerjavo nizov.

Koda:

public const string defaultString =  "VXTDuob5YhummuDq1PPXOHE4PbrRjYfBjcHdFs8UcKSAHOCGievbUItWhU3ovCmRALgdZUG1CB0sQ4iMj8Z1ZfkML2owvfkOKxBCoFUAN4VLd4I8ietmlsS5PtdQEn6zEgy1uCVZXiXuubd0xM5ONVZBqDu6nOVq1GQloEjeRN8jXrj0MVUexB9aIECs7caKGddpuut3";

        [Benchmark]
        public bool ToLower()
        {
            return defaultString.ToLower() == defaultString.ToLower();
        }

        [Benchmark]
        public bool ToLowerInvariant()
        {
            return defaultString.ToLowerInvariant() == defaultString.ToLowerInvariant();
        }

        [Benchmark]
        public bool ToUpper()
        {
            return defaultString.ToUpper() == defaultString.ToUpper();
        }

        [Benchmark]
        public bool ToUpperInvariant()
        {
            return defaultString.ToUpperInvariant() == defaultString.ToUpperInvariant();
        }

V .NET Core 3.0 je povečanje za vsako od teh metod ~x2 in uravnava implementacije med seboj.

Tier Compilation

V prejšnjem članku sem na kratko opisal to funkcionalnost in želel bi popraviti ter dopolniti svoje besede. Večstopenjska kompilacija pospeši čas za zagon vaše rešitve, vendar žrtvujete dejstvo, da se deli vašega kode kompilirajo v bolj optimizirano različico v ozadju, kar lahko povzroči manjše preglede. Z prihodkom NET Core 3.0 se je zmanjšal čas sestavljanja projektov z vklopljeno večstopenjsko kompilacijo in so bile odpravljene napake, povezane s to tehnologijo. Prej je ta tehnologija povzročila napake pri prvih zahtevah v ASP.NET Core in zmrzovanje pri prvem sestavljanju v načinu večstopenjske kompilacije. Trenutno je v .NET Core 3.0 privzeto vključena, vendar jo lahko po želji izklopite. Če ste na položaju vodje ekipe, senior, middle ali vodja oddelka, morate razumeti, da hitra razvoj projekta povečuje vrednost ekipe in ta tehnologija vam bo pomagala prihrani čas tako razvijalcem kot tudi samo delovnemu času projekta.

.NET nadgradnja

Povečajte različico vašega .NET Framework / .NET Core. Pogosto vsaka nova različica prinaša dodaten povečanje učinkovitosti in dodaja nove funkcije.

Kakšne so natančne prednosti? Poglejmo nekatere od njih:

• V .NET Core 3.0 so se pojavile R2R slike, ki bodo zmanjšale čas zagona .NET Core aplikacij.
• Z različico 2.2 je prišla večstopenjska kompilacija, ki bo programerjem omogočila, da porabijo manj časa za zagon projekta.
• Podpora novim standardom .NET Standard.
• Podpora novi različici programskega jezika.
• Optimizacija, z vsako novo različico se izboljšuje optimizacija osnovnih knjižnic Collection/Struct/Stream/String/Regex in še veliko drugega. Če prehajate z .NET Framework na .NET Core, boste iz notranjosti pridobili velik povečanje učinkovitosti. Kot primer priložim povezavo na del optimizacij, ki so bile dodane v .NET Core 3.0: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/

Zaključek

Pri pisanju kode je vredno posvetiti pozornost različnim vidikom vašega projekta in uporabiti funkcije vašega programskega jezika ter platforme za dosego najboljšega rezultata. Vesel bom, če boste delili svoja znanja, povezana z optimizacijo v .NET.

Povezava na github

Izvor: habr.com