Applikationsprestanda

[ARKIVERAD] Senast uppdaterad av Joe Schaefer den Fri, 26 Apr 2024    källa
 

Många utvecklare faller i fällan att tänka prestandaoptimering handlar om att göra varje rad av kod så effektiv som möjligt.

Det är faktiskt tvärtom. Du börjar med applikationens arkitektoniska begränsningar och använder dem för att borra ned till den observerade “långsamma” delen av programmet. Den delens implementering guidar alla andra prestationsval du behöver göra. Allt som inte är så långsamt som den delen behöver inte optimeras ytterligare. Fokusera istället på det mänskliga uttrycket och implementeringens enkelhet och tydlighet, till icke-expertläsare över SSDLC

Du kan iterera på den här spelboken, men jag har aldrig behövt gå utöver 3 iterationer i min professionella karriär.

Så fortsätt och använd ett elegant programmeringsspråk som Python3 eller Javaskript/Typsnittoch låt ämnesexperterna (SME) där ute i världen med öppen källkod ge dig kraftfulla C/C++

Även ett beroendefritt bash-skript är en fungerande lösning för många grundläggande uppgifter. Här är en jag skrev för Augmented Reality firm Magiskt språng år sedan, för att ersätta en klumpig OpenGrok tjänst med något som utnyttjar parallellisering med flera processorer med xargs -Poch stöder PCRE sök med enkel Emacs/Vim

https://github.com/joesuf4/home/blob/wsl/bin/pffxg.sh

Det skriptet är en storleksordning snabbare än de vanliga misstänkta på GitHub, som alla skrevs i statiska, kompilerade programmeringsspråk. Men genom att identifiera den exakta flaskhalsen i basiska (slinga med hög volym) gaffel + körning samtal i mitten), och använda xarg istället får du ett skript som ser mycket ut som detta, med kärnalgoritmen implementerad i 10 rader av skal

Det använder också Open Source Community av SME på ett smart sätt, i stället för hur de andra “filtrerade rekursiva grep” implementeringarna på GitHub gjorde. Istället för att internt anta och upprätthålla min egen (trådade) implementering av söka, xargoch fetknoppJag återanvänder bara de förinstallerade körbara filerna som andra ME har fulländat under årtionden ** i befintligt skick**. Jag behöver inte behärska deras implementationer, bara återanvända deras kommandoradsgränssnitt

För att se motsatsen, där allt görs internt, helt mikrooptimerat och fortfarande inte kan slå det här skriptet med standardsökalternativen och inget cachningssystem tillgängligt, här är ett bra exempel https://github.com/BurntSushi/ripgrep

Bara för att dra den första #performance #benchmark från den sidan, och skala upp den från en leksak prov trädstorlek (linux kärna källor), till ett heterogent träd som är 23GB: (bästa körningar efter 3 iterationer; LANG=en_US.UTF-8

    % du -sh .
    23G .
    % time rg -uuniw '[A-Z]+_SUSPEND' | wc -l
    6259
    rg -uuniw '[A-Z]+_SUSPEND' 9.46s user 16.08s system 261% cpu 9.759 total
    wc -l 0.00s user 0.07s system 0% cpu 9.759 total
    % time pffxg.sh -- -wnE '[A-Z]+_SUSPEND' | wc -l
    5855
    pffxg.sh -- -wnE '[A-Z]+_SUSPEND' 16.66s user 2.68s system 429% cpu 4.501 total
    wc -l 0.00s user 0.00s system 0% cpu 4.501 total

Det är ganska dumt att mikrooptimera något som är djupt knutet till tillståndet i kärnans filsystemcache för din sökning. Variationen i prestandatider domineras av åtkomsthastigheten till arkivens innehåll, och det är en storleksordning som är mer relevant än någon annan faktor för slutresultatet. Att vara på en NVMe hjälp, men ingenting i detta utrymme slår RAM

Det är därför att ha en komprimerad cache i minnet för en stor korpus av filer, kommer att stabilisera prestandatiderna. Det är förvånande att ingen annan tyckte att detta var tillräckligt viktigt för att stödja.

Ta den andra #performance #benchmark från den sidan och skala upp den som tidigare (samma 23GB

    % time rg -tc -uuuiwn '[A-Z]+_SUSPEND' | wc -l
    5629
    rg -tc -uuuiwn '[A-Z]+_SUSPEND' 3.51s user 1.71s system 1141% cpu 0.457 total
    wc -l 0.00s user 0.05s system 11% cpu 0.457 total
    % time LANG=C pffxg.sh --cache /tmp/pffxg-$USER --workers 32 --cc -- -wE '[A-Z]+_SUSPEND' | wc -l
    5628
    LANG=C pffxg.sh --cache /tmp/pffxg-$USER --workers 32 --cc -- -wE  3.14s user 0.88s system 1055% cpu 0.381 total
    wc -l 0.00s user 0.00s system 0% cpu 0.381 total

