Är det någon skillnad på Skalbarhet vs Prestanda.
Vad är dess skillnad, vad anser ni???

"DENNA tråd är till för att prata om ämnet. Det är ingen fråga jag vill ha svar på...
diskusionen är fri... Anledningen till denna tråd är för att ämnet togs upp i en annan tråd
som tappade fokus."

>Är det någon skillnad på Skalbarhet vs Prestanda.

Finns det någon likhet?

Skalbarhet anger hur prestanda förändras vid ökad belastning, dvs en slags derivata för att prata i matematiska termer.

Många blandar ihop skalbarhet med prestanda.
Beroende på hur man ser det (min uppfattning) så skalar man oftast för prestanda.

Ex Man skalar ut för att kunden skall uppleva att saker går snabbare.
Man skalar upp för att ens applikation skall gå snabbare för att kanske slippa lägga för mkt tid på optimera kod.

Målen med bägge är oftast det samma... Att minska svarstider, att få snabbare upplevelse m.m.

Prestanda är ju hur snabbt systemet upplevs, och vi skalar oftast för att öka upplevelsen.

Sedan kan man bygga ett system icke skalbart (om vi pratar skala ut nu) där man dock kan bygga systemet baserat på att ha hög prestanda. Där av rubriken Skalbarhet vs Prestanda. (Vad är skillnaden och vad menar vi med de två orden... )

Jag håller med Martin här..

Tex. ett program som lägger massa data i RAM, kan få bra prestanda pga att mycket går att slå upp snabbt..

men den kommer inte vara vidare skalbar om du kopplar på fler användare om appen körs på en server..

>Där av rubriken Skalbarhet vs Prestanda. (Vad är skillnaden och vad menar vi med de två orden... )

Nu förstår jag vad du menar. Det du menar med skala ut/upp är att öka mängden resurser (det kallar jag för att bygga ut men det behöver inte vara mera rätt).

Med skalbarhet menar jag i vilken grad en utbyggnad verkligen ger en prestandaökning.


Så det vi diskuterar här är om man skall öka mängden resurser eller om man skall "optimera" resursutnyttjandet.

Jag brukar använda lite olika definitioner på skalbarhet beroende på målgrupp men essencen är den samma:

"skalbarhet är ett mängdbegrepp för hur möjlig /throughput/ ökar i linje med mängden hårdvara".

Det innebär att en lösning som kan ta emot exakt en användare per tillagd server har i princip linjär skalbarhet (100%), medans en lösning där server 1 ger en througput på 1000, att lägga till en server och få en total throughput på 1300 och sen lägga till en tredje och då få en throughput på 1400; är mycket sämre skalbarhet, även om vi totalt kan serva fler användare.

Jag brukar alltid prata om skalbarhet, prestanda och data integritet som en treenighet där om jag optimerar för en av dem måste tumma på de andra två. Dvs skalbarhet och data integritet får stryk om jag optimerar 100% för prestanda, likaså får data integritet och prestanda stryk om jag optimerar 100% för skalbarhet.

Den här bilden brukar jag använda för att beskriva relationen dem emellan:


http://www.lowendahl.net/images/holy_threesome.jpg

Patrik, du och jag menar nog samma sak att skalbarhet är en egenskap hos applikationen som kan vara bra eller dålig.

Johan menar att skalbarhet är något man kan lägga till en befintlig applikation för att öka prestanda.

Om vi håller oss till Johans definition så ligger grundfrågan här:

>Man skalar upp för att ens applikation skall gå snabbare för att kanske slippa lägga för mkt
>tid på optimera kod.

Dagens verktyg och programspråk är dåliga på att hjälpa till med skalbarhet. Min uppfattning är att det är oundvikligt att lägga tid på att optimera kod nu när "the free lunch is over" (dvs hårdvaran blir inte snabbare längre utan bara mer parallell)

Med optimera kod menar jag dock inte att byta ut double mot int, undvika exceptions mm. Jag hävdar att sånt alltid är bortkastad tid och pengar (om man inte gör det i något annat syfte än prestanda förståss).

