Fråga om AJAX
 

Om jag typ har ett ett ställe där man kan skriva med varandra. låt oss säga en chat.

Då har jag med ajax kanske varje sekund kallat på ett skript som gjort en fråga till databasen och hämtade de senaste 10 insatta radera.

Men då har ja funderat på om man kan vi varje ny rad man skriver så skriver man samma sak till en fil, chat.txt

och sen med ajax hämtar man innehåll från chat.txt varje sekund.

Det borde väl vara mycket lättare, alltså inte lika krävande? Tänker ja rätt?

Det blir nog helt fel för då har du ett extra steg och dessutom är inte chat.txt unikt för varje användare elle aktuellt, så det verkar inte vara någon bra idé.

Du skulle behöva kalla filen chat[user123].txt, chat[user124].txt, chat[user125].txt... och därmed få tusentals små filer på disken som du måste rensa bort.

Databasen är ju orginalet av informationen så du behöver hämta den därifrån. Däremo skulle du kunna kolla om det finns en ny post i databasen med en tidstämpel som är senare än den när du senast hämtade texterna från databasen. Om det fins nya postningar så slår du en hämtningsfråga, annars låter du texten på skärmen ligga kvar oförändrad.

det behöver inte vara unikt :P det ska inte vara precis som en chat. tänk dig ett forum med en tråd.

En bättre teknik att göra detta på är ju att använda push, inte pull som ajax gör.

Titta t.ex på http://meteor.com

Det funkar ju att använda ajax. Fördelen är väl att det går snabbt att göra. Nackdelarna är däremot rätt många. Men kan man leva med nån sekunds försening och inte har så många användare så funkar det ju helt ok.
Hänger bara hårdvara och bandbredd med... Kan man ju alltid ha fler användare. Men det är inte optimalt. Men för en sida med få besökare funkar det fint. Blir det fler besökare kan man ju öka tiden mellan uppdateringarna om man kan leva med det. Räknar du med många användare så googla "node.js" t.ex finns en del olika system som använder push istället precis som CotopaXi sa.

Jag hjälper en chatt ibland som använder ajax... Runt 200 inne samtidigt funkar helt ok. Men beror ju som sagt helt och hållet på hårdvara och bandbredd.

node.js tycker jag ser helt fantastiskt ut men jag har haft en jäkla tid att försöka installera det och sen köra. Det funkar inte :/.

Men mitt sätt som ja beskrev det gör ju att på varje request så hämtar en innehål ur en fil och inte en fråga till databasen. Det borde väl vara såååå mycket snabbare?

Nja, är mer eller mindre de samma. Handlar mer om datamängd då. Databaser är snabba.

Däremot får du se upp så att du inte ställer till det när det skrivs i filen. Så inte två försöker skriva samtidigt. Dvs lås filen, öppna och skriv, spara filen och sen går det att skriva i filen igen.

Om du tycker databasen är långsam så har du gjort något fel i designen. databaser är normalt mycket snabba och det är sällan man ens behöver fundera på att optimera med externa filer. jag har aldrig sett det behovet utom när du har stora bildfiler eller BLOBar som man ibland kan vinna på att lägga som lösa filer p ådisken i stället för i databasen, men det är extrema undantag. Som jag inte ser något nytta med i ditt fall.

ingen aning om vilken backendteknologi du kör men om du vill bygga en chat och kör .NET så kika på SignalR. Här är en site byggd i SignalR http://jabbr.net/

Angående node.js kan du hitta en guide för precis din OS-version för att installera det. Att komma igång med websockets med node.js är också förvånansvärt lätt.

Använder du en push-teknologi istället så kommer en ny kommentar att pushas ut direkt till de andra i chatten och därmed inte behövas hämtas från databasen annat än om en ny användare ska få gammal chat-data (även här kan man eventuellt behålla en array i node.js som man skickar till nya klienter).

Måste du tvunget använda pull så skulle jag dock göra mig av med text-filen, du får en fördröjning på upp till 1.99s om reload och text-fil är max out of sync. Och om du vill halvera den fördröjningen genom att skriva alla uppdateringar direkt till text-filen så finns en viss risk att du korrumperar text-filen. Istället för text-filen borde du isåfall fundera över antingen en cache (memcache, apc etc) eller byta till en mycket lättare databas-lösning (se t ex Redis, Membase). Om du gör detta så kommer ditt val av pull att ge dig en första bottleneck i CPU eller RAM vid ditt dynamiska språk som PHP/Ruby/vadsom (förutsatt att du använder en bra webbserver).

Men som redan tidigare föreslagits, push är absolut bäst.