En stämd pffxg.sh är fortfarande snabbare, trots allt arbete i mikrooptimering ripgrep för detta C

Hur jag använde detta manus med AOSP var att schemalägga en lager synkronisering och efterföljande pffxg.sh **länk-komprimerad-cache frö-till-tillf.Kör varje morgon före jobbet (via crontab), med PFFXG_CACHE=... sätta i min ~/.pffxg.conf fil. Alltså någon pffxg.sh anrop som jag körde under arbetsdagen skulle använda den komprimerade cachen i tillf.

.25M LOC mellan ripgrep och ugrep. 632 LOC för pffxg.sh

Eftersom det är ett så litet skalprogram, pffxg.sh kan ge dig kraftfulla krokar i sina inre med nästan noll ansträngning. Till och med fetknopp kommandot själv är anpassningsbar: alla kommando du behöver för att köra på en utvald korpus av filer, som kan acceptera en lista med filnamn som läggs till i slutet av dess argument, är rättvist spel. Här är en “total radräkning i MiLOC

    % time find * -type f | xargs wc -l | awk '{ $2 == "total" {a+=$1} END {print a/1024**2}'
    28.451
    find * -type f 0.00s user 0.06s system 2% cpu 2.733 total
    xargs wc -l 0.53s user 1.02s system 54% cpu 2.853 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.23s user 0.59s system 28% cpu 2.853 total

    % time pffxg.sh --workers 8 --cmd wc --all -- -l | awk '{$2 == "total" {a+=$1} END {print a/1024**2}'
    28.4506
    pffxg.sh --workers 8 --cmd wc --all -- -l 0.92s user 0.66s system 826% cpu 0.192 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.02s user 0.00s system 11% cpu 0.192 total

ripgrep

    % time rg -c \$ | awk -F : '{a+=$2} END {print a/1024**2}'
    28.4284
    rg -c \$ 2.12s user 2.19s system 276% cpu 1.564 total
    awk -F : '{a+=$2} END {print a/1024**2}' 0.58s user 0.45s system 66% cpu 1.564 total

Här är den begränsad till C

    % time pffxg.sh --workers 8 --cc --cmd wc -- -l | awk '$2 == "total" {a+=$1} END {print a/1024**2}'
    25.3935
    pffxg.sh --workers 8 --cc --cmd wc -- -l 0.76s user 0.54s system 734% cpu 0.177 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.02s user 0.00s system 9% cpu 0.177 total

och ripgrep

    % time rg -tc -c \$ | awk -F : '{a+=$2} END {print a/1024**2}'
    25.3844
    rg -tc -c \$ 3.49s user 1.54s system 441% cpu 1.140 total
    awk -F : '{a+=$2} END {print a/1024**2}' 0.38s user 0.38s system 66% cpu 1.140 total

Real ** Applikationsprestanda** kommer från balans, flexibilitet och funktionell programmeringsteknik; det kommer inte från fixering på imperativ mikrooptimeringstaktik i statiska, kompilerade programmeringsspråk som är en björn att arbeta med från balans- och flexibilitetsperspektivet. Sådana överhypade, imperativa språk är stora mål för mycket specifika problemdomäner, men är hemska för systemomfattande applikationsprestanda.

pffxg.sh är inte en produkt, och detta är inte en säljargument för det. Det är ett exempel för att illustrera min poäng på ett mycket dramatiskt sätt. Om du är bekant med den långa historien av filtrerade-rekursiva-grep-lösningar på GitHub, är de alla baserade på tanken att problemet med Andy Lester ursprungliga Perl implementering bekräftaOm det är skrivet i Perl. Det enda verkliga problemet ur ett resultatperspektiv var att Perl skrevs av Andy, som inte verkade ha någon förmåga för systemprestanda begrepp (som jordbruk ut söka parallelliseringsarbete till ett specialbyggt C binärt), men i stället syftade till lat portabilitet genom att försöka fånga hela koden som en enda trådad Pure Perl

Må tusen blommor blomma, oavsett dumma de verkar!

Permalänk 

 

   

Kommentarer  


Bilagor  

Länkar  


Index

- [Tredubbla produkter av egenfunktioner och spektral geometri](/joe/triple-products.html.sv) &mdash; Vi avslöjar en roman, men bekant, global geometrisk invariant ... <small><em>Sun, 28 Apr 2024</em></small>

