[PHP/JAVASCRIPT] Directe communicatie

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
OK, ik zit met het volgende probleem:
Ik ben bezig met het maken van een chat, ik wil hiervoor het liefst helemaal niets geen databaseverkeer gebruiken. De chat maakt gebruik van SmartIRC, een IRC-client voor PHP. SmartIRC moet blijven draaien zolang je een verbinding wilt blijven houden met IRC dus dit is een script wat op de achtergrond blijft draaien in een iframe (zonder page refresh dus).
De communicatie vanaf PHP naar javascript werkt al door een javascript functie te echoén gevolgd door een flush(); maar nu komt dus de bottleneck.. Hoe communiceer ik vanaf javascript rechtstreeks naar mijn PHP script? Tot nu toe de enige methode wat ik me kan bedenken is vanaf javascript een ander PHP script aan te roepen wat op zijn beurt hetgeen wat naar de PHP script gestuurd moet worden tijdelijk naar een tekstbestand schrijft die later dus door weer uit wordt gelezen door de PHP script die op de achtergrond draait.
Over het gebruik van een tekstbestand als een soort tussenbuffer heb ik zo mijn twijfels, is dit wel stabiel genoeg? zal dit qua performance wel goed presteren als er bijvoorbeeld 50+ mensen in de chat komen?
Wat ik verder nog had geprobeerd, wat naar mijn zeggen de beste oplossing zou zijn geweest, was het zetten van de cookie binnen javascript en dit vervolgens ophalen via PHP, maar de cookie wordt slechts éénmalig bij de pageload opgehaald. Wanhopig probeerde ik dit op te lossen door de cookie op te halen via 'unserialize(file_get_contents('http://localhost/chat/cookie.php'))' waarbij cookie.php dus 'echo serialize($_COOKIE);' bevatte. Dit werkte echter niet, ik kreeg een lege array terug terwijl er wel data in de cookie stond, zag ik hier iets over het hoofd, of..?
Natuurlijk zou je zeggen, 'doe het dan gewoon via de database' waar ik op mijn beurt weer terug zou komen op het performance gedeelte.. Als er 50+ mensen op de chat zitten en ik laat de PHP script om de seconde kijken of er nog nieuwe berichten zijn zit ik dus al op 50 queries per seconde, wat ik de server niet graag aandoe.
Wie kan me vertellen wat ik het beste kan doen..?

Acties:
  • 0 Henk 'm!

  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

De communicatie vanaf PHP naar javascript werkt al door een javascript functie te echoén gevolgd door een flush();
Ik kan me niet voorstellen dat de clientside pagina dan ueberhaupt nog responsive is, laat staan het invoeren van berichten mogelijk maakt. Afgezien van het probleem hoe je dat dan weer terug gaat sturen naar de server.
Ik zie hier een geknipte job voor Ajax: asynchrone requests op de achtergrond die met de server communiceren. Push-technieken gaan je nekken, al is het alleen maar omdat je uiteindelijk veel te veel open connecties blijft houden.

Het probleem met het aantal queries bij het opvragen van nieuwe berichten door clients kan je prima afvangen met memory-cacheing, maar 50 queries per seconde - zeker als het simpele queries zijn - is ook nog peanuts.

Intentionally left blank


Acties:
  • 0 Henk 'm!

  • FragFrog
  • Registratie: September 2001
  • Laatst online: 09:34
Kijk hier eens, een kant en klaar voorbeeld van hoe zoiets met PHP en AJAX kan staat er zelfs al gegeven.

Let wel, erg efficient ben je dan niet bezig, volgens mij kun je net zo goed dit direct door smartIRC laten afhandelen zonder tussenkomst van vage technieken / databases. Immers, je moet het smartIRC script toch laten draaien, waarom niet simpelweg een echo op nieuwe regels tekst met desnoods output buffering om te zorgen dat je pagina niet duizend lang wordt? Schrijf er een nette class voor en je bent zo klaar lijkt me.

[ Voor 28% gewijzigd door FragFrog op 12-03-2007 23:42 ]

