Hej!

Vi kör en liten tjänst som är AJAX baserad, när vi kör tjänsten så får vi cirka 5,000 förfrågningar per sekund, vi ligger idag hos Loopia och kör i .NET miljö med MySQL som databas.

Det är otroligt lite data som hämtas men det är viktigt att det hämtas varje sekund så där kan vi inte göra något åt det. Vi hämtar data ifrån MySQL Servern och sedan lägger det i cachen.

Problemet vi har är helt enkelt att HTTP förfrågningarna går för segt, på dom cirka 10 raderna kod så är nog allt optimerat.

Vad behöver vi? Mer bandbredd? En snabbare server? Vad rekomenderas?
Vi vill helst inte alls hålla på med att sätta upp server utan att programmera. Duger en VPS? Vad är rekomenderad konfiguration?

Du ger ingenting egentligen.

AJAX anropet, vad anropar filen? Vad gör denna filen? Vad är det för output från filen?
Kör du ett JS ramverk (prototype, jquery, dojo mm)?

Har själv inte Loopia, men enligt tidigare poster här så verkar Loopias MySQL vara rätt seg, tillåter bara ett visst antal anslutningar mm.

Hej!

Ursäkta, jag tror egentligen att det är en hårdvaru fråga.
Vi använder oss utav jQuery och det är json output ifrån filen med ett väldigt enkelt objekt, tjänsten fungerar klockrent när det är lite belastning. Så i och med det uteslutar vi klientsidan.

Men eftersom vi inte kör några MySQL frågor alls i princip eftersom hela webbplatsen har bara en fråga och den använder sig uta Cache.

Jag håller med om att Loopias MySQL inte är den bästa, 15 anslutningar tillåter dom bara, men jag tor ändå inte det är där felet ligger.

Hur ser queryn ut?
MySQL är väldigt kass på att cacha frågor, uppdateras tabellen så förloras cachen.

Vad för cache är det?

Vi använder cachen som är inbyggd i ASP.NET
Queryn är en vanlig SELECT Test FROM tabel ORDER BY ID DESC <- Ungefär så, väldigt simpel

Det kanske blir en skillnad om ni lägger query som en lagrad procedur istället? under förutsättning det körs mysql 5.x men det gör det väl säkert..

Jag tror inte det beror på SQL frågan då den i sig själv inte är seg alls och desutom cachas. Problemet är nog att vi har så mycket besökare under korta interval och då känns det som att webservern inte klarar trycket.

LÅter som CPU går i taket på webbservern..
Även om den läser från minnes cachen så är ju 5000/sek vääldigt mycket

En lagrad procedur i mssql är iaf snabbare att köra än en sqlsats och jag förmodar det är liknande i mysql.

danjel, det är alltså CPU kraft vi behöver om vi ska skaffa en ny server? Eller använder sig systemet utav mycket Minne?

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.

sätt upp en frontcache med varnish

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.

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.

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.

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

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...

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.

eliasson, hur fungerar long polling på server-sidan?
Vad är det för typ av cache du läser och hur (med MySQL/PHP)?

Danga: memcache
PHP: memcache

Tyvärr ligger jag i ASP.NET och Windows Miljö.. Jag kanske har glömt och förtydlga det.

Angående databasen så sker det inga läsningar därifrån mer än 1 per minut. Sen lägger det i .NET inbyggda cachemekanism. Cachningen är alltså inte MySQLs egna.

Jag har hittat ett bra exempel för .NET http://www.codeproject.com/KB/aspnet...ltiClient.aspx som jag hade tänkt och implantera, jag kan återkomma om hur det gick =) Alltså vad det gäller Comet lösning med Long Polling

Men du cachar alltså i en minut...då är det ju onödigt att köra en ajax call per sekund då informatiionen uppdateras varje minut..?
Eller cachar du per användare..?

danjel, cachen ligger max i en minut, men förändras databasen så förstörs cache objektet och ett nytt skapas. Det är själva objektet som cachas men sedan körs en enklare uträkningen med objektet och det är resultatet som förändras varje sekund. Cachen är global för applikationen

Själva requsten sker ifrån en annan webbplats så det är Cross Site, så min färdiga ASP.NET kontroll jag hittade kommer inte fungera alltså.

Den beräkningen, vad handlar den om? Går den att flytta till klienten?

Okej, så Apache klarar 5000 samtidiga långvariga trådar bättre än 5000 vanliga requests per sekund menar du? Intressant.
En av mina tidigare arbetsgivare har en egenutvecklad plattform för att komma runt skalningsproblemen med Apache så när du skriver som du gör förstår du kanske att jag blir intresserad. För mig är det här riktigt high-tech. :D

Som jag förklarar så har jag ingen erfarenhet av så många anslutningar med apache, men vid de tester jag kört så har 100 långvariga trådar presterat bättre än 100 trådar/sekund.

Någon lightweight webbserver för just "streaming"/long polling är att rekommendera.

OK då är jag med...!:)
Har ni någon cache dependency mot databasen? Jag funderar just vad som händer under den korta tid när cachen invaliderar ,då kan möjligen ett flertal requests gå ner mot DB..vi kan ju kolla koden om du postar den

Yep, en server eller tjänst som hanterar förfrågningar och svar asynkront via events, det borde vara mycket bättre. Vanliga HTTP-servrar fungerar oftast inte så, inte vad jag vet iaf.

En annan grej som också kan vara intressant är frågan hur man på ett bra sätt kan uppskatta (och mäta last-) belastningen på en Ajax-intensiv sajt. Vet ni några sjysta verktyg för det får ni gärna skriva en rad eller två.

apachetop borde ju visa ajax skapligt om man vill se live

dAEk: IIS 7 har möjlighet att köra asynkront har jag för mig, dvs. inte binda upp en anslutning = en tråd. Tomcat tror jag också klarar det? Lighttpd?

Som sagt, jag är inte heller speciellt kunnig inom området så det kan mycket väl stämma, och det gör det säkert. :)