Visst, men i det här fallet är det bara idiotiskt att inte ha någon form av cache om det är många som ska komma åt samma innehåll. Du vill inte gå ned till databasen varje gång och fråga för en sån här sak.

Problemet med att använda t.ex. memcached är att du då måste wrappa memcached med ett serverside språk, t.ex. PHP. En textfil kan man komma åt direkt med jQuery i AJAX-anropet utan att behöva leta sig ned till något skriptspråk som ska köras varje gång. När man cachar vill man ju göra det så nära klienten som möjligt och minimera antalet lager i arkitekturen som requesten måste gå igenom för att hämta datan.

Men som sagt är push en bättre lösning, men också betydligt svårare och jobbigare att implementera. Så gör det enkelt för dig och kör du på AJAX + textfil till att börja med om du känner dig osäker på det där med push. Det går ju alltid att byta till push senare om behovet skulle finnas.

Databaser brukar normalt ta hand om cachening så det är mest naturligt att låta databasen hantera detta och inte lägga utvecklingstid på sånt som hanteras automatiskt.

Visst, men det är väldigt stor skillnad i prestanda och resursåtgång mellan query cache i databasen och en vettig applikationscache. Är det dessutom tal om många förfrågningar av exakta samma data finns det ju ingen anledning till att inte cacha. Det blir sällan mer än 2-3 rader kod extra per query som ska cachas så utvecklingstiden blir ju inte något att tala om.

Är serversidespråket problemet använder du C libbet direkt från webbservern (går alldeles utmärkt med lighttpd, apache, nginx och säkerligen många av ovanliga utmanarna). Om du kan skriva en textfil med jämna mellanrum kan du dock istället använda en cachande reverse proxy framför med samma expiry time istället och slippa gå mot webbservern alls.

Fördelen med memcache/http proxy är att de skalar utan problem från 1 server till 100, från 1 skrivning i sekunden till 100 skrivningar i sekunden och 100 anrop i sekunden till 10 000 anrop i sekunden. Ska du hantera detta med på ett bra sätt med 4234242 textfiler (när chatten även har privata konversationer en längre tid) i slutändan så har du nog skrivit en väldigt ineffektiv cachelösning som dessutom slukar serverns diskcache.

Och dessa fördelar får du med mindre jobb och krångel från första början... (förutsatt att du någonsin sett eller använt memcache kanske).

Två tekniskt bra lösningar absolut. Men det känns verkligen inte nödvändigt att göra det så komplicerat i det här fallet. Att komplexiteten i en applikation ska hållas så låg som möjligt är en bra tumregel. Man bör givetvis vara medveten om vad man väljer bort och se till att det går att byta ut den delen senare om behovet skulle uppstå. Ser man till att göra ett modulärt system med lösa kopplingar är det oftast bättre att välja den enklaste lösningen med kortast utvecklingstid först för att sedan kunna byta ut den komponenten när behovet uppstår.
Utifrån TS frågeställning här känns det inte som det finns några behov av en extremt högpresterande och skalbar lösning och då bör man nog hålla det så enkelt som möjligt, så länge man är medveten om alternativen och beredd på att göra om när man får prestandaproblem.
Räknar man med ett stort antal besökare direkt är det såklart en helt annan sak, men jag fick uppfattningen om att det inte var fallet här.

Om man har en vettig webbserver(t.ex. Nginx) så blir vinsten med att köra en reverse proxy framför väldigt liten när man bara ska serva statiskt innehåll som i det här fallet. Nu skulle det ju bara vara en chatt, och då hanterar diskcachen detta tillräckligt bra.

Att blanda in C för detta känns väldigt avlägset. Då är det mycket bättre att satsa på en pushlösning direkt i så fall.

Det går ju att använda memory table (mySQL)
På så vis undviker man skrivningar till disk vilket ofta är den största boven
SQLite kan vara ett alternativ det med, istället för textfiler

Jag håller med. Och text-filer för datalagring blir väldigt snabbt väldigt komplicerat (utrensning av gammal data, expires av cachad data, simultan skrivning, diskcache-nivåer, hämta delar av data, bearbeta datan från en struktuerad form etc etc är sådant man själv får lösa).

Nja, stor skillnad men små siffror (200%+).

Lite slarvigt uttryckt av mig. Du använder givetvis mod_cache/mod_memcache och dess ekvivalenter och behöver inte skriva en rad C utan har ett färdigt API att arbeta med i serverconfen.

Ja, fast inte i det här enkla användningsområdet.
Det är bara en fil så det är inte något stort behov av struktur. All skrivning hanteras ifrån ett ställe, annars är det bara läsningar. Diskcachen hanterar detta bra så länge det inte är några höga prestandakrav så borde det här vara fullt tillräckligt för TS, åtminstone till att börja med.