Vill att när man anropar databasen så ska anropet hamn i en kö först i databasen, om det skulle vara många som försöker samtidigt!
Någon som har några bra ideer/erfarenheter hur man löser det smidigast?
SQL Kö system
18 svar · 594 visningar · startad av hakan@4u2.se
Varför vill du ha det så?
Om inte databasen du har nu kan prestera tillräkligt ska du byta databas.
Jag tror att det kommer att behövas mkt prestanda, jag använder SQL server 2000 nu, jag har inte byggt applikationen ännu iof.
Det jag vill skydda mig mot är prestanda problem och att beräkningarna kan bli fel om det kommer in en massa nya värden innan han är klar med den första beräkningen mm!
Om du kollar in stora siter så har de "skydd" mot överbelastning, typ Lunarstorm, "just nu är det stressigt"! Banker har oxå skydd har jag sett!
Vet inte exakt hur det har gjort det, men antar att det är ett slags kö system de använder sig av???
Transaktioner är det du måste använda, iallafall för att kontrollera så att det inte blir inkonsistens i databasen ifall en av flera UPDATE-/INSERT-frågor failar.
Huruvida låsningen funkar i dessa fall, har jag mindre koll på.
Om du kollar in stora siter så har de "skydd" mot överbelastning, typ Lunarstorm, "just nu är det stressigt"! Banker har oxå skydd har jag sett!
Lunarstorm har ju visserligen ~25-30,000 besökare på sajten samtidigt på dagarna, så man kan ju förstå att de behöver en sådan funktion, men det är tveksamt i ditt fall, såvida det inte är en grymt klen server eller större projekt än jag tror att det är.
Att det kommer att kräva en sådan mängd prestanda är ju inte helt säkert, även om specen säger det, men det kan ju vara bra att bygga det ifall, alltid surt att implementera det efterhand!
Säger specifikationen att du kommer ha över 1,000,000 besök per månad? Och du har tänkt att bygga sidan med vanliga, scriptade ASP-sidor?
Den ska klara över 1miljon besök per månad enligt specen!
Något bättre förslag en scriptade ASP sidor?
hakan@4u2.se skrev:
Den ska klara över 1miljon besök per månad enligt specen!
Något bättre förslag en scriptade ASP sidor?
Den skall klara över en miljon besökare per månad och du frågar i ett forum hur du skall sköta låsningen på radnivå i din databas?
Okey, det låter spännande. Får man fråga vad det är för typ av projekt? :)
Det liknar typ Managerzone fast det är ett annat spel än Fotboll o Ice hockey!
Okey. Låter som du har en bra idé.
Dock;
- 1 miljon besökare i månaden? Det låter väldigt optimistiskt, även om det kan vara sant. Var kommer siffran ifrån? Är den uppskattad av kunden eller av dig?
- Om du nu kommer att ha en sån besöksfrekvens och sidan skall vara helt databasdriven, alltså antagligen göra anrop hela tiden, så bör du nog se till att läsa på lite om transaktioner och låsningar innan du sätter igång.
- Dessutom, om det nu blir gamla goda ASP som scriptspråk, se iallafall för Guds skull till att, som @nders säger, kompilera och strukturera koden i komponenter, om du vet hur man gör det.
Jag vet inte själv hur man gör den typen av låsningar smidigast. Jag antar att det finns ett antal olika standarder för i vilken ordning vissa typer avv dataläsare och dataskrivare får access till databasen och i vilken utsträckning.
Kunden säger att det ska kunna vara typ 30.000-40.000 användare per dag det blir cirka 1 miljon per månad!
Komponeter har jag bara har provar lite o göra, jag kan göra dem men är väl ingen hejare på det! Har ni några bra råd hur man gör "bra" komponter så uppskattas det oxå!
Går det inte att göra komponeter i nya vb.net för att användas i ASP? Måste jag använda gamla vb6 för det?
Hur mycket kan du om relationsdatabasdesign? Har du byggt en så stor lösning innan? Vet du vad transaktioner är och hur de fungerar? Har du hårdvaran att klara 30k besökare varje dag och framförallt; har du bandbredd / transferlimits?
Jag har nu funderat i ett par minuter på det här och kommit fram till följande, ifall det nu kan vara till någon hjälp:
Eftersom du bygger en applikation som skall användas av så pass många användare samtidigt, så är det viktigt att tänka på konsistensen i datat, ja, precis som du oroade dig för. Med ett undantag; att två användare faktiskt kan skriva över varandras data. Kommer detta att ske? Kommer en användare att läsa en post i databasen, samtidigt som en annan kommer ändra samma post? Det finns säkert tillfällen, men jag ser dem inte när jag tänker efter just nu. Datat blir liksom privat att skriva för varje användare, men publikt att läsa. Typ. ;)
Transaktioner är ett måste. Gör du flera statements mot databasen i en 'batch' och en av dem går fel, så måste de andra göras ogjorda, annars riskeras datats konsistens. Detta skall du sköta i dina komponenter.
Fundera på var det finns tillfällen där två användare kan få möjlighet att ändra varandras data. Där är de ställen där låsningar måste tillämpas. Hur är en senare fråga som man tar när man vet hur flödet ser ut.
Relationsdatabasdesign har jag arbetat en hel del med!
Transaktioner och transferlimits har jag aldrig använt... men transaktioner verkar inte så svårt iof! Transferlimits vet jag inte alls hur det fungerar..
Bandbredden är inte bestämmt vad som ska väljas, blir lite först och sedan utökas den med mer allt eftersom det behövs! Likadant med hårdvaran, men programvaran och databaserna är planerade att det ska vara lätt att lägga dit en eller flera nya sql server eller webbservrar utan att man måste göra om programvaran!
Ett tillfälle när användarna kommer att ändra varandras datan är i handeln av spelare och lag mm! Principen blir som en börs - aktiehandel! Där är väl ett tillfälle man måste använda låsningar och kösystem för att det ska fungera till 100%!
En så stor lösning har jag aldrig arbetat med...blir en utmaning!
Med transferlimits så menar jag alltså om det finns några restriktioner för hur mycket data som du får skicka till/från din server under en viss tidsperiod. Om du nu har egen server och lina, så kanske detta visserligen inte är något problem.
Ett tillfälle när användarna kommer att ändra varandras datan är i handeln av spelare och lag mm! Principen blir som en börs - aktiehandel! Där är väl ett tillfälle man måste använda låsningar och kösystem för att det ska fungera till 100%!
Isåfall skall du använda adLockPessimistic i ADO, för att säkerställa att du inte får inkonsistens.
adLockPessimistic fungerar (såsom jag förstår det) som så, att om du öppnar en eller flera rader, så låses dessa för alla andra, tills dess att du kör en UPDATE, allt enligt MSDN. När du använder denna typ av lås måste du dock använda .open-metoden på dina recordset i combination med propertyn LockType, vilket lär vara prestandamässigt sämre i jämförelse med .Execute-anrop på connection-objektet (som inte stödjer olika låstyper, enligt vad jag förstått). Du kan inte använda adUseClient tillsammans med adLockPessimistic.
Jag är inte hundra procent säker på hur man skall göra det där, för på något sätt så är ju ett webbaserat gränssnitt typ 'stateless', vilket innebär att om du hämtar data, så stänger du också kopplingen på samma sida, vilket (jag antar) gör att låset försvinner. Jag vågar som sagt inte svara på exakt hur det fungerar. Någon som kan fylla i? :)
Också mer nyfiken på adLockPessimistic