Web worker és Ajax?

Internet: PHP, CGI, stb.

Sziasztok!

Készítek egy böngészőben működő GUI-t, ahol JS-sel, JQuery-vel nagyszerűen tudok Ajax hívásokkal adatokat lekérni, feldolgozni, kitenni a képernyőre.

Gondom az, hogy mostanra már ~1000 körüli objektum adatait kell induláskor lekérdeznem majd ennyi darab egyedi képet kiszerkeszteni a képernyőre, ez pedig nagyban megakasztja az UI-t.

Ennek a helyzetnek a kezelésében kérném a tanácsotokat!

1. Lehetne csak annyi elemadatot lekérdezni, amennyi kifér a képernyőre, de még ez is érezhető
2. Tudom, hogy hány db elem kerül ki a képernyőre összesen, ezeket mind kirajzolom egy átmeneti kis képecskével (pl fekete négyzettel) és valahogy időben elosztva szépen lekérdeződnének az elemadatok és frissítődne a teljes képernyő

3. ????

Olvastam a web worker-ről, de abban az Ajax hívások nem ajánlottak.

Minden tippet, ötletet szívesen fogadok!

Üdv, Cözi

  • 880 megtekintés

( kiuka | 2017. 02. 23., cs – 17:48 )

ha jól értelek mit szeretnél, akkor lazy loadnak hívják a technikát amit keresel. a lényege hogy betöltesz x rekordot (ha ezeknek csak egy része látszik a képernyőn, akkor csak azokat töltöd be) és miután görget a látogató akkor jeleníted meg a többit (mint pl ahogy fb is csinálja).

amit neked át kell gondolnod: van-e értelme ajax-szal lekérni 1000 rekordot (ha nem lassít semmit, akkor van és görgetéskor csak a képeket tölteni amik kelleni fognak).

a webservice inkább arra való, hogy a kliensel folyamatos kapcsolatba tud állni (tehát pl realtime akarsz neki megjeleníteni adatot úgy, hogy ahhoz ne kelljen folyamatosan http kérésekkel bombázni a szervert, mert egy usernél még működőképes, de pl 1000-nél már kevésbé)

( Aadaam v | 2017. 02. 23., cs – 19:53 )

Vissza kell adni a CPU-nak a vezérlést időről időre. Az stimmel ugyanis hogy a "natúr" JS kód a UI szálon fut, de nem kell hogy egy vezérlési blokkban oldd meg az egészet, kiszervezheted.

Ezt két módon tudod megtenni:

1) a képek kirajzolását kirakod a vezérlési queue-ba, így beleférnek közbe az egérműveletek is

A legegyszerűbb kód erre:

for (i=0;i<1000;++i){
window.setTimeout(function(){draw(elem[i])},0);
}

Van ennél szofisztikáltabb is (pl. requestAnimationFrame), nézz utána.

2) az egész kirajzolással megbízol valami performance orientált frameworköt, ilyen pl a react.

( Hevi v | 2017. 02. 24., p – 02:00 )

Web worker miert nem ajanlott AJAX-ra? En ugy tudtam, hogy az a bongeszo "threadje" (ennyit tudok hallomasbol).

Szerk: mondjuk az AJAX az ugye alapbol Async, szoval lehet, hogy nem nem ajanlott, hanem felesleges?

Hát gondolom azt csinálja, hogy amikor megjön az Ajax akkor egy for-ciklussal elkezdi összeépíteni a HTML-t és addig áll a UI mert ez a main threaden fut.

A Workerekkel az lehet a baja hogy azok nem nyúlhatnak a DOM-hoz (a UI-t csak a UI thread kezelheti) és security okok miatt referencia szerint se adhtnak át, az meg ha bemegy egy bytecopy a JSON-ról majd stringbe kiköp egy 1000 ojjektes HTML-t az megint lassú lehet.

A UI threadben sokmindent meg lehet csinálni, annyi a lényeg, ne fuss egyszerre 30 milisecnél többet mert megakasztod a felületet.

Erre megoldás a setTimeout, mert az berakja a paraméterként kapott függvényt az event queue-ba, méghozzá úgy, hogy ha közben a felhasználó csinál valamit, azt berakja két setTimeout futás közé.

EDIT: persze azt is lehet hogy a worker hívja meg az ajaxot elés dolgozza fel, vagy szerveroldalról eleve HTML-be jön le, de próbáljuk a modern megoldások felé tolni... :)

( asch v | 2017. 02. 24., p – 09:21 )

Én mérnék, hogy mi akasztja meg? Az sem mindegy, hogy a CPU-t leterheli, úgy akad meg, vagy a hálózatra vár és azért. (Az ajax lekérdezés elvileg aszinkron, tehát nem akaszthatná meg, csak azáltal, hogy a CPU-t leterheli.)

Ha nem maga a lekérés, hanem az eredményből a HTML ojjektumok építése tart sokáig, akkor meg ott kell kotorászni optimalizálással. Én például egyszer írtam egy egyszerű játszós oldalt, ami párezer feliratot div-be létrehozott HTML-be, és egy JS-t, ami minden div-re feltett egy egérkezelőt. Ez a JS pár másodpercig 100%-on pörgette a CPU-t. Chromium és Firefox alatt jelentősen eltért az hogy pont mennyi. Ha beírtam az egérkezelőt a HTML-be, akkor gyorsabb lett. Ez csak egy játszós példa volt, nem vittem végig, a lényeg, hogy a sokszor ismétlődő részt kell mérni, és a leglassabban futó lépést másként csinálni valahogy.

Első körben én 1000 lekérés helyett 1-et csinálnék, ami paraméterként kapja meg, hogy 1000 ojjektumot kér a kliens. Persze ez sok programozás, csak akkor éri meg, ha a mérések alátámasztják.

A Web Worker hosszú _számítás_-ra való, tudtommal (da javítson, aki képben van) szerializált ojjektumokkal lehet kommunikálni vele, és a GUI-t nem érheti el. Ebben az esetben tehát nem használható.