Melyik a szerver kínzás? A hosszan futó szkript, vagy a rövid ideig, de sokszor ismétlődő?
Sziasztok!
Azért írtam ebbe a topicba, mert a kérdés AJAX technológiához kapcsolódik. Volt az elmúlt időszakban néhány olyan téma, ami AJAX-os tartalom frissítéssel foglalkozott és többször elhangzott az 1-2-5 másodperces frissítés.
Felmerült ezzel kapcsolatban bennem egy kérdés!
Tételezzük fel, hogy folyamatosan friss adatra van szükség kliensen. Mondjuk egy folyamat állapot mutatója. (pl.: 5000 levél elküldése, de úgy, hogy látható legyen a folyamat: összes/elküldve)
off: Nem levelezési eljárást feszegetek, csak ez a legéletszerűbb példa ami eszembe jutott!
Melyik a jobb megoldás:
Ha ven egy js rutin (alább sematikusan), azt mondani a szervernek AJAX-szal, kezdje el csinálni a melót, az elvégzendő 5000 feladatból hajtson végre 100-at, majd térjen vissza a fennmaradó értékkel, hogy kliens lássa mennyi van még vissza (pl.: első 100 után 4900, aztán 4800 stb.). Megérkezik a response, frissül az állapotjelző és jöhet a következő 100. Vagy ugyan ez, csak egyesével!?Kíváncsi vagyok a véleményetekre!
s_volenszki
■ Azért írtam ebbe a topicba, mert a kérdés AJAX technológiához kapcsolódik. Volt az elmúlt időszakban néhány olyan téma, ami AJAX-os tartalom frissítéssel foglalkozott és többször elhangzott az 1-2-5 másodperces frissítés.
Felmerült ezzel kapcsolatban bennem egy kérdés!
Tételezzük fel, hogy folyamatosan friss adatra van szükség kliensen. Mondjuk egy folyamat állapot mutatója. (pl.: 5000 levél elküldése, de úgy, hogy látható legyen a folyamat: összes/elküldve)
off: Nem levelezési eljárást feszegetek, csak ez a legéletszerűbb példa ami eszembe jutott!
Melyik a jobb megoldás:
Ha ven egy js rutin (alább sematikusan), azt mondani a szervernek AJAX-szal, kezdje el csinálni a melót, az elvégzendő 5000 feladatból hajtson végre 100-at, majd térjen vissza a fennmaradó értékkel, hogy kliens lássa mennyi van még vissza (pl.: első 100 után 4900, aztán 4800 stb.). Megérkezik a response, frissül az állapotjelző és jöhet a következő 100. Vagy ugyan ez, csak egyesével!?
...
var amount = 100;
//var amount = 1; ?????
function Work(){
AjaxRequest = new Ajax.Request('working.php',
{
method:'post',
parameters: {amount:amount},
onSuccess: function(transport){LetsWork(transport.responseText);}
}
);
}
function LetsWork(rest){
UpdateProgress(rest);
if(rest > 0)
{
Work();
}
}
Work();
...
s_volenszki
Szerintem
Szerintem ha nem életbevágóan fontos, hogy pontosan a 83. vagy 84.-nél tart, célszerűbb nagyobb csoportokra bontani, kevesebb forgalmat generál, és a szervernek se kell állandóan küldözgetni a kéréseket.
nem életszerű
Sejtettem, hogy a levél küldés elviszi a témát...
Sejtettem, hogy a levél küldés elviszi a témát. Mivel ez nem egy valós alkalmazással szemben támasztott igény, ezért gondolkoznom kell egy "életszerűbb" példán!
s_voleszki
szerk:
Ne az elvégzendő feladat legyen, ami meghatározza a témával kapcsolatos véleményeket, hanem az elvégzés módja! Ja! És fontos a kapcsolat a kliensel!
általános hiba
az eredeti kérdésre: feladatfüggő. a legjobb ha nem is használsz ajaxot. ha mégis használsz, akkor minél sűrűbben indítasz egy kérést, annál több hálózati forgalmat generálsz és annál több munkát végez a szerver, ez elég egyértelmű. a munkától függ, hogy mennyire kell, hogy friss legyen az adat a böngésződben és ezért mennyi erőforrást vagy hajlandó áldozni.
Nem mondom, hogy...
Ha egy kliens által indított folyamat állandó felügyeletet igényel, az dönti el az alkalmazott eljárás ésszerűségét, hogy mennyire fontos a klienshez érkező információ, azaz mekkora időbeli tolerancia van az adatok feldolgozása és a szükséges beavatkozás között!
Amikor feltettem a kérdést nem gondoltam volna, hogy a teljesítmény és hatékonyság fogalma ennyire általános érvényű. Mindenre igaz!
s_volenszki
attól függ
A példádnál maradva én úgy oldanám meg, hogy a szerver egyesével csinálja, és beállít egy változót, hogy hol jár a folyamatban, amit a kliens oldalról 3 másodpercenként lekérdeznék ajax-szal.
Ha még kifinomultabban szeretnéd megjeleníteni, akkor a kliens oldalon számolnék egy csúsztatott átlagot, amivel előre kalkulálnám, hogy kb hogy áll a folyamat teljesülése és mondjuk egy kis letöltési csíkkal és egy % megjelenítésével kiírnám. Persze ez nem lesz pontos, de aki már másolt winen egyik wincsiről a másikra az tudja, hogy egy ilyen csík mennyire szokott pontos lenni :)
De érdekes a kérdés felvetés én is kíváncsi vagyok mit mondanak mások. Érdemes lenne írni rá egy tesztet és lemérni.
Párhuzamos vagy soros végrehajtás?!
Igen! Ez volt a másik alternatíva a gondolattal kapcsolatban. Ne soros, egymástól függő, hanem párhuzamos, egymástól független végrehajtás.
Induljon el a végrehajtó rutin szerveren, és folyamatosan preparáljon egy állapotjelzőt, ami párhuzamosan kliens oldalról kiolvasható.
Tekintsük csak át:
Ha sorosan zajlik a folyamat, akkor egy "ciklusban" lesz ugye egy AJAX végrehajtó kérés, egy php futás ami végrehajt és egy response kliensre amikor az egy végrehajtás teljesül.
Ha párhuzamosan (ha már elindult a folyamat és egy php folyamatosan tekeri a végrehajtó rutint), akkor lesz egy AJAX kérés, lesz egy php ami tájékoztat az állapotról és egy response az állapottal.
Akkor ebből most melyik a szerver barátabb?
s_volenszki
Párhuzamos, de hogyan?
Én is hasonló megoldásban gondolkodom (mármint a párhuzamos végrehajtásban és kijelzésben), csak azt az egyet nem tudom, miként tudnám a végrehajtó modult (ami egy PHP függvény) úgy elindítani a szerveren, hogy az "leváljon" a hívó folyamatról, hogy így aztán vele párhuzamosan le tudjam kérdezni az állapotát.
Tudom, linuxon van a fork, meg exec, meg ilyenek, de
1. szeretnék platformfüggetlen megoldást alkalmazni
2. nem tudom, hogy lehet ezeket PHP-ből hívni
Szóval a fenti párhuzamosítási elv tetszik, de a gyakorlati megvalósítás részleteire vagyok kiváncsi!
Norbi
ne bonyolítsd
Optimalizálás
Tegyük fel, hogy a szerver 10ms alatt elintezi egy levél kiküldését. De 10ms amig a kliens kérése eljut a szerverhez és 10ms amíg vissza megy. Ekkor 30ms alatt küldettél ki vele egy levelet. Így 1mp alatt 33 levelet tudsz kikuldeni.
- Cserébe a szervered 33*20ms-ig tud mással foglalkozni.
- A kijelzési pontosságod 1 levél.
Ha 100 levelenként hívod, akkor 10ms + 10*100 + 10ms durván 1mp alatt 100 levelet küldtél ki.
Ekkor a kijelzési pontosságod 100 ami 5000 levelnél ha %-ban írnád ki akkor 2%-os ugrásokat jelentene.
Növelheted a kijelzés pontosságát, hogy méred az időt kliens oldalon és becsülve az eddigi eredményekből fél idben is lépteted a % számlálót.
Valójában a második esetben az 1 levélre jutó szerver terhelés mégkisebb lesz mint az első esetben, mert nem kell a szervernek a hívás fogadással, php értelmezéssel stb feladatokat minden alkalammal megcsinálni.
Szerveroldalon
Én mindent php-ben csinálnék, ami mondjuk ha a kész feladatok százaléka változott egyszerűen:
(Mellesleg mindenféle hostingok kényszerítettek engem is kliens-alapú megoldásokra, amikor nem voltak hajlandók emelni a time limitet... A sok kérés és az újra meg újra való PHP betöltés túltesz a valódi munka követelte erőforrásokon.)