Optimera kod för mig är att se över algoritmernas resursutnyttjande.
Kan man förändra en algoritm så att det blir ett databasanrop mindre vinner man så mycket mer än vad alla smarta kodtrick någonsin kan ge.

Läste nyligen en artikel refererad från slashdot som undrade lite över hur det skall gå i framtiden. Programmeringsutbildningar nuförtiden (iallfall i USA) försöker medvetet distansera programmeringen från hårdvaran så mycket som möjligt (Java togs som exempel). Det finns ingen "känsla" längre för hur programkod kommer att exekveras och därför ingen förståelse för hur program skall skrivas för prestera bra. Prestanda och skalbarhet är något man försöker fixa till i efterhand och då hamnar man ofta i saker som att byta ut string mot stringbuilder när grundproblemet är en felaktig algoritm.

Mycket prat men min slutsats är att "skala ut" bara ger en tillfällig förbättring. Har applikationen dålig skalbarhet slår man snart i taket igen.

Jag vill nog hävda att man måste tänka skalbarhet även för att skala upp, inte bara för att skala ut.

Om du tex har lägen där du inte kan ta emot fler användare men processor och minnesanvändningen bara spikar aldrig ligger på en jämnnivå, då kommer det inte hjälpa speciellt mycket att skjuta in mer processorkraft eller mer minne.

Så skalbarhet kan man sabotera både för upp och ut.

"Mycket prat men min slutsats är att "skala ut" bara ger en tillfällig förbättring. Har applikationen dålig skalbarhet slår man snart i taket igen."

man kommer alltid slå i taket för eller senare, men om du har riktigt dålig skalbarhet så kommer du till slut att nå en punkt där det inte längre spelar någon roll hur mycket mer hårdvara du har, antalet användare / mängden last du kan hantera kommer fortsätta vara konstant. Ju sämre skalbarhet desto snabbare kommer du till punkten att hårdvara inte längre kan hjälpa dig.

Eftersom Johan säkert syftade på mig angående den andra tråden :). Så tänkte jag ge min syn på skalbarhet och prestanda.

Den är inte lika snävt definerad som Patriks : "skalbarhet är ett mängdbegrepp för hur möjlig /throughput/ ökar i linje med mängden hårdvara", utan även hur man skulle kunna göra förändringar i uppdelning av hur och var koden körs. Om ni läst den andra tråden så tog jag ett exempel där man hade 4 sidor websidor var av 3 var extremt snabba och den sista var långsam, då den innehöll massor med beräkningar och långsamma anrop. I detta fall så kan man ju skala ut på olika sätt, och även skala upp. Men om vi tar skala ut, så kan man göra det genom att helt enkelt bara lägga till fler webserverar och du kommer iprincip få en linjär ökning av antalet samtidiga användare jämfört med antalet webservera du ställer ut (om vi antar att bakomvarande system inte har några begränsningar).

Alltså om en webserver kan max hantera 100 användare på 3 sekunder (enligt mitt exempel i föregånde tråd), så kommer 2 webserver hantera 200 användare och 3 webserverar hantera 300 användare osv osv. Det är ju faktiskt en ganska schysst skalbar lösning, vi ökar antalet samtidiga användare med 100 för varje ny server vi lägger till.

Men om man istället analyserar koden, så ser man brister i hur själva uppdelning av koden skulle kunna skalas ut, eftersom 75 % av koden blir lidande för de andra 25 % så kanske man kan göra om sin kod så att de 75% inte blir påverkade av de sista 25%. Och genom att flytta ut delar av koden på separata maskiner och där med komma runt "flaskhalsar" i OS/IIS så är det enligt min mening en mer skalbar lösning. Prestanda blir givetviss lidande eftersom vi har skapat fler abstraktionslager och lagt in mer komplexkod för att hanterar denna skalbarhet. Det kommer ta längre tid per anrop än tidigare, men den totala upplevelsen kommer att uppfatas som snabbare då de 75% av koden inte behöver bli begränsad av de andra 25% av koden.

- M

Att koden går att distribuera är inte en garanti för att den kan skala.

Magnus: Det du missar är att det är lätt att bygga så att det finns saker som alla behöver komma åt, och som då blir flaskhalsar. T.ex. en databas, eller en viss tabell i en databas osv. Det löser man inte genom att slänga dit en till maskin. Och det är väl lite det som är ett utav problemen med att skala ut..?

