[Perben]

Alltså.. 5000 requests/sekund på en server, som ni kanske inte ens är exklusiva om, är en hel del. Varför inte be Loopia lastabalansera det på fler servrar, eller gör en balansering på DNS-nivå? Med sådana trafikmängder brukar man lämna "vanlig hosting" bakom sig och börja bygga någonting rejälare. Du nämner inte vad för sorts trafik det är, så svårt att veta vilken budget det rör sig om.

Vid små korta anrop behöver man pilla på Apaches och OS:ets inställningar för TCP-stacken för att optimera mot rätt sorts trafik, så hör med Loopia om du måhända kan få en egen webfront om inte annat. Man kan också göra väldigt mycket cachning ute i weblagret så att bara vänder ner till applagret visst ofta, mao att man stoppar in en Apache-modul som är gjord för just din tillämpning.

[znap]

sätt upp en frontcache med varnish

[Innocast]

SELECT SQL_CACHE `kolumn` FROM `table` WHERE `column` = 'value' LIMIT 1

Kan ju vara ett steg på vägen om inte Loopia / er lösning inte stödjer ovanstående förslag.

[Onkelborg]

Det finns en sak till att fundera på: Behöver man 1 förfrågan/sekund? Är det någon som funderat över det?

I mina öron låter det som att man vill få saker i realtid, frågan är dock vad man vill få i realtid. Det kan nämligen finnas andra lösningar än att ligga och fråga servern varje sekund, lösningar som dessutom är mer responsiva än att konstant fråga servern. En vanlig variant är att servern väntar med att returnera ett svar tills det faktiskt kommit in någonting att skicka tillbaka, t.ex. ett meddelande i en chat. Man kommer visserligen få många parallella anslutningar till servern, men de flesta kommer vara vilande.

(Kräver Windows 2008 dock, dvs. IIS 7)

[Innocast]

Originally posted by Onkelborg@May 12 2009, 15:30
Det finns en sak till att fundera på: Behöver man 1 förfrågan/sekund? Är det någon som funderat över det?
I mina öron låter det som att man vill få saker i realtid, frågan är dock vad man vill få i realtid. Det kan nämligen finnas andra lösningar än att ligga och fråga servern varje sekund, lösningar som dessutom är mer responsiva än att konstant fråga servern. En vanlig variant är att servern väntar med att returnera ett svar tills det faktiskt kommit in någonting att skicka tillbaka, t.ex. ett meddelande i en chat. Man kommer visserligen få många parallella anslutningar till servern, men de flesta kommer vara vilande.
(Kräver Windows 2008 dock, dvs. IIS 7)

Och som uppföljning, om det är uppdatering varje sekund och det är 5000 requests / s så borde en ändring till uppdatering var 5:e sekund sänka antalet förfrågningar till 1000 / s. Ser ingen direkt anledning till en uppdatering så ofta som varje sekund. Eller hämta mer data med längre tid mellan.

[eliasson]

Originally posted by Onkelborg@May 12 2009, 13:30
Det finns en sak till att fundera på: Behöver man 1 förfrågan/sekund? Är det någon som funderat över det?
I mina öron låter det som att man vill få saker i realtid, frågan är dock vad man vill få i realtid. Det kan nämligen finnas andra lösningar än att ligga och fråga servern varje sekund, lösningar som dessutom är mer responsiva än att konstant fråga servern. En vanlig variant är att servern väntar med att returnera ett svar tills det faktiskt kommit in någonting att skicka tillbaka, t.ex. ett meddelande i en chat. Man kommer visserligen få många parallella anslutningar till servern, men de flesta kommer vara vilande.
(Kräver Windows 2008 dock, dvs. IIS 7)

Precis som han förklarar så bör du antagligen tänka om, för jag kan inte heller se någon anledning att skapa en ny HTTP-request varje sekund - och istället bör man då använda long-polling eller liknande.

[danjel]

Originally posted by ledstrom@May 12 2009, 14:21
danjel, det är alltså CPU kraft vi behöver om vi ska skaffa en ny server? Eller använder sig systemet utav mycket Minne?

vid närmare eeftertanke..nja inte säkert men om ni cachar resultatet i asp.net så lagras det i minnet och så många läsningar kan ju få CPU att jobba även vid en så enkel operation..

men hur länge cachar ni..? kanske cachen invaliderar och under den tid som det tar för sql frågan att gå klart och cacha upp igen i .net så hinner det dundra in en mängd databas frågor

[Robert]

Med så många requests så kan man också ta en titt på.Net's garbage collector som timear ut gammalt skräp efter ett tag. Dock så kan en webserver gå ned på knä om GC'n blir full. En vanlig fallgrop är att använda strängkonkatenering då det blir mycket skräp (strängobjekt) som måste kasserars hela tiden. Kolla upp i dina 10 rader kod så att du inte har några sådana utan kör tex stringbuilder istället.
Kan vara värt att kolla även fast det sannorlikt inte är problemet.

Har du möjlighet (och inte ligger på ett webhotel) så sätt mätpunkter och mät via performance monitor vad som sker och när det sker...

[dAEk]

Originally posted by eliasson@May 12 2009, 15:49
Precis som han förklarar så bör du antagligen tänka om, för jag kan inte heller se någon anledning att skapa en ny HTTP-request varje sekund - och istället bör man då använda long-polling eller liknande.

Det är inte första gången jag ser dig tipsa om det här så jag måste fråga: har du nån erfarenhet av att sätta upp sådana lösningar? 5 tusen visningar/sekund är trots allt en hel del och det inte är direkt trivialt att implementera en lösning som är skalbar.
Jag är intresserad av hur hur du brukar gå till väga. Vilken plattform, vilka servrar? IIS, Apache och vilka ytterligare komponenter? Egenutvecklade kanske? I så fall, hur gör du för att komma runt problemet med sockts och trådar som käkar begränsade resurser?

Sorry för OT men det är ett intressant ämne.

[eliasson]

Originally posted by dAEk@May 12 2009, 17:48
Det är inte första gången jag ser dig tipsa om det här så jag måste fråga: har du nån erfarenhet av att sätta upp sådana lösningar? 5 tusen visningar/sekund är trots allt en hel del och det inte är direkt trivialt att implementera en lösning som är skalbar.
Jag är intresserad av hur hur du brukar gå till väga. Vilken plattform, vilka servrar? IIS, Apache och vilka ytterligare komponenter? Egenutvecklade kanske? I så fall, hur gör du för att komma runt problemet med sockts och trådar som käkar begränsade resurser?
Sorry för OT men det är ett intressant ämne.

Jag använder uteslutande Debian med Apache tillsammans med PHP och MySQL.
Vad det gäller trådar som käkar resurser så är det inga problem, om man jämnför med 5000 HTTP-requests/sekund.

Istället för att t ex göra en SQL fråga varje HTTP-request, så läser jag av cache tills det finns något värde, och sedan pushar detta till klienten med lämplig teknik - men självklart fortfarande har igång tråden - och fortsätter.

Dock har jag inte haft erfarenhet av så många anslutningar samtidigt (och när jag får det så lär jag också byta webbserver till någon lightweight) men jag vet att X antal HTTP-requests/sec väger tyngre än X antal öppna long polling trådar.

Hoppas att jag besvarade din fråga.