ugrás a tartalomhoz

PHP multithread

N0r3i · 2007. Ápr. 5. (Cs), 09.49
Sziasztok!

Van egy PHP/MySQL oldalam, amin szeretnék a "háttérben" kommunikálni egy másik szerverrel. A kommunikáció rendben működik, de nem tudom, hogyan tudnám a háttérbe kényszeríteni a folyamatot.

A folyamat: felhasználó beküldi a megfelelő adatokat a weblapon, PHP beírja a helyi adatbázisba. Ez ismétlődhet rövid időn belül akár többször is. Az így begyűjtött adatoknak egy részét szeretném átküldeni egy másik szerverre, de nem szükséges, hogy a kommunikáció azonnal megtörténjen, sőt, erősen ellenjavalt, hogy a kommunikáció blokkolja az aktuális műveletet. Annál is inkább, mivel előfordulhat, hogy akkor rögtön nem is sikerül az adatátvitel.

Van erre valami elegáns módszer?

Köszi:
N0r3i
 
1

cron?

gex · 2007. Ápr. 5. (Cs), 10.00
cronból óránként elindítod a kommunikációt?
2

trigger

city99 · 2007. Ápr. 5. (Cs), 11.32
file szintu triggerrel mukodik nalunk.
Erdekes hogy ez a cron tema mindig felmerul ilyenkor pedig szerintem az idozitett futattas es az igeny szerinti futttas nem azonos.
3

Hogyan?

N0r3i · 2007. Ápr. 5. (Cs), 11.37
Ez érdekelne. Pontosan hogy is van ez?
Ha nem a saját szerveremen használom, van esélyem ilyesmit kérni?
5

rendszergazdi

city99 · 2007. Ápr. 5. (Cs), 11.56
Csinalsz egy filet amibe a belirsz barmit is.
A rendszer meg ha eszre veszi a file valtozasat meghiva a mit beallitasz neki, jelen esetben egy masik php sciptet ami majd kommunikal meg teszi a dolgat a "hatterbe" . Igy a felhasznalo altal hasznalt script csak a db-be tur ill a filebe rak bele valamit. (ez a filet mi meg egyfajta lognak is hasznaljuk. Beleirunk egy datumot meg akar user id-t igy latjhato hogy ki mikor csinalt valamit)

Ha nem sajat szervered van akkor meg kell kerdezni a redszergazdajat hogy van erre lehtoseg vagy sem. (gyanitom a nem valasz fog erkezni:) es akkor marad a cron, ha az lehetseges)
8

Juj

janoszen · 2007. Ápr. 5. (Cs), 12.28
Ez ugye, nem úgy akar működni, hogy állandóan nézegeti a fájl változás dátumát? Az elég csúnya lenne. Ennek mondjuk jól megoldva úgy kellene működnie, hogy rendszerüzenetként megy a ping a feldolgozónak... már csak azért is, mert lehet, hogy egy írás kellős közepében vagy és úgy olvasol belőle... a flock meg PHP-ben nem megbízható:

On some operating systems flock() is implemented at the process level. When using a multithreaded server API like ISAPI you may not be able to rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance!
13

nem

city99 · 2007. Ápr. 5. (Cs), 13.59
file system szintu.
Teljesen fuggetlen a lockolastol. linearis az ugy:
-php script beleir
-oprendszer filesystem eszreveszi hogy valtozas van hivja masik script

kozben meg 20x beirahat mindenki abszolut nem erdekel senkit mert a feldolgozando adat db-be van.
4

egyszerű

gex · 2007. Ápr. 5. (Cs), 11.41
mivel elég egyszerű a cron használata, és nem tudom milyen szinten van az illető akinek mondom, kiindulási alapnak jó lehet.
sokszor felmerül a cron használata ez igaz, viszont az esetek 90%-ában a kérdező nem tudja mi az. magyarázd el neki a triggert. :]
6

Tudom mi a cron