Man kan ju ha databaskluster.

Det löser inte alla problem direkt. Ett databaskluster i sig skalar inte perfekt.. Dessutom, du har fortfarande problem med låsningar, om än nu ännu större bekymmer ;)

"Att koden går att distribuera är inte en garanti för att den kan skala."

Nej helt klart, i vissa fall finns det ingen som helst vinst att lägga ut det på fler maskiner. Om vi tar mitt exempel igen ovan (och från förra tråden), så skulle jag ju inte vinna något på att flytta ut hela businesslagret på en och samma maskin om det vore webservices, efter som det skulle innebära att jag bara flyttade begränsningen från en maskin till en annan. Om det nu inte vore så att det är CPU och Minne som är problemet, för då kanske det blir bättre om man flyttar en del av lasten till en annan maskin.

Det jag menar är att om man kan koda isig förbi typiska begränsningar som finns med olika lösningar så skulle man kunna få en mer skalbarlösning genom att separerar på koden till olika maskiner.

Jag tycker inte att koden är speciellt skalbar även om den skalar ut bra genom att öka antalet maskiner om man kan få den betydligt bättre genom att koda runt begränsningar, och där med kunna få ut ännu mer prestanda ur applikationen med mindre antal maskiner än om jag bara slängt upp 8 stycken webservers (där alla lager ligger på samma maskin) som totalt hade kunnat klar 800 samtidiga användare om 3 maskiner där de olika lagrerna ligger på vars en maskin klara samma eller fler samtidiga användare.

- M

"Magnus: Det du missar är att det är lätt att bygga så att det finns saker som alla behöver komma åt, och som då blir flaskhalsar. T.ex. en databas, eller en viss tabell i en databas osv. Det löser man inte genom att slänga dit en till maskin. Och det är väl lite det som är ett utav problemen med att skala ut..?"

Klart att det finns fysiska begränsningar, det kommer alltid finnas begränsningar, men om man kommit så långt i sin kod att det inte är koden som begränsar en eventuell skalbarhet utan som du säger något annat bakom så kan man ju inte göra så mycket åt det.

Om mitt databaskluster nu är kört i botten så kan jag inte göra så mycket åt det, men den dag som någon bestämmer sig för att göra något åt databasklustrert så skall inte flaskhalsen flyttas direkt till min kod och flaskhalsen hamlar där. Om jag kodar rätt från början så kommer ju min applikation så fall istället ta nytta av att det finns fler lediga kopplingar till databasen och uttnyttja dem för att öka prestandan. Om jag inte skriver den koden rätt från början så händer ju inget när man pumpar in en mille för att utöka databasklustret, och då har man inte tänkt rätt när man kodar

Sedan så finns det ju tillfällen då man bara är ute efter extrem prestanda, jag vet att applikatione aldrig kommer ha hundratals samtidiga användare, utan enbart kommer användas av några få, då kan man istället lägga krut på att få till prestandan istället för att koda komplexa lösningar för att få till skalbarheten. Men oftas så vinner man i längden på att fokuser på skalbarhet istället för prestandan.

Om vi tar ett exempel där du har ett UI och ett BLL för en website (en maskin), så säger vi att 50% av CPU tiden ligger på UI och 50% ligger på BLL och maskinen går på knäna för att klara med det hela. Visst kan man slänga dit ytterligare en maskin och skapa ett kluster, men helt plötsligt får du en betydligt dyrare lösning, då licenskostnader ökar, dessutom så skapar det andra problem om du inte kan garantera att samma besökare träffar samma maskin vid varje hit, om du håller något i ett minne på servern.

Om man däremot bara flyttar ut UI och BLL till olika maskiner så har du likvärdig prestanda, visst det tar någon futtig ms att anropa BLL (beroende på protkoll) men knappast något som kommer märkas i det hela, och dessutom så får du betydligt lägre kostnader för den maskinen eftersom du inte behöver ha den i ett kluster, och eventuell minneshantering av state på UI behöver inte ändras. Det blir alltså billigare att koda skalbart från början, även om prestandan kanske inte ökar, eftersom du kan få samma prestanda med 2 maskiner i ett kluster.

