[Clarence]

Ursprungligen postat av StefanBergfeldt

Eftersom en och en halv miljard sidvisningar per dygn betyder mer än femton tusen sidvisningar i sekunden, så tycker jag nog att vi kan dra paralleller?

Både IIS och ASP.NET är byggt för att prestera bra i storskaliga system, så jag förstår inte riktigt varför det inte skulle fungera.

Och facebook kör 10 gånger mer trafik med apache och PHP på de vanliga appservrarna. Det betyder inte att de, liksom de flesta andra, inser det olämpliga i att använda detsamma till chatt-tjänsten. Det finns olika egenskaper både hos språk och webbservrar vilket gör dom mer eller mindre lämpade för olika användningsområden. Varken apache eller IIS är ett smart val om du ska hålla igång en stor mängd anslutningar. Men vill man så, visst, man kan köpa in 5 gånger fler servrar.

[eliasson]

Ursprungligen postat av Clarence

Och facebook kör 10 gånger mer trafik med apache och PHP på de vanliga appservrarna.

Källa?
Jag har då aldrig läst att Facebook använder Apache.

[emilv]

Ursprungligen postat av eliasson

Källa?
Jag har då aldrig läst att Facebook använder Apache.

Förr presenterade sig Facebook som Apache 1.3.37 i HTTP-huvudet (fast med någon "-fb2" eller liknande på slutet, antagligen för deras egna patchar).

Enligt Slashdot verkar det som att HipHop som de kör nu även hanterar HTTP:
http://developers.slashdot.org/story...-PHP-Webserver

En vild gissning är att de slutat använda Apache på senare tid.

[Clarence]

Ursprungligen postat av eliasson

Källa?
Jag har då aldrig läst att Facebook använder Apache.

I princip alla tal eller publikationer de gjort senaste åren om sin teknik, vilket är ganska många. Jag lyssnade på ett i våras på FOSDEM där jag är rätt säker på att de nämnde det, finns på http://video.fosdem.org/2010/maintracks/.

Ursprungligen postat av emilv

Förr presenterade sig Facebook som Apache 1.3.37 i HTTP-huvudet (fast med någon "-fb2" eller liknande på slutet, antagligen för deras egna patchar).

Enligt Slashdot verkar det som att HipHop som de kör nu även hanterar HTTP:
http://developers.slashdot.org/story...-PHP-Webserver

En vild gissning är att de slutat använda Apache på senare tid.

Det kan nog stämma att allt är flyttat till HipHop nu. I våras hade de flyttat över runt 50% har jag för mig. De hade med Apache, liksom MySQL eller Memcached, patchat deras värsta problem med mjukvaran varför det låg en -fb2.

[kullervo]

Ursprungligen postat av StefanBergfeldt

Eftersom en och en halv miljard sidvisningar per dygn betyder mer än femton tusen sidvisningar i sekunden, så tycker jag nog att vi kan dra paralleller?

Både IIS och ASP.NET är byggt för att prestera bra i storskaliga system, så jag förstår inte riktigt varför det inte skulle fungera.

MySpaces webbservrar genererar en sida på ca. 0,2s och genererar således några fåtal sidor parallellt per CPU. Det är väldigt annorlunda än mot att hålla i 20000 parallella requests som HTTP long polling kan medföra.

[StefanBergfeldt]

Varför long polling?
Min chatt bygger på att hämta ny data ofta. Det blir inte push på riktigt, men å andra sidan kan dom flesta nöja sig med att det tar en sekund att leverera meddelanden.

Lämpligtvis använder man till exempel json för att överföra data, för att minska mängden overhead som skickas fram och tillbaka.

[Clarence]

Ursprungligen postat av StefanBergfeldt

Varför long polling?
Min chatt bygger på att hämta ny data ofta. Det blir inte push på riktigt, men å andra sidan kan dom flesta nöja sig med att det tar en sekund att leverera meddelanden.

Lämpligtvis använder man till exempel json för att överföra data, för att minska mängden overhead som skickas fram och tillbaka.

1.) Long polling är effektivare då du slipper extra anslutningar, som ger stor overhead för router+brandvägg+OS+webserver+applikation, och extratrafik från klienten i större mån. Det är fördel för både klient och server. Att man sedan får snabbare responstider är en trevlig sideffekt (upp till poll time snabbare).
2.) IIS (och apache) kommer alltid vara enorm overhead för applikationer där det bara är webbservern och en väldigt enkel datahämtning ("hämta nya meddelanden sedan x skrivna till y") som behövs.
3.) Trafikmängden tillbaka till klienten är väldigt sällan något större problem men påverkar såklart kostnaden en del och JSON kan du välja oavsett anslutningsmetoder.

Web sockets är på väg av en anledning. Comet är hypat av en anledning.

[JonatanH]

Med tjänsten Beacon (http://beaconpush.com/) kan man slänga ihop en realtids-chatt med kanaler på ett par timmar (som inte kräver java eller flash och som även fungerar på iphone/android). Beacon är en tjänst för att pusha meddelanden till användare via websockets (med fallback på longpoll och flash sockets), utan att behöva köra sin egen comet-server (man pushar ut meddelanden genom att göra HTTP-anrop till beacon's API).

Full disclosure: Jag jobbar på ESN, företaget som bl.a. utvecklar Beacon.

[Jonas]

Ursprungligen postat av JonatanH

...

http://www.wn.se/t3490.html §3 kan vara intressant att läsa.

[robincox]

Det känns som att det relativt enkelt borde gå att göra en ajaxlösning med hjälp av t.ex. jQuery för själva chatdelen, sen att skapa de olika chatrummen som vanliga webbsidor, alltså t.ex. chatsidan/valet2010.se är ett chatrum och chatsidan/nintendo.se är en annan. Då kan du även spara och radera inläggen hur du vill i en sql databas som du själv har kontroll över.