N0r3i · 2007. Ápr. 5. (Cs), 12.00
Valóban nem sok mindent mondtam magamról - nem gondoltam, hogy ez is fontos lehet -, de a cron-t elég jól ismerem és használni is fogom.
Szerintem sem arra való, amit fent leírtam, ui. nem tudom, hogy mikor fog bekövetkezni egy esemény. Óránként futtatva egy kicsit lassú lesz a frissítés, 5 percenként futtatva meg sok felesleges futás lesz.

Szóval jobban tetszene a trigger amit - bár tudom hogy mit jelent - még sosem használtam, nem találkoztam vele, és azt sem tudom, hogy egy nem általam felügyelt szerveren használhatok-e.
7

nem rólad van szó

gex · 2007. Ápr. 5. (Cs), 12.02
itt nem konkrétan rólad volt szó, csak elmondtam, miért vetettem fel a cront, és miért szokott általában előkerülni.

szerk: nem magadról kellett volna elmondani valamit, hanem a szerverről (tiéd-e, oprendszer, stb), te is látod mennyi függ például attól, milyen jogaid vannak.
9

Más megoldás?

N0r3i · 2007. Ápr. 5. (Cs), 12.36
Köszönöm szépen az eddigi tippeket, a rendszergazdát meg fogom kérdezni a file triggerről.

Azért lenne még egy kérdésem a témában: találtam egy francia nyelvű oldalt a php multithreading témában, ami - ha jól gondolom - szintén megoldás lehetne a problémámra, csak sajnos nem tudok franciául, így egy kukkot sem értek a leírtakból :-(

Néztem a skeletont is, amit sajnos szintén nem értek :-((

Szerintetek arra van esély, hogy ez működjön? És hogyan? Többek között az a baj, hogy nem látok benne olyan részt, ahova az én kódomat kellene tennem, olyan függvényt, ami hívnom kellene ahhoz, hogy elinduljon egy új thread. Erre van ötletetek?

Most csak Windows-on tudnám kipróbálni (meg is tettem...) de eleve úgy kezdi, hogy nem fog műküdni, és tényleg ;-) Az éles üzem viszont linuxon lesz, szóval esélyes lehet.
10

process control functions

gex · 2007. Ápr. 5. (Cs), 12.51
a francia oldalon erről van szó.
11

Multithreaded

janoszen · 2007. Ápr. 5. (Cs), 13.16
Azért a multithread programoknak nagyon komoly követelményei vannak. Pl az, hogy ne hagyj magad után zombi process-t, vagy a kettő szinkronizációja, stb. Nem tudom, mennyire hibatoleráns a PHP implementációja, de van egy olyan sanda gyanúm, hogy annyira nem, hogy bármit szabadjon csinálni.

Szerintem, az a megoldás, hogy egy system hívással elindítasz egy fájlt, (ami megcsinálja a feladatot,) nem szinkron módon. Windows alatt start paranccsal tudod megcsinálni, Linux alatt nem tudom. Ez persze azt jelenti, hogy ha több egy ilyen esemény jön be, akkor több process fog futni.
12

lock file

N0r3i · 2007. Ápr. 5. (Cs), 13.34
A több esemény -> több process problémát könnyen tudnám orvosolni mondjuk egy lock file felhasználásával. A küldendő adatok úgyis mindig ugyan abba az adatbázisba kerülnek, és a feldolgozott rekordokat azonnal törlöm, így ez nem lenne probléma.

Ez a system dolog mennyire biztonságos? Hívhatok így (elsősorban linuxon érdekes) egy mások PHP scriptet?
14

Hívhatsz

janoszen · 2007. Ápr. 5. (Cs), 14.53
Persze, hívhatsz, a PHP CLI-n keresztül megszólíthatod. Biztonsági szempontból azzal a userrel futsz, mint a webszerver, hacsak nem CGI (FastCGI) van föltéve, mert akkor a saját user neved alól megy.