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.

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.

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

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.

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.

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.

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.

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

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.