[json/ajax] Hoe zwaar zijn de calls/posts

[Douweegbertje]

Ik vraag mij af hoe zwaar bepaalde GET/POST en w/e commands zijn voor zowel de client als de server. Voor de server weet ik dat ongeveer wel, omdat ik ervaring heb met websites die veel hits krijgen maar wellicht dat ik iets over het hoofd zie.

In elk geval ben ik dus bezig met een app, waarbij ik niet wil dat hij alles zelf gaat doen ivm met tampering oftewel "cheaten". Als ik bepaalde dingen serverside doe is dat dus zo goed als opgelost.
Nu heb ik wel de optie om het op 2 manieren te doen.

De eerste manier is om bij elke actie, laten we zeggen "slaan op een beest" een GET request te doen om vervolgens terug te krijgen voor hoeveel schade de client hem heeft geslagen. Dit kan dus best zijn dat er voor 10 seconden lang elke seconden 1 request komt.

Is dit nu wenselijk, en wat doet dit met de performance? Vanuit de client word geen data verstuurd, los van een token in de header. Tis immers ook een GET. De server returned wel een JSON met maar ~ 2-3 keys oftewel bar weinig data.

Voor dat iedereen middeleeuws gaat, ben ik mij ervan bewust dat er andere mogelijkheden zijn zoals sockets e.d. om dit soort "verkeer" beter af te handelen, echter wil ik het op deze manier sowieso gaan doen. Mocht dit nou echt enorme slecht zijn voor de client qua performance dan heb ik altijd de optie om eens in de ~10 seconden een call te gaan doen. Dit is in zekere zin ook prima alleen moet dan ook een deel op de client gegeneerd worden, iets wat ik het liefst zo min mogelijk doe.

[leuk_he]

Meten is weten. zonder platform, en doel hardware is daar niks zinnigs over te zeggen.

Maar hoe dan ook, wil je denk ik OOK de data op je client voorspellen bij een spel. Soms is er immers wat lag. Dan wil je niet vele seconden wachten tot het netwerk zich hersteld heeft. Ook weet je niet wat je bandbreedte is. als die bij sommige erg beperkt is wil je e daarop je netwerkwerk verkeer flexibel kunnen aanpassen.

[Gomez12]

Voor de server is een ajax call gewoon een request net zoals alle andere requests.
En voor de client geldt in basis hetzelfde.

Dus oftewel als jij je server-kant onder de 100 ms houdt gaat alles goed.
En aan de client--kant is het voornamelijk afhankelijk van wat je allemaal doet voordat je de request stuurt (haal jij 50 variabelen op links en rechts, dan kost dat tijd, ga jij het omzetten naar json dan kost dat tijd, heb je een framework als jquery erboven zitten dan kost een heel klein beetje tijd)

In wezen zijn de client en de server perfect uitgerust voor de requests zelf (ze zijn er grotendeels voor gebouwd), alleen over het algemeen verlies je 99,999% van de (beinvloedbare, want je hebt ook nog netwerk lag etc) tijd in je eigen code.

[Ramon]

Of dit wel of niet "slecht" is hangt vooral af van je eisen aan de responsiviteit die je wenst van je app, de hoeveelheid data die heen en weer moet en hoeveel requests je verwacht te gaan doen, dus dat kunnen wij niet voor je beantwoorden. Er zit een hele hoop overhead aan http requests (headers, cookies e.d.) die je niet hebt met websockets dus als je vraagt of http requests efficient zijn tov websockets dan nee.

Overigens maakt een online spel zoals browserquest gebruik van Websockets, dat zal niet zonder reden zijn .

=edit=
Dit is een interessante pagina: http://stackoverflow.com/...bsockets-protocol-vs-http

[ Voor 9% gewijzigd door Ramon op 31-05-2014 20:23 ]

[Douweegbertje]

Ramon schreef op zaterdag 31 mei 2014 @ 20:09:
Of dit wel of niet "slecht" is hangt vooral af van je eisen aan de responsiviteit die je wenst van je app, de hoeveelheid data die heen en weer moet en hoeveel requests je verwacht te gaan doen, dus dat kunnen wij niet voor je beantwoorden. Er zit een hele hoop overhead aan http requests (headers, cookies e.d.) die je niet hebt met websockets dus als je vraagt of http requests efficient zijn tov websockets dan nee.

Overigens maakt een online spel zoals browserquest gebruik van Websockets, dat zal niet zonder reden zijn .

=edit=
Dit is een interessante pagina: http://stackoverflow.com/...bsockets-protocol-vs-http