Hyperbolisk honungskaka

- [Stokastisk spårningsformel för stängda, negativt böjda grenrör](/joe/stochastic-trace-formula.html.sv) &mdash; Min * 1997 Ph.D. avhandling* som ett blogginlägg. ... <small><em>Fri, 26 Apr 2024</em></small>

tjärad och fjädrad

- [Apache HTTPd Devs ansåg vara skadliga](/joe/apache-considered-harmful.html.sv) &mdash; Philip visste inte mycket då var hur fullständigt [peevish, vapid och territorial](https://www.mail-archive.com/dev@httpd.apache.org/msg77781.html) Det laget hade blivit ... <small><em>Fri, 26 Apr 2024</em></small>

Beroenden för engelska

- [Vad handlar <em>Smart Content Dependency ManagementTM</em> om?](/joe/dependencies.html.sv) &mdash; En tydlig förståelse av din webbplats *beroende graf* kommer att se till att du kan maximera prestandan hos vår byggteknik i stor skala ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Rörelsen DevOps](/joe/devops.html.sv) &mdash; Den stora idén bakom "rörelsen" är inte bara att ge utvecklare mer rep ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Roligt med htop](/joe/fun-with-htop.html.sv) &mdash; Avancerade funktioner på populära Unix-plattformar ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Git och non repudement](/joe/git-and-non-repudiation.html.sv) &mdash; Det finns en tydlig skillnad mellan "åtagandets" historia och "uppladdningens" historia. ... <small><em>

Denna uppsats gäller verkligen DVCS i allmänhet, inte bara git per se. Men vi kommer att fokusera uppmärksamheten på git eftersom det fortfarande är den mest populära DVCS runt idag.

Ej avvisande.

Med ett traditionellt centraliserat versionskontrollverktyg är sådana poster lätt tillgängliga från bekräftelsehistoriken. Varje bekräftelse till systemet går igenom en auktoriseringsmekanism för att säkerställa att den person som gjorde ändringen har behörighet att ladda upp den. Dessa register är avgörande för företaget för att säkerställa att korrekta register förs som visar vem som är ansvarig för att ladda upp varje kodrad till programvaran i fråga.