[ Site ] [ twitch ] [ jijbuis ]


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
crisp schreef op maandag 12 maart 2007 @ 23:11:
Ik kan me niet voorstellen dat de clientside pagina dan ueberhaupt nog responsive is, laat staan het invoeren van berichten mogelijk maakt. Afgezien van het probleem hoe je dat dan weer terug gaat sturen naar de server.
Ik zie hier een geknipte job voor Ajax: asynchrone requests op de achtergrond die met de server communiceren. Push-technieken gaan je nekken, al is het alleen maar omdat je uiteindelijk veel te veel open connecties blijft houden.
de cliëntside wordt helemaal geladen en pas als hij helemaal klaar is met laden dan opent hij het PHP script op de achtergrond via een iframe. Dit werkt goed! http://82.75.60.196/chat
Van de technieken van Ajax ben ik redelijk op de hoogte, ik kan inderdaad bij het versturen van een bericht een ajaxrequest doen naar een script die het bericht vervolgens naar een tekstbestandje of de database stuurt en het PHP script wat op de achtergrond draait op zijn beurt om de zoveel tijd laten kijken of er nog nieuwe berichten zijn. Maar hier komt performance dus weer om de hoek kijken.

Hier even kort een kleine beschrijving van wat elk bestand doet:

index.html:
- hele chat layout
- alle javascriptaansturing
- onload: PHP script (connector.php) laden in een iframe voor de verbinding met IRC

connector.php
- moet zolang de gebruiker is ingelogd blijven draaien zonder een page-refresh
- onMessageReceived: echo <script>top.chat.sendMessage($from, $message); flush(); (bij wijze van)
dit is dus de communicatie tussen PHP en javascript en dit werkt goed

Het liefst wil ik de berichten via Javascript in een cookie of sessie krijgen en dit vervolgens via het PHP script ophalen. Hier is echter het probleem dat deze data geloof ik pas opnieuw wordt gezet bij een page-refresh, wat dus niet kan! Is er een alternatief om toch de nieuwe sessie/cookiedata op te halen?

Acties:
  • 0 Henk 'm!

Verwijderd

Bedenk voortaan gewoon eerst wat je precies wilt doen, en bedenk dan met welke programmeertaal / framework / libraries / etc. je dit het best voor elkaar kan krijgen. PHP is hier best ongeschikt voor. Een Java Servlet of ASP.NET Applicatie voor de serverkant zou al een hoop ellende schelen. Maar aan de andere kant is een Java Applet voor de clientkant ook niet verkeerd natuurlijk.

En wat is er nou helemaal het probleem als de client moet pollen om informatie? Dat is de defacto standaard op internet. Je begint over performance, terwijl je nog niet eens hebt vastgesteld of dat wel een probleem gaat worden.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Verwijderd schreef op dinsdag 13 maart 2007 @ 08:46:
Bedenk voortaan gewoon eerst wat je precies wilt doen, en bedenk dan met welke programmeertaal / framework / libraries / etc. je dit het best voor elkaar kan krijgen. PHP is hier best ongeschikt voor. Een Java Servlet of ASP.NET Applicatie voor de serverkant zou al een hoop ellende schelen. Maar aan de andere kant is een Java Applet voor de clientkant ook niet verkeerd natuurlijk.

En wat is er nou helemaal het probleem als de client moet pollen om informatie? Dat is de defacto standaard op internet. Je begint over performance, terwijl je nog niet eens hebt vastgesteld of dat wel een probleem gaat worden.
In ASP.NET zou ik het zelfde probleem hebben, Java moet appart geïnstalleerd worden en dat is niet de bedoeling. De chat moet door iedereen te gebruiken zijn zonder extra dingen te installeren.
Ik heb precies uitgelegd wat ik wil en ik heb bewust gekozen voor PHP, JA, ik weet dat het niet echt efficiënt is maar voor zover ik het kan zien zijn er geen alternatieven voor hetgeen wat ik wil bereiken.
Tot nu toe leg ik 90% van de performance neer bij de client-side en de IRC server zodat de server waar de chat op komt te draaien zo min mogelijk last heeft van de chat.
Ik heb dit topic gestart omdat ik een probleem heb, als je geen oplossing hebt moet je gewoon niet reageren en niet mijn ontwerpbeslissingen af gaan kaffen.
Pagina: 1