- Magnus

Per:
Ett databaskluster är i princip bara till för failovers.

När data persisteras måste de lagras någonstans, om det inte lagras på samma fysiska hårddisk så får du en hel uppsättning med väldigt intressanta replikeringsutmaningar om du inte väljer att partionera datat istället. I båda fallen pratar vi om extrema situationer där det kommer att krävas mängder med resurser och tid för att få till på ett affärsmässigt säkert sätt. Så i praktiken är det oftast databasen som blir svårast att skala ut och en av nyckelfaktorerna till hög skalbarhet är att man är snäll mot databasen med få lås och så lite access som möjligt.

Ett databaskluster kan även ge ökad prestanda:
http://www.mysql.com/products/database/cluster/

När det gäller lås är det viktigt att förstå att det finns en skillnad mellan läsa och skriva. Läsa kan godtyckligt antal göra samtidigt och om en tabell endast läses behövs egentligen inget lås. Men så fort det kan hända att man skriver till en tabell, behövs lås.

Om du hanterar t.ex. pengar så har du ofantliga krav på dig att du kan garantera att t.ex. en insättning inte görs dubbelt, eller ett uttag. Att då "bara" slänga dit ett kluster, och tro på hög prestanda, lär ge en hel del problem.. Även läsningar är lite av ett problem då. Hur man sedan tacklar det är en annan fråga..

Ingen som har koll på om det finns vettiga alternativ till den principen som idag används inom databaser, det känns så jävla 80-tal.

Om man ser på trådar/processer och distribution och uppdateringar av driftsatta system så ligger ju Erlangs möjligheter en bit framför alla gamla stökiga varianter. Finns det något motsvarande för databaser?
Non-relational, kanske?
Någon slags transaktions-prediktion-tjohej?

Dels är det som jag sa, deras fokus är "availability",

"MySQL Cluster combines the world's most popular open source database with a fault tolerant database clustering architecture so you can deliver mission-critical database applications with 99.999% availability."

Sen när det gäller deras "prestanda ökning" så använder de, precis som oracle, en "Shared One" lösning. Dvs de delar samma hårddisk och försöker miniminera access mot den genom att cacha data lokalt i varje nod. Det kommer att minska accessen på den disken och på så sätt flytta gränsen för hur länge servern klarar av att arbeta. Men när du slår i taket så har du slått i taket med "share one", när disken inte kan skriva mer så kan den inte, det är en fysisk begränsning.

Problemet med cachning av det här slaget är att synkronisera dem så att informationen alltid är samma i båda noderna. Vilket gör att man i praktiken bara flyttat problemet till en annan del av hårdvaran, minnet och nätverkskortet.

Databsen är den plats som kommer att sätta gränsen för när du inte kan skala längre och ur skalbarhetsperspektiv är lösningar som shared-one är bara en huvudvärkstablett på ett avhugget ben.

<b>Sen när det gäller deras "prestanda ökning" så använder de, precis som oracle, en "Shared One" lösning. Dvs de delar samma hårddisk och försöker miniminera access mot den genom att cacha data lokalt i varje nod.</b>

Varifrån har du fått det där? Det jag hittar tyder på att du har fel:
<info>MySQL Cluster and Oracle RAC are both focused on delivering high-availability database solutions. However, Oracle uses a "shared storage" architecture, whereas MySQL Cluster uses a "shared nothing" architecture.</info>
http://www.mysql.com/products/database/cluster/faq.html

Mitt misstag, eftersom de påstod att de fick ökad prestanda baserat på att de cachade datat i klustret så antog jag att de menade på samma sätt som oracle.

Men med shared nothing så innebär det alltså att den, precis som MS SQL, inte får några direkta prestandaökningar baserat på klustret, utan på den cachning som görs.

Att i realtid replikera datat så att lås, och information är up-to-date på båda maskiner kostar bra mycket mer än det smakar.

Det beror väl på...? Om systemet har en hög läsbelastning, men låg skrivbelastning, borde inte synkning behöva ta så mycket tid. Men om man har hög skrivbelastning, är det bäst att hålla sig till en nod.