Men i .net så är jag lite rädd för att prestandan ska ta skada av att man från gränssnittet går ner till datalagret och sedan upp igen
Det som tar tid är användningen av databaser, inte att du har delat upp din applikation i flera lager. Visst det finns en prestanda hit i att anropa 10 metoder istället för att skriva samma kod i en metod. Dock så är den prestanda hiten så försvinnande liten att de vinster du får med att dela upp din applikation i flera lager med råge överväger den försvinnande lilla prestand förlust då får.
Har man flera anrop så kan det väl bli lite tungt eller är detta kanske inte några problem pga "connection poolingen"?
Nu har inte connection poolingen så mycket med "flera anrop" att göra, eftersom du kommer att vara tvungen att göra dessa anrop varesig du vill eller ej, eftersom de krävs i din kod.
Vad connection poolingen är bra till är att när du gör flera anrop, så kan man göra det på 2 sätt.
1. Öppna databasen, gör alla dina anrop, stäng databasen
2. Öppnar och stänger databasen vid varje anrop.
I exempel 1 så kapslar du in alla dina anrop i en öpen koppling, och på detta vis så kan man öka prestandan, eftersom man bara öppnar sin koppling 1 gång.
I exempel 2 så kasplar du in varje anrop i en egen koppling, det betyder att du får öppna och stänga din databas lika många gånger som du gör anrop och det är detta som tar tid, att öppna en databaskoppling, det du vinner är skalbarhet. Alltså om din databas bara kan ha 10 öppna kopplingar, så kan du i exempel 1 inte ha mer än 10 besökare samtidigt på din site, men där du i exempel 2 kan ha fler än 10 eftersom alla inte samtidigt kommer ha en öppen koppling mot databasen (den är ju faktiskt stängd ibland).
För att då minska ner den prestandförlust det blir att öppna och stänga kopplingen hela tiden, så använder man sig av connectionpooling, där det då finns några öppna kopplingar som programmet kan använda sig av.
Säg nu att vi i vårt exempel skrivit koden så att lika mycket tid läggs på databasanrop som på övrig kod. I exempel 1 så kommer 10 besökare kräva 10 öppna kopplingar, eftersom vi först öppnar koppling, gör all kod, och sedan stänger den. I exempel 2 så öppnar vi bara kopplingen när vi behöver den, och har den stängd när vi exekverar annan kod, om det ny tar lika mycket tid, så kan vi säga att hälften använder databasen, medans hälften exekverar kod, i exempel 2 så behöver vi alltså bara ha 5 samtidiga kopplingar mot databasen. Om vi har en connectionpool med 5 kopplingar i, så klara sig vår lösning i exempel 2 med dem, medans exempel 1 måste öppna 5 till. Alltså har vi fått sämre prestand med exempel 1 än med exempel 2 eftersom det tar längre tid att öppna en koppling, än att kontrollera om det finns en ledig i connectionpoolen.
Så vårt system har med exempel 2, blivit både mer skalbart och fått en bättre prestanda.
Angående MySQL och connectionpooling, så har jag svårt att tro att de inte använder sig av det default, då nästan alla andra databaser gör det. Vad man skall komma ihåg om man skall använda sig av connection pooling är att connectionsträngen måste se exakt likadan ut.
Så om du har exempel 2 och har 10 olika användera och man använder deras rättigheter så kommer man få 10 olika connectionstrings och connectionpoolen har spelat ut sin roll. Om du däremot har samma connectionstring för alla dina använderar oberonde av vem det är, så har du en vinst med connectionpoolen.
- M