Klopt, is ook leuk. Heb het even verder opgezocht: https://github.com/mozilla/BrowserQuest/tree/master/client

Punt is, dit werkt niet met PHP, en dat wilde ik eigenlijk wel.

Overigens de rede dat het zo gedaan is met sockets is puur om de rede dat je via een andere manier geen data terug kan sturen. Iets wat ik ook niet nodig heb, aangezien ik er toch steeds om ga vragen

Gomez12 schreef op zaterdag 31 mei 2014 @ 19:05:
Voor de server is een ajax call gewoon een request net zoals alle andere requests.
En voor de client geldt in basis hetzelfde.

Dus oftewel als jij je server-kant onder de 100 ms houdt gaat alles goed.
En aan de client--kant is het voornamelijk afhankelijk van wat je allemaal doet voordat je de request stuurt (haal jij 50 variabelen op links en rechts, dan kost dat tijd, ga jij het omzetten naar json dan kost dat tijd, heb je een framework als jquery erboven zitten dan kost een heel klein beetje tijd)

In wezen zijn de client en de server perfect uitgerust voor de requests zelf (ze zijn er grotendeels voor gebouwd), alleen over het algemeen verlies je 99,999% van de (beinvloedbare, want je hebt ook nog netwerk lag etc) tijd in je eigen code.

Het betreft zo'n ~1 request per seconden met minimale data waarbij er serverside niet veel word gedaan. Maar volgens mij of dit nu met een socket of niet is, maakt dat niets uit. Of je nou moet wachten op je return data van je socket of van json data maakt dan natuurlijk niets uit (correct me if wrong ).

[ Voor 41% gewijzigd door Douweegbertje op 31-05-2014 23:05 ]

[Ramon]

Douweegbertje schreef op zaterdag 31 mei 2014 @ 22:40:
[...]

Punt is, dit werkt niet met PHP, en dat wilde ik eigenlijk wel.

Overigens de rede dat het zo gedaan is met sockets is puur om de rede dat je via een andere manier geen data terug kan sturen. Iets wat ik ook niet nodig heb, aangezien ik er toch steeds om ga vragen

Je moet je doel niet afstemmen aan de techniek die je beschikbaar hebt, maar de techniek afstemmen aan het doel wat je wil bereiken

Het betreft zo'n ~1 request per seconden met minimale data waarbij er serverside niet veel word gedaan. Maar volgens mij of dit nu met een socket of niet is, maakt dat niets uit. Of je nou moet wachten op je return data van je socket of van json data maakt dan natuurlijk niets uit (correct me if wrong ).

Het probleem zit hem in de overhead van een http request. Kijk bijvoorbeeld naar de onderstaande voorbeelden:

Een HTTP request:

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

Een HTTP response:

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

Dit is data die bij iedere http request heen en weer gestuurd wordt, daarnaast moet die data verwerkt worden en moet er een nieuwe connectie worden opgezet. Bij websockets zet je één keer een verbinding op, en kan je daarna gewoon data heen en weer sturen. Gewoon veel efficienter als je het hebt over spellen of chat, bijvoorbeeld.

[ Voor 61% gewijzigd door Ramon op 01-06-2014 16:44 ]

[Douweegbertje]

Je eerste zin is overigens een beetje vanuit een 100% programmeurs kant gesproken. Soms moet je het maar doen met wat je hebt, en 'even' een andere backend/server taal leren omdat je 1 action per seconden te veel vind voor iets is een overweging, geen feit/eis.
Je hebt het over een chat/game, waarbij er soms om de 200ms iets word verstuurd. Dan is een "normale" GET/POST w/e om de 1 seconden naar mijn mening even effectief, behalve dat ik niets extra's hoef te leren.

In elk geval heb ik wel veel aan je reactie, en ben ik het aan het overwegen om wat extra's erbij te leren (node.js).

[TheNephilim]

Als een speler op een knopje drukt en met AJAX wil je met een backend communiceren en de data verwerken zul je niet meteen met een probleem zitten. Ik denk dat je probleem voornamelijk gaat zijn dat je (misschien) de resultaten van die actie aan andere spelers wil laten zien.

Ik weet niet precies wat je maakt, maar je moet erg je best doen om performance problemen te krijgen met gewoon interactie van client <-> server. Pas bij client <-> server <-> client/client/client/client/... ga je echt websockets nodig hebben.

[Douweegbertje]

Dat is ook echt niet het geval zoals volgens mij(?) in mijn openingspost ook staat.