Skalerbar chat

Tags:    php

Hej igen folkens ;)

Jeg har på det seneste siddet og knækket hovedet med en hjernevrider jeg har påkastet mig selv. Jeg har da selvfølgelig sat mig for at skrive en AJAX chat med PHP ! :)

Indtil nu lader jeg den blot opdatere hvert 2 sekund og når brugeren indsender en besked.

Jeg har så hurtigt ramt en mur. Jeg har valgt at bruge MySQL som backend da det umiddelbart virkede logisk.

Lad os starte med "showchat.php" :
Jeg har en query i toppen der opdaterer den nuværende loggede ind brugers "latestactive" field, så brugeren kan blive logget ud efter 10 sekunders inaktivitet (Det er jo en chat og der skal være fart på.) og så ellers så henter den de seneste 25 beskeder ud fra chatten og returnerer, hvis en session (chat-count) ikke er sat. Og derefter sætter den sessionen til det sidste id den spyttede ud, så næste gang behøves den kun tage beskeder derfra.
- Den opdaterer hvert 2. sekund.

Så har jeg også en "showusers.php"
Den laver noget lignende, den henter bare alle brugere hvor "login" er lige med "true" og så løber dem dem igennem og checker om hver brugers lastactive er inden for 10 sekunder, hvis de er bliver de printet, ellers bliver deres login = false.
- kører hvert 10 sek.



Jeg er ret sikker på jeg har kvajet mig i stor stil mange steder, men det er mit første forsøg på en skalerbar ajax applikation, så bær over med mig :S. Jeg kan trække 20 - 30 brugere før vi rammer 100% cpu på en 1,8GHz single core maskine med 1GB ram (lighttpd og MySQL på FreeBSD)

Jeg er allerede ret sikker på sessions trækker en del tid pga de bruger disken, og at mysql queriesne måske kan optimeres en smule. Jeg har også mistanke til min måde at vise brugere ikke er den bedste, men der er foreslag velkomne. Caching har jeg ikke rigtigt set som en mulighed fordi at en chat (sigter efter 100 bruger mindst på den her maskine - 200 - 300 på produktionsserveren) og det vil gå rigtigt stærkt med så mange i et rum.


Alt kritik og eventuelt hjælp, erfaring, opfordringer osv. er velkomne. Det er bare et hobby projekt det her, men skalerbarhed er altid rart at have lidt erfaring med :P





Det kan nok klares med HTTP polling, men han opnår 100% cpu ved 30 brugere.


Det er det jeg siger må betyde at der laves noget "uhensigtsmæssigt". Det vil svare til at ens webside kun kunne have 30 samtidige brugere. Tingene bliver hurtigt overkomplicerede.

Skifte sprog = skifte hammer. For nu at blive i name dropping, så skrev Greg Larman, at kun ca 15% af et projekt er implementering, resten er afklaring design, arkitektur osv. Så jeg vil stadig sige at det er "forholdsvist" meget billigere at udskifte sproget end at skifte alt det andet (design arkitektur osv.) - eksempelvis er der mange virksomheder der omlægger deres systemer til .NET/Java - det er typisk fordi det kan betale sig.


Ja, det kan ofte godt betale sig at skifte arkitektur, men kun hvis det er dyrere, at bibeholde den nuværende.
F.eks. den her: http://www.version2.dk/artikel/17392-drop-mainframes-i-det-offentlige-og-spar-300-millioner-kroner

At gå fra mainframe til x84 er i DEN grad en arkitektonisk ændring og én af de dyrere af slagsen, men det kan åbenbart betale sig i det her tilfælde.

At skrive komogvind.dk's kode om fra PHP til ASP/.Net ville bestemt ikke kunne betale sig.

Der ligger andet end syntax i et sprog. Der er hele runtime miljøet, applikations servere, tilgængelige frameworks og meget andet. Derfor er det meget vigtigt at få rigtigt og dermed en del af arkitekturen.
Ét sprog er måske bedre optimeret end et andet, som så til gengæld tilbyder nogle features, som er "kringlede" i det første. Og hvis disse features er meget vigtige, så er det første sprog måske det rigtige...medmindre performance også er meget vigtigt.

