[secag]

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?

[P3N]

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.

[Conny Westh]

Ursprungligen postat av secag

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?

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.

[Clarence]

Ursprungligen postat av secag

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?

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.

[pelmered]

Ursprungligen postat av ConnyWesth

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.

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.

Ursprungligen postat av Clarence

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

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.

[Conny Westh]

Ursprungligen postat av ITisGood.se

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.

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.

[pelmered]

Ursprungligen postat av ConnyWesth

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.

[Clarence]

Ursprungligen postat av ITisGood.se

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.

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

[pelmered]

Ursprungligen postat av Clarence

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

[Clarence]

Ursprungligen postat av ITisGood.se

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.

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

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.

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

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.

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.