Med git, eller distribuerad versionskontroll i allmänhet, {# lede #}Det finns en tydlig skillnad mellan "åtagandets" historia och "uppladdningens" historia.{# lede #} &mdash; som jag kommer att hänvisa till som "push records". Bekräftelser i git autentiseras inte, eftersom de sker lokalt, med lokala, overifierade metadata tillagda i historiken. Uppladdningssteget, aka git push

Med Apache Software Foundation.

Varför är detta viktigt? Tja till att börja med låt mig ta itu med en vanlig missuppfattning om behovet av bidragsgivare licensavtal (ICLA) för Apache-företag. Många verkar inte förstå att det inte finns någon skillnad mellan det tillämpliga språket i de enskilda författarverken. ICLA och Apache-licens 2.0.

Vad push-poster ger då är ett sätt att spåra tillbaka, till varje rad av kod i en release, den enskilda committer som ansvarar för att driva den koden till ASF: s git-datalager. Detta är kritiskt viktigt för att bestämma härkomst av ett bidrag från tredje part med git, eftersom det tyvärr är möjligt för en sådan bidragsgivare att "gå bort" från sitt bidrag till ett git-projekt på grund av den distribuerade typen av DVCS-loggar. Den ansvariga parten blir då, enligt ICLA, den beställare som drev koden.

Tidiga och korrekta begränsningsstrategier kretsar kring att ta bort det övergivna bidraget, men skadorna på projektet kan redan ha gjorts. Och utan push-rekorden skulle vi bokstavligen inte ha någon auktoritativ process för att bestämma hur den koden faktiskt kom in i vårt lager, annat än att tråla igenom alternativa poster i problemspårare eller on-list-kommunikation. Att enbart förlita sig på sammanslagningsbekräftelseloggar för att bestämma härkomst är inte särskilt tillfredsställande ur säkerhetssynpunkt, eftersom det kräver strikt efterlevnad av en viss typ av arbetsflöde, som vi inte vill diktera.

Utan sådana saker skulle vi behöva mandat åtminstone PGP-signering av varje bidragsgivares åtagande, vilket är betungande för många projekt. Push-poster ger en transparent process som inte påverkar ett projekts arbetsflöde, annat än för att säkerställa att ASF:s git-datalager är det verkliga huvuddatalagret.

$Datum: 2023-01-19 22:58:40 +0000 (Thu, 19 Jan 2023) $


Informationsarkitektur

- [Informationsarkitektur](/joe/ia.html.sv) &mdash; Hela skalan av teknik som är relevant för design, presentation, relationer och arkitektoniska begränsningar som täcker varje URL du tjänar ... <small><em>Fri, 26 Apr 2024</em></small>

Drakens år

- [Joe's slumpmässiga tankar](/joe/index.html.sv) &mdash; Välkommen! ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Informationssäkerhet - introduktion](/joe/infosec.html.sv) &mdash; Alla data som kommer från ett exekverings-UNIX **systemanrop** ska behandlas som **behållna** ... <small><em>

Vad är det primära målet för InfoSec?

För att säkerställa att alla förändringar vid kontextgränser är väl reglerade.

Till exempel uppfyller varje systemanrop på en UNIX-plattform detta villkor när det gäller UNIX-säkerhetsmodell för användare/gruppprocess+filesystem. Den litterala definitionen av en kontextväxel, vilket anges av systemanrop, inbegriper en kontroll av API-användningssäkerheten på kärnans sida av anropet.

När det gäller leverans av SaaS, {# lede #}alla data som kommer från ett exekverings-UNIX systemanrop ska behandlas som behållna{# lede #}

UNIX säkerhetsmodell ensam gjorde aldrig bestämmelser för nätverksansluten klient / server applikationsutveckling, eftersom historiskt BSD socket API som föregick ökningen av Network Computing på 90-talet (Sun Microsystems) uppfanns över ett decennium efter UNIX föddes (med sin OS-baserade multiuser säkerhetsmodell helt bildad vid födseln). MIT Kerberos.

Schemalägga CPU:er på ett säkert sätt för att utföra arbete på kärnnivå för någon "auktoriserad användar-/grupp-/rollkontext" som inte är kopplad till den underliggande processens UNIX-användar-/gruppkontext har alltid legat utanför UNIX-modellen. Många infosec initiativ misslyckas med att erkänna detta regulatoriska ansvar tillhör program ensam; Låt inte din vara en!

Om det inte är klart vid denna tidpunkt, bör DevOps/SRE-team triaging SaaS security (CAI) incidenter på Linux bekanta sig med htops stjärt gränssnitt via ss nyckel! Bättre att behärska stjärt

Hur relaterar detta till Zero-Trust-initiativ, som en praktisk fråga?

Nolltillförlitlig arkitektur.

Även om det kan finnas VPN/Firewall-kontexter i verkligheten är ingen av dessa detaljer relevanta för InfoSec inom ett Zero-Trust-ramverk. Med andra ord kan sådana nätverkstopologisäkerhetsinitiativ öka Zero-Trust-initiativ, men de förlitar sig aldrig på inom ett Zero-Trust-initiativ på basserverns värdsäkerhetsnivå upp genom applikationsnivån.

MIT Kerberos och Active Directory är till exempel kompatibla med Zero-Trust.

$Datum: 2023-01-19 22:58:40 +0000 (Thu, 19 Jan 2023) $


 

- [Utskickslistor](/joe/mailing-lists.html.sv) &mdash; Dessa tillfälliga adresser är anathema för `ezmlm-idx`'s abonnemang och modereringssystem ... <small><em>Fri, 26 Apr 2024</em></small>

- [Perl 7 Funktionsbegäran: förseglade underdelar för typangivna lexikaler](/joe/perl7-sealed-lexicals.html.sv) &mdash; Perl 5:s OO-exekveringsmetoduppslagning har 50 % mer prestandakostnader än ett direkt, namngivet subrutinanrop ... <small><em>Fri, 26 Apr 2024</em></small>

COVID-19 i mars 2020

- [Exponentiell tillväxt och COVID-19](/joe/power.html.sv) &mdash; Ta din tid med ** matte** avsnittet &mdash; Det är viktigt att vara en utbildad konsument av statistik som är relevant för den nuvarande pandemin ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Om skräppostproblemet...](/joe/spam.html.sv) &mdash; Bästa plugin för `qpsmtpd`Även om det är svårt att förstå varför ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Informationssäkerhet, applikationsprestanda och tillförlitlighet](/joe/spr.html.sv) &mdash; "Icke-funktionell" programvaruteknik handlar om tre huvudfrågor: säkerhet, prestanda och tillförlitlighet (**SPR**) ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Glädjen i DTrace](/joe/joy-of-dtrace.html.sv) &mdash; Mät två gånger, skära en gång innan du påbörjar ett arbete med kodoptimering ... <small><em>Fri, 26 Apr 2024</em></small>

 

- [Glädjen i htop](/joe/joy-of-htop.html.sv) &mdash; Hotell nära Solaris 11 ... <small><em>Thu, 25 Apr 2024</em></small>