Igen for lige at bringe komogvind.dk ind i sagen, så bruger jeg Java, PHP, JavaScript, Ruby, C og Bash (jeg har sikkert glemt et par stykker) forskellige steder til forskellige opgaver. Sproget er valgt til opgaven, og det ville sikkert være arkitektonisk forkert at skifte min C kode ud med JavaScript.



http://dev.w3.org/html5/websockets/

Tag skridtet videre, eksperimentér.



http://dev.w3.org/html5/websockets/

Tag skridtet videre, eksperimentér.


Jeg har leget med det. Ganske interessant, men under motorhjælmen er det HTTP kald...ganske vist med noget HTTP push/long poll.
Men det er vist meningen, at næste version af JavaScript får ægte sockets.



Og der er opdaget en fejl i spec, så det er egentlig disabled pr. default i de fleste browsere der understøtter det. Det var vel egentlig nok mest for at sige, at du også bare kunne prøve noget helt nyt, i stedet for at bruge vante metoder.

Men ja, JavaScript med sockets lyder afsindigt spændende! ECMAScript 5, får vist også bedre OOP muligheder, jeg glæder mig som et lille barn.. :)



Indlæg senest redigeret d. 22.12.2010 17:49 af Bruger #11328
At gå fra mainframe til x84 er i DEN grad en arkitektonisk ændring og én af de dyrere af slagsen, men det kan åbenbart betale sig i det her tilfælde.


NEJ! Det er en teknisk ændring, og har intet med arkitektur at gøre. Software arkitektur er eksempelvis om du benytter et repository pattern til at tilgå dine objekter, om du har et Data Access Layer (DAL), hvilke elementer der er prioriteret højt i din software.

Der er nogle klassiske begreber omkring software arkitektur som eksempelvis:

* Lagdeling og indkapsling
* 3-lags arkitektur
* 5 lags arkitektur
* Objektorientering
* Client-servier (system arkitektur)

Fælles for alle disse er at de ikke tager stilling til hardware eller sprog. Det er arkitekturen af softwaren, det vil sige dens opbygning der tales om.

Du blander begreberne sammen, sprog er værktøjer til at implementere arkitekturen med, maskinerne er system deployment. Arkitektur er overordnet system design.

Sommerville omkring arkitektur (grundbog i software udvikling): "Architectural Design is concerned with understanding how a system should be organized and designing the overall structure of that system"




Vi bliver aldrig enige, så jeg lader den ligge.



Der fik jeg dagens smil :)
(13 nye indlæg - i en tråd.)


Jeg overgår i øvrigt til Flash med en .NET klient som jeg havde snakket om (har demoen kørende her), så hvis det kan slå lidt koldt vand i blodet hos nogle af parterne, så smider jeg hele koden ind her. Også selvom det sikkert koster mig min ære :$

Index.php
Fold kodeboks ind/udKode 


Login.php
Fold kodeboks ind/udKode 


Post.php
Fold kodeboks ind/udKode 


clientswindow.php
Fold kodeboks ind/udKode 


Chatwindow.php
Fold kodeboks ind/udKode 



Jeg har udeladt db_open og db_close.. Der er ikke noget i dem andet end at åbne databasen, sætte utf-8 og så har db_open en php funktion til at lave en string MySQL sikker.




Tror ikke at det er helt optimalt det setup. Det der er blevet foreslået igennem hele tråden er følgende:

En HTML side, med dit DOM træ. Et javascript der periodisk kalder din Flash/Java chat klient, og henter output, som du så renderer i DOM træet, vha. JavaScript.

Fold kodeboks ind/udKode 


EDIT: De smukke pile, repræsentere dataoverføring. Fra klient til server og omvendt, snakker vi TCP Sockets.



Indlæg senest redigeret d. 23.12.2010 20:59 af Bruger #11328
Tror ikke at det er helt optimalt det setup. Det der er blevet foreslået igennem hele tråden er følgende:

En HTML side, med dit DOM træ. Et javascript der periodisk kalder din Flash/Java chat klient, og henter output, som du så renderer i DOM træet, vha. JavaScript.

Fold kodeboks ind/udKode 


EDIT: De smukke pile, repræsentere dataoverføring. Fra klient til server og omvendt, snakker vi TCP Sockets.



Var det rettet mod mig?

For det er jo netop det jeg lige skrev at jeg gjorde. Det der var min originale kode, nu har jeg alligevel ikke noget at bruge den til, så den kunne lige så godt komme til almen nedgørelse :)



Ah.



t