Hajlítsa az állandó kapcsolatot
cURL állandó kapcsolat Új
Üdvözöljük!
Kétlem, hogy a kérdés közvetlenül a modxra vonatkozik, de hasznos lehet konzultálni az ismeretekkel.
2. A folyamat során a lekérdezés lassú végrehajtását tapasztalták: legfeljebb 5-10 másodpercig. Ezért találkoztam a cikken: Http kéri - mindannyian tévesszük a dolgot. Az a lényeg, hogy nem minden kapcsolatra van szükség kapcsolat létrehozására, ez komolyan akadályozza végrehajtását.
5. A hosszú végrehajtási idő miatt felmerül a kérdés. Tegyük fel, hogy 100 felhasználó elindítja ezt a részletet egy időben. Szerintem a szerver lefagy, nem teszi lehetővé a webhely alapvető funkcióinak elvégzését, vagy problémák merülnek fel a fórumon. Meg kell szerveznem a végrehajtási sorokat ezekre a kérésekre?
De mivel Én a legteljesebb 0, én szeretnék konzultálni, mielőtt kerékpárok a mankó.
Először olvassa el a phpDaemon-ot. majd az aljzatokról. és aztán sokáig gondolkodni.
Személy szerint én hasonló problémák megoldására a tárhely, nem lépett kapcsolatba PHP és elsajátított Python.
Köszönjük a tippet!
És vettem egy csomópontot (nodejs). De nem tud megbirkózni vele - túl sok árnyalattal rendelkezik a felkészületlen személy számára)
Noda minden bizonnyal jó, csak az én VPS nem fog megbirkózni. Terveket terveznek a helyszín újjáélesztéséről, és a mancsok eltávolításáról, amikor egy másik kiszolgálóra költöznek, a funkcionális funkció túlgördülésével azonban túl korai.
ez csak az én VPS nem képes Chait-t kezelni? Számomra a helyi gépen, Windows alatt a Nodov-folyamat, amely semmit sem tesz, 6,5 megabájt tárolót foglal el. Ez minden. Az Ön feladata (kérések fogadására és elküldésére) - nem sokkal többet. Minden vps'ka mester.
Általában az a feladat, mindezen táncokat keep-alive'om az curl'a php egyáltalán nincs értelme, ha egy ügyfél nem kell, hogy több, mint egy kérés egy harmadik fél által üzemeltetett webhely.
Tetszik - a felhasználó megnyitja az oldalt (vagy poszt-küld egy kérést, akkor nem számít), a kódrészletet a curl kérelmet intéz a külső webhely fogad és ad az ügyfélnek, és minden - php-process meghal. Amint azt mondják - "a php életét meghalni". Egy másik felhasználó számára külön php-folyamatot hoz létre, amely semmit sem tud az előző ügyfél korábbi curl-kéréséről, és nem tudja tudni. Ennek megfelelően a táncolás a "keep-alive" kifejezéssel értelmetlen.
Tehát ez az. Ha élni akarok, csak egy lehetőséget látok.
A csomópontban lévő webkiszolgáló emelkedik, amely például a 3000m-es portra figyeli a helyi szolgáltatást.
Ez a webszerver minden egyes kérelemhez az Ön adatait, amelyeket külföldre kell küldenie, ezt a kérést harmadik fél webhelyére küldi és válaszol. És a kódrészleted görbén keresztül elküldi a kéréseket erre a legtöbb localhostre: 3000. amely egy csomópontot vesz, és ebből válasz érkezik.
Ie a példában a lánc:
1. Az ügyfél adatokat küld;
2. a kódrészlet megkapja;
3. kódrészlet valamilyen robbantással küld valamit harmadik fél webhelyére;
4. göndör fogad egy választ harmadik féltől;
5. adatokat ad az ügyfélnek;
6. php haldoklik.
A példában a csomópontnak így fog kinézni:
1. Az ügyfél adatokat küld;
2. a kódrészlet megkapja;
3. küld valamit a csomópont egy göndör localhost: 3000 (és itt, Emlékeztetem Önöket, a csomópont nem lesz időveszteség a start-up és inicializálás az már fut, és proinitsializirovanna hogy minden úgy történik, amilyen gyorsan csak lehet.);
4. A csomópont megkapja az adatokat és elküldi azt egy harmadik fél webhelyére;
5. A csomópont adatokat visz egy harmadik fél webhelyéről, és el is adja;
6. görbe ez az eredmény;
7. adatokat ad az ügyfélnek;
8. php meghal, és a csomópont továbbra is él.
Tehát itt, sobssna, a kérdés - hol van a díj? És ez a leginkább helyes kérdés!
Amit elveszítünk:
- kérelmet küldeni a csomópontnak;
- választ kapni a csomóponttól;
- nézd meg? Php -, hogy a csomópont folyamat fut, és ha nem, akkor fut (vagy jöhet az aktuális verzió - közvetlen kérelmet a harmadik fél oldalon keresztül a göndör, nem kell időt tölteni a dob a csomópont).
És hogy van-e költsége a Keep-alive'a-díjának fedezésére, nagy kérdés.
Ennek csak akkor van értelme, ha sok egyidejű kapcsolat van. Ön esetében - azoknak a felhasználóknak a száma, akik egyidejűleg kéréseket küldnek a szolgáltatáson keresztül.
Valójában - ha a szolgáltatásaidban a felhasználók 30 másodpercnél ritkábban kérnek be kérdéseket, akkor ennek a sámánizmusnak egyáltalán nincs értelme. Miért? Próbáld kitalálni magad :-)
És mivel biztos vagy a VPS gyengeségében, akkor (valószínűleg) nem létezik ilyen számú egyidejű felhasználó a webhelyén, és az utolsó lehetőség a legvalószínűbb :) Bocsáss meg, összetévesztve a megosztottal. Számomra miatt valamiért V - virtuális - és gyenge.
Sharednél volt, hogy a közönség növekedésével átállt az UPU-ra.
A jelenlegi projekt szellemes, jóval jövedelmezőbb a közösség megtartása a fejlesztési szakaszban (valamiért nem tartom a számítógépemen). És van egy jim, hogy a promóció színpadán a megosztott fékek elindulnak.
Azonban, hagyja úgy, ahogy van, úgy tűnik, hogy nem annyira, és a hajó furcsa kb 3 másodperc lekérdezést, ami gyakorlatilag nem észrevehető nézi ajaxloader.
Azt tervezem, hogy erősebb hardverre váltok, de ugyanakkor nem akarok sietni.
Nem tudom, milyen vasat kell egy adott célra.
Forgalom elárasztott, egyszerre akár 50 ember is ül. És úgy tűnik számomra, hogy túl gyakran "üreges" egy külföldi fórum. Hogyan állíthatom be az időzítőt? vagy hogyan kell hívni.
És mégis úgy tűnik számomra, hogy világosan meg kell értenie, és nem szabad feltalálnia.) Vezessen egy naplót, hogy megértse, milyen gyakran történik a lekérdezések. Bár ostobán a fájlban írja le - ez nem számít.
Valójában ez így van, bejelentkezem 1 linkre, parsy oldalon a 2-ben, és elküldöm egy üzenetet 3-ra. Akkor írd be a cikket egy nyitott curl_init nevű csomóponttal. szükség szerint kérjen fórumot, és csak az összes kérés után zárja be a kapcsolatot curl_close (ne felejtse el a verbose-opciót a curl-ben).
Ismét meg kell javítanod - de ügyfeleid még várni egy válaszra egy nyílt fórumon. Ie a kiszolgáló egyszerre képes ellenállni 50 embernek (de lehet, hogy a csúcsterhelés pillanatában és a kiszolgáló nem tudja megbirkózni?), de a harmadik fél fóruma ellenáll egy ilyen terhelésnek?
Itt azt hiszem, ahogyan megérted, nem megfelelő - mindent nyomon kell követni annak érdekében, hogy levonjunk néhány következtetést.