PHP vagy nem PHP.

Nagyon sok bejegyzésben/hozzászólásban olvasom, hogy a PHP-t mennyien nem tartják komoly célra használható nyelvnek. De sehol nem olvastam még olyan érvet, ami mindezt valóban alátámasztaná.

Valamikor én is nagy PHP ellenző voltam. De egyszer rátolt az élet, hogy kicsit elmélyüljek benne, és arra jutottam, hogy a maga -vitathatatlan- hülyeségeivel, inkonzisztenciáival együtt is egy jól használható eszköz. Nagyon jól dokumentált. és 1000 apró dologra van benne kész megoldás. A html-en keresztül nagyon jól lehet formázni a kimenetét, és a rendszerigénye is teljesen tolerálható.
Egyfajta svájci bicska.

Az, hogy valami komoly célra használható kerül-e ki a kezeink közül, az pedig még mindig rajtunk, mint programozókon múlik. Szerintem a PHP-nak jogos helye van minden programozó eszköztárában. Mindenkinek aki eddig távol tartotta magát tőle, ajánlom, hogy szánjon rá egy pár napot, és ismerkedjen meg vele. Akár úgy, hogy tekintse egy erősebb bash-nak, mint egy gyengébb C-nek.

Olyasmi feladatokra, mint pl. ami most jött szembe.
- adott két kamera amik 5 percenként egy-egy képet feltöltenek egy szerverre.
- ezek közül a képek közül ki kell venni azokat amik nem tartalmaznak használható információt. (pl. majdnem teljesen feketék, mert nem éjellátó kamerákról van szó)

Ti miben, hogyan oldanátok meg?

( uid_7086 | 2013. 10. 20., v – 23:04 )

Nem tudom, az imagemagick vagy valami egyéb eszköz alkalmas-e a feladatra. Ha igen, szerintem ez nem olyan feladvány, amire ne lehetne PHP-t használni. (imagemagick segítségével a histogram lekérdezhető, szóval a feketesége jó eséllyel megállapítható)

Én nem szeretem a sok következetlensége miatt, de hasonló csúfságokba belefutottam pl. django-ban is, szóval ez önmagában már nem ellenérv.
Manapság úgy érzem, a legfőbb gond vele az elterjedtsége, ami miatt a legtöbb Szomszéd Pistike ezt használja, ezért van igazán rossz híre.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Igazából egy picit bonyolítani tervezem az értelmező részt... hátha meg tudom tanítani más "rossz" képek kiszűrésére is. De a feketeségre valóban jó ötlet a histogram. A keretet miben írnád meg?

A szomszéd pistike dolog is jogsos. Kicsit olyan Comic-Sans jellege van a dolognak. De fordítva nézve, ezekszerint könnyű belerázódni.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

( saxus | 2013. 10. 20., v – 23:21 )

Nem azzal van a gond, hogy használható vagy nem használható, mert vannak dolgok, amikre én is ezt választom.

Hanem arról van szó, hogy nagyobb projekteken már igen erősen érződik a hátránya.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igen van egy pont ahol vaskézzel markolt kódolási guidelinineok nélkül bizony a nagy "szabadság" vissza tud ütni.
De sok esetben látom úgy, hogy a komoly dolgok nem is olyan nagyok.
Amúgy szerintem nagy projekteknél mik a legkomolyabb problémák amiket a nyelv okoz?

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

- Gyengen tipusossag. Amennyit sporol vele az ember, annak tobbszoroset bukja kesobb, mikor egy halom ellenorzest be kell rakni, hogy valonban az jott-e a kulvilagbol.
- Nagy szabadsag vissza fog utni. Foleg, ha tobben dolgoznak a projekten.
- Amikor mondjuk jo lenne egy normalis multithread daemon.
- Altalaban nincs gond a sebessegevel, de van, amit pl. eselytelen gyorsra megirni benne. Pl. ha tudna rendes appserverkent futni a PHP es be lehetne tolteni _egyszer_ egy csomo adatot elore a DB-bol, nem minden oldallekeresnel ujra es ujra. (Ez a mi esetunkben oldaltol fuggoen kb. otodere-tizedere vagna vissza a DB muveleteket)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mintha a Zend tudna alkalmazás szerverként is működni. Vagy az valami más? Csak fórumokon olvastam róla, sohasem néztem utána, hogy mi ez, szóval számomra kissé rejtélyes, hogy ez csak egy framework vagy valami egyéb is van mögötte?

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Attól, hogy összecsomiznak mindent egy csomagba, még nem lesz application server. De nem is értem, hoyg jön ez ide: azzal nem tudsz mit tenni, hogy a PHP script a kérés feldolgozása után kilép és minden adatot felszabadít.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Simán lehet PHP-ben démont is írni (most hagyjuk, hogy mennyire stabil), mi akadályoz meg benne, hogy pl. alkalmazás szervert írjak?

Egyébként ha jók az emlékeim, zend néven fut alkalmazás szerver fejlesztés is, nem csak keretrendszer. (persze tévedhetek, nem néztem utána)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ha fogalmad sincs róla, akkor minek magyarázol?

Nem daemonról van szó, hanem alkalmazásszerverről. Ami elindul, inicializál, majd fogadja a kéréseket és jobb esetben ezt multithread módon teszi. Na most erre a PHP totálisan alkalmatlan. És mondjuk tudok adatot a memóriában tartani egy-egy kérés között.

"most hagyjuk, hogy mennyire stabil)"

Ezek után, hogy te fikkantod, mégis miről beszélünk?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Arról pofázok, hogy ha démont lehet írni benne, akkor mi akadálya annak, hogy alkalmazás szervert is írj?
http://en.wikipedia.org/wiki/Zend_Server
Bogarászd ki belőle, ha érdekel, hogy valóban AS-e avagy csak valami, amit annak neveznek! ;)

És a lehetőségről van szó, nem a használhatóságról. :)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Szóval, ha megírom magamnak, hogy alkalmazásszerverként működjön, akkor jó lesz. Köszi.

Akkor lefordítom magyarra: eredendően nem ennek tervezték és ebből kifolyólag így nem képes kiszolgálni a webes kéréseket, csak ordenálé nagy és ronda hackok árán, amit biztos, hogy nem raknék be production környezetbe.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A mondandód második felével (nem túl nyerő produktív környezetben) nem vitatkozom. Szerintem sem nevezhető ideálisnak.

Az elsőt meg most ellenőrzöm (kúszik fel egy zend szerver - screenshotok alapján kísértetiesen emlékeztet egy valódi alkalmazás szerverre), még érhet meglepetés téged is, engem is (feltéve, hogy te sem ismered :) )

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ezt kérdezd a fejlesztőitől. Szerintem ugyanúgy, ahogy mondjuk egy javaban megírt szerver esetében.
Van egy olyanom, hogy úgy vitatkozunk róla, hogy te sem értesz hozzá, meg én sem. Csak én el tudom képzelni, hogy működhet (még ha nem is túl stabilan), te meg eleve kizártnak tartod.

Te tényleg azt hiszed, hogy a PHP még mindig csak egy template nyelv? Akkor most szólok, hogy már régóta van benne mindenféle OOP elem, létezik olyan kiegészítő, amivel gyakorlatilag ugyanúgy lehet parancssoros programokat írni benne, mint mondjuk egy python-ban vagy perl-ben, más kérdés, hogy finoman szólva nem erre lett kitalálva. :)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Kicsit részleteznéd?
Imádom az ilyen beszólásaitokat, mikor még egy értelmes magyarázatra is képtelenek vagytok. :D
(közben kicsit utánanéztem: a Zend Servert Application Serverként definiálják, én meg elhiszem nekik)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Kb. 2004 óta foglalkozok PHP-vel. Igen, tudom, hogy lehet CLI-ből is futtatni (pont most nyessük vissza azt a részét a rendszereinknek...), és nem, nem tud ugyanúgy futni, mint a Java vagy a .NET. Kezdjük onnan, hogy az utóbbi kettő egy JIT-telt nyelv, míg a PHP egy interpretált, és akkor látom még mindig nem sikerült felfogni a különbséget aközött, hogy:

PHP script:
1) Beesik a request az [insert kedvenc webserver here]-hez:
2) A kérést megkapja a PHP, mod_php vagy fcgi-ként, rosszabb esetben CGI-ként és indul nulláról egy PHP process.
3) Nekiáll interpretálni a kódot
3.1) Jobb esetben valamilyen opcode cache-ből rángatja elő ugyanezt.
4) Inicializálja a webes scriptkupacot/frameworköt, akármit, db kapcsolatot, mindent.
5) Egyszer csak eljut a kérés lényegi részéhez, ahol már a tényleges munka fut.
6) Visszaböfögi a webszervernek a választ, majd felszabadít mindent.

VS

Application server:
0) Elindul vagy elindítja az AS az alkalmazásod
0.1) Az alkalmazásod inicializál
0.2) Ha kell betöltöd az összes adatot, amivel dolgozni akarsz, felépíti a DB kapcsolatokat, stb.
0.3) Mindezt egyszer.
----
1) A már futó alkalmazás megvárja, míg jön egy request.
2) Inicializálás helyett egyből a modul fog futni.
3) TADA.WAV, GOTO 1

És igen, vágom, hogy beletúrtak egy rakás dolgot, PHP5-től már-már majdnem jól használható OOP is van benne, de még így is rengeteg olyan dolog van, ami mondjuk C#-ban vagy Java-ban ezerszer egyszerűbb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Na ezt egy kicsit részletesebben, ha kérhetem, mert tényleg nem értem: mi az, amitől nem tud úgy futni, mint egy java v. .net alkalmazás?
Még egyszer mondom: stabilitás, biztonság, egyszerűság most nem igazán szempont, csak a puszta működés, mivel eredetileg is csak ennyiről volt szó.

A Zend Servert - ebből következően - gondolom ismered. Miben más, mint mondjuk egy java AS?
----------
Közben módosítottad a hozzászólásod, akkor én is:
amit írsz különbséget az a mezei PHP applikáció, meg egy alkalmazás szerverben futó program közti eltérés. De (én most hirtelen csak ezt találtam) úgy tűnik, a Zend Server épp ezt valósítja meg...

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ja, majd ha teszem azt egy drupal-t beraksz Zend "AS"-be, akkor majd a php script, ami lefut, kilép és stateless, hírtelen egy stateful applicationként kezd el futni, mindenféle módosítás nélkül?

Biztos, hogy én nem értek hozzá?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Momentán úgy tűnik, te vagy az, aki vagy tényleg nem ért hozzá, vagy szándékosan tereli a témát.
Én még nem láttam olyat, hogy valami, ami alapvetően nem arra készült, hogy alkalmazás szervert használjon, hirtelen annak megfelelően kezdett volna működni.
Kb. olyan, mintha egy java-ban írt CGI programtól várnád ugyanezt, holott az sem fog másképp működni, mint egy alap PHP program.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Magyarázd már el, hogy az alapvetően single thread, mindig kilépő PHP script mintől fog a tökugyanazokból az alapkomponensekből építkező Zend Serveren (+néhány extra mütyűrön, ami a deployt, cront, stb.-t segíti) úgy futni, hogy a PHP script NEM fog kilépni, miután befejezte a kérés kiszolgálását, hanem egyből várja a requestet inicializált frameworkkel, mindezt multithreaden?

Elárulom: semmi.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Elbeszélünk egymás mellett, attól tartok.
Te az alap PHP környezetből indulsz ki, én meg abból, hogy van egy PHP interpreter, ami futtat egy PHP kódot, a'la phpcli (nem tudom, mi a pontos neve).
Nem tudom, konkrétan hogy működik a Zend Server, (egyébként erre céloztam korábban, hogy a jelek szerint mintha te sem tudnád) de el tudok képzelni olyat, hogy önmagán belül megoldja az ilyesmit, csak ehhez igazodva kell megírni a kódot.
Multithread tudtommal van PHP-ben (nem tudom mióta): http://www.php.net/manual/en/book.pthreads.php
Ez nem az?
Pl. erre alapozva meg lehet írni a megfelelő alkalmazásszervert is, ha épp úgy adódik, nem?

Közben kaptam egy linket: http://weblabor.hu/blog/20100907/php-alkalmazas-szerver
Emlékeztem rá, hogy valahol olvastam ilyesmit, csak arra nem, hogy hol, a google meg a kereséseimre ezt nem hozta elő. (igaz, elsősorban a hup-on és külföldi oldalakon keresgéltem)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Szóval fingod nincs, de okoskodsz.

phpcli és a fastcgi/mod_php is tök ugyanazon az elven működik ilyen szempontból. A Zend "Application Server" nevű cucc, meg ugyanezekre építkezik. De sebaj, te egy screenshot alapján jobban tudod.

Nem mondom, hogy nem lehetne összetákolni, de azt már az adott PHP scriptben kell, azon nem segít a ZAS. Ld. pl. ZAS-ba deployolt drupal. De úgy látom, te jól összemosod a ZAS-t, a ZF-et és a megvalósított alkalmazást.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nézd meg a fenti linket!
Továbbra is ott tartunk, hogy nem az a kérdés, mennyire hatékony/biztonságos/etc, hanem, hogy megoldható-e. És jééé, igen, valóban megoldható.

Nem én mosom össze...

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Idézlek: " van, amit pl. eselytelen gyorsra megirni benne. Pl. ha tudna rendes appserverkent futni a PHP es be lehetne tolteni _egyszer_ egy csomo adatot elore a DB-bol, nem minden oldallekeresnel ujra es ujra. "

Ezt meg lehet csinálni PHP-ben is. Pont. Hogy mennyi munka, nem tudom.
A Zend Server részemről csak egy olyan kitérő volt, amiről feltételeztem, hogy normál alkalmazásszerver lehet.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Mi a f@szért kellene neki megnéznie a linkeket? Te tettél állításokat a szál elején/közben, nézd meg te, olvasgasd, értelmezd, és ha jutottál valamire, akkor írd be ide, hogy "A Zend Server azért van partiban a jelenlegi Java-s megoldásokkal, mert..." na itt jönnek majd az érveid.

Illetve ha nem csak mindig az előző hozzászólásból kimazsolázott szakkifejezésekre reagálnál Google szinten, hanem átfogóan értelmeznéd a kérdést, az is sokat segítene.

És ez még csak a "hogyan folytassunk értelmes vitát" téma, nem is a PHP vs akármi.

Na ezért lol.

Na most, ha kicsit oda is figyeltél volna és nem csak a beleugatás céljából szóltál volna hozzá, akkor esetleg észrevehetted volna, hogy valaki tett itt egy kategorikus kijelentést, miszerint PHP-ben nem lehet alkalmazásszervert írni. Janoszen meg elég szépen leírta a fenti, három évvel ezelőtt íródott írásában, hogy tképp lehet.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Előtúrtál egy proof of conceptet (ami amúgy erősen épít egy Gearman nevű, nem PHP orientált szoftverre), és el akarod sózni, mint használható gyakorlati alternatívát? Zend szervert meg idekavarod, mivel lövésed sincs róla, csak az "Application Server" string ollyan enterprájszul hangzik, akkor ez biztos ugyanaz?

Bash-ban is lehet appszervert írni, miért pont abban ne lehetne? Sőt, toljad a linkeket, biztos már van is.

(Mellesleg a Janoszen cikk baromi jó, de nem ez a lényeg.)

Na akkor megis csak beleszolok a temaba. Megirtam FastCGI-re is a proof of conceptet nativ PHP-ban, de sajnos tobb projekt bizonyitotta, hogy a PHP socket kezelese olyan memory leakes mint az allat. Lehet hozza restartert irni meg minden egyeb ilyen hulyeseget, de a veredemeny megis csak az, hogy noha technikailag lehet PHP-hoz appszervert irni nativ PHP-ban, gazdasagilag nem erdemes. Ha valaki nagyon akar ebbe az iranyba erolkodni, jobban teszi, ha mindjart C-ben all neki a megfelelo kodot legyartani.

És végeredményben erről pofázok az egész kezdete óta, hogy _lehet_, a többi nem érdekel.

Mondjuk az, hogy három év alatt nem tudták rendbe tenni, az más téma.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nem celja a PHP-nak. Egy alkalmazasszervernek tok mas uzemeltetesi kovetelmenyei vannak, mint egy fire and forget scriptnek. Igy csomo-csomo problemaval nem kell foglalkozni mind fejlesztes mind uzemeltetes oldalrol. El lehet donteni, hogy az adott feladatra mi a megfelelo eszkoz.

Aki tud tisztesseges kodot irni, az PHP-ban is tud. Aki meg nem tud, annak ugyis mindegy.

Ezt már korábban is megbeszéltük: a PHP eredendően egy template nyelvnek készült, ennek megfelelő minőségű az egész.
Csak itt egyesek annyira belelovalták magukat a fikázásába, hogy muszáj volt kicsit visszatartani a társulatot, mert annyira nem hulladék, mint ahogy rengetegen állítják.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

MS-DOS-ra is írtak webszervert, mégse hostolnak nagyon FreeDOS-ról, na vajon miért? Persze, meg lehet írni, jó nem lesz, de legalább LEHET!

Bocs, de ezzel _nincs_ megoldva a probléma. És nagyon jól összemosod azt az apróságot, hogy a PHP interpreter alkalmatlan arra, hogy alkalmazásszerverként fusson, perzisztens módon és úgy szolgáljon ki párhuzamos kéréseket, mivel nincs ilyen funkciója. (Persze, bele lehet nyúlni, de...) Amiről te beszélsz, az az, hogy e felett PHP-ben újraimplementálva azt, amit a Java és .NET alatt már rég megírtak, azzal ugyanúgy nem vagyunk ki a vízből, mert production munkára totálisan alkalmatlan a PHP ilyen szempontból. Igen, több, már mint egy template nyelv, de még mindig kevesebb, mint egy teljesen általános célú programozási nyelv.

Sajnos a "lehet" picit kevés. Mint ahogy attól, hogy a ZS-ba összecsomagolják ugyanazt egy kis körítéssel, mint amit önállóan is össze tudok legózni, attól még nem lesz AS.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Miért? A java interpreterbe bele van kódolva az AS?
Szerintem azt is javaban írták.

Mégegyszer: te kategorikusan kijelentetted, hogy nem lehet. Én meg azt ismételgetem, hogy lehet. Senki sem mondta, hogy érdemes. Ha megnézed az itteni hozzászólásaimat, sehol sem emlegettem olyat, hogy a PHP bármi extrém dologra élesben használható lenne.

Említhetem legfrissebb mániámat: python microframeworkök, beépített, pythonban írt webszerverrel. Azok is csak játékra jók (fejlesztéseket tesztelni, bár inkább csak tanulásra), éles környezetben eszembe nem jutna használni őket.

És nem győzöm hangsúlyozni: a Zend mellékszálként került ide, rákerestem arra, hogy PHP Appserver és ez volt az első találatom.
Ezek után megnéztem, hogy hogy néz ki, nagyjából emlékeztetett arra, amit anno alkalmazásszerver címén láttam, leírtam, hogy nekem úgy tűnik, hogy...

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nem szeretned befejezni? GYAKORLATBAN nem lehet PHP appszervert irni PHP-ban mert memleakes a socket implementacio. Irhatsz, csak le fog rohadni nagyon gyorsan. Ahhoz, hogy ne rohadjon le, segitseg kell a PHP-n kivulrol. Innentol kezdve meg nem hasonlithato a Javahoz. Kezicsokolom.

Mindegy, hagyjuk! (valaki kategorikusan kijelent valamit, ami úgy, abban a formában nem igaz, majd nekiáll győzködni, hogy de mégis)

Viszont ez az indoklásod kissé mellément: attól, hogy bugos az interpreter és szarnak a javítására... Ki kell javítani és akkor máris mehet.
(vannak egyéb gondok vele, ami miatt a gyakorlatban nem lesz használható még sokáig, de a memleak csak egy javítandó bug)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nemigazhogyvalakiennyireerőltesse...

Melyik részét nem érted annak, hogy az elvi lehetőségről beszéltem kezdetektől, te meg egyre jössz a gyakorlati alkalmazásával.
Az, hogy egy ordas nagy bug benne van a php interpreterben a mai napig, az miért akadály?
Hogy nem erre találták ki, azt senki sem vitatja.
Ettől még a PHP-ben rengeteg olyan dolgot meg lehet csinálni, amire nem való. Ennyi.
Na, részemről kiszálltam. Ha értitek miről ugatok jó, ha nem, magánügy.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ne keverjuk a nyelvet es a nyelv implementaciojat. Nincs mindenki megelegedve a php zend fele implementacijaval,
igy aztan tobb kevesebb sikerrel szuletnek mas implementaciok is.

Harom nepszerubb, open source implementacio (java, c#, c++):
http://quercus.caucho.com/
http://www.php-compiler.net/
http://www.hiphop-php.com/

Es lass csodat, a php (quercus) elerheto java application serveren.

A php alapvetoen allapot nelkuli mukodesre lett kitalalva, annak minden elonyevel es minden hatranyaval. Hatranybol van rengeteg, ezt mar kifejtettetek, de belso allapot hianya erdekes dolgokra ad lehetoseget.

pl.: az allapotok rogzitesevel, majd a vegrehajtasi grafok osszehasonlitasaval lehetoseg van exploit detektalasra, sot a multban tortent biztonsagi incidensek elemzesere is ...

Taesoo Kim, Ramesh Chandra, Nickolai Zeldovich: Efficient patch-based auditing for web application vulnerabilities [1]

"This paper presented POIROT, a system that can audit
past requests in a web application for exploits of a newly
patched security vulnerability. POIROT incorporates three
techniques—control flow filtering, function-level auditing,
and memoized re-execution—to significantly speed up
auditing compared to previous systems that audit through
re-execution. POIROT is effective at detecting exploits of
real vulnerabilities in MediaWiki and HotCRP. POIROT’s
optimizations allow it to audit challenging patches, which
affect every request, 12–51× faster than the original exe-
cution time of those requests."

[1] https://www.usenix.org/system/files/conference/osdi12/osdi12-final-147…

Ez remek, csak az esetek jelentős részében nem elég a stateles rendszer. Plusz ezzel el veszel magadtól egy jó adag cachelési lehetőséget.

Mi pl. ezzel az SQL Query-jeink drasztikus részét meg tudnánk spórolni (minimum fele), ha anno nem PHP-ben kezdtük volna, hanem valami olyanba, amivel lehet adatot tárolni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

De tudtam, hogy valaki idejon a memcacheddel, anelkul, hogy felfogna a lenyeget.

Adott mondjuk egy 80K-s cikktorzs, cikktorzsenkent N arral K keszletinfoval, stb. Mikor megjelenitesz termekeket (darabszam mondjuk 1...1000/oldallekeres, es igen, nem veletlen huzunk ki 1000-ret, ugyanis kliensoldalon van a lapozas), akkor mi lesz a gyorsabb?
a) Ott van az alkalmazas memoriajaban elore betoltve?
b) Kihuzod egyben a PostgreSQL-bol? (Ami jo esellyel ugyanugy memoriabol szolgalja ki)
c) Mivel mashogy nem nagyon tudod csoportositani, egyesevel kimazsolazod memcachedbol?

Memcached sajat mereseim alapjan egy erosen tulertekelt dolog. Egyreszt, mert sokszor mar az RDBMS is cachebol szolgalja ki a tartalmat, masreszt sokszor van olyan adat, ami nem cachelheto, harmadreszt hiaba memoriaban tarolja, a PHP deserializalas es a plusz halozati kapcsolat akkora overhead, hogy maris elenyeszik a memcached elonye. Nalunk az osszes esetre ez jott ki, ahol hasznalni akartuk.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

mekkora a masodpercenkenti oldalletoltesek szama nalatok? Nem a kepek, stb. erdekel, hanem a dinamikusan eloallitott tartalom, ill. (most nem lapoztam vissza) a "80K-s cikktorzs" az 80000 cikket jelent, es vegul 1 oldalon tenyleg 1000 termeket mutattok meg?

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

Irreleváns, itt most arról van szó, hogy egy oldalt mennyi idő alatt szolgál ki. És igen, van olyan, hogy egy oldalon tényleg 1000 termék jelenik meg, mivel a gyakorlat azt mutatja, hogy jobb letolni mindent egyszer egy cikkcsoporton belül a kliensnek és a lapozást, gyorskeresést, szűrést (ez alatt egy oldalt lévő szűrőre gondolj) kliens oldalon intézni JS-ből. Persze, ez nem azt jelenti, hogy az összes oldal 1000 cikket tartalmaz, de van olyan.

De ha kell, hozhatnék olyan példát is, ahol a 37K aktív cikket mind le kell tolni mondjuk egy XML-be vagy egy CSV-be, természetesen ott a több MP megengedett.

Szerk.: Szumma 37K aktív cikk, átlag 135/kategória, a top 3 1016, 1393 és 1615, az átlag felett 73 kategória van a 276-ból.

(Az persze más kérdés, hogy ha az adatokat a memóriában lehetne tárolni, az is meglenne <100ms alatt.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Én sem nagyon látom általánosságban a memcached értelmét. Gyakorlatilag visszavesszük a DB feladatának nagy részét megunkra, fejlesztőkre, hogy mi optimalizáljuk ki, hogy milyen műveletek milyen erőforrás igényesek - és azokból a leggyakoribbakat direkte memóriában tároljuk - ha elférne a cache-ben, ha nem.

Rettentő macerás dolognak tűnik. Persze lehet mindent agyon optimalizálni, csak kérdés a kód egyszerűsége és karbantarthatósága. Számomra a DB a kisrabszolga - én megmondom mit kérek, ő meg adja ki az eredményt az általa legoptimálisabban. Ha 20x kérem le ugyanazt ugyanazzal az SQL paranccsal és a táblák sem változtak, akkor dobja ki cache-ből.

A post, amire válaszoltam, nem tartalmazta, mennyi és milyen adatot akarsz kitolni, szóval abból felfogni a lényeget... Azt hiszem megjegyeztem a postom végén azt is, hogy ésszel kell azt is használni. Nyalván nem alkalmas mindenre, esetedben valóban nem megoldás, de vannak helyzetek, mikor van helye.

( dap | 2013. 10. 21., h – 00:07 )

Errefelé stabil daemont még egyik fejlesztő se tudott php-ban írni, mindet watchdog rúgdossa újra, többnyire segfault után. Puszta megfigyelés, nem az én dolgom utánamenni, hogy mi a baj. PHP-s GUI alkalmazással se igazán találkozom valamiért.

Érdekes a daemon dolog. Van esetleg konkrét példa? Amúgy simán el tudom képzelni. Avval, hogy gondolom inkább az interpreter adja meg magát ilyenkor.
Elvileg van hozzá GTK meg ilyenek, de inkább nem akarom tudni. Ellenben a webes alkalmazások is GUI alkalmazások.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Esélyes, hogy az interpreter hibája, de azt is figyelembe kell venni a nyelvnél, pláne ha nincs nagy választék belőle. Konkrét példát nem tudok, proprietary szoftverek, más php daemonnal még nem igazán találkoztam.

A web csak egy korlátozott GUI és nekem kérdéses, hogy ebben a formában lesz-e valaha teljes értékű a biztonsági aggályok miatt.

Igen, a világ erre megy, csak ez nagyon nincs jó hatással egyik szakterületre sem. Én belekontárkodtam mindkettőbe, nem árt, ha a fejlesztő tisztában van az üzemeltetés alapjaival és az üzemeltető is látott már éles fejlesztést, de nem kellene őket összemosni.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Viszont milyen jó lenne, ha bizonyos helyeken a fejlesztők és üzemeltetők végre eljutnának odáig, hogy az "olvasott" jelzésre ne maradjon olvasatlan egy-egy bejegyzés! ;)
(finom célozgatás egy évek óta meglévő hibára, bár nem tudom, te személyesen érintett vagy-e... :)) )

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nincs baj az ilyen jellegű terminus technicusokkal, ha nincsenek túldimenzionálva.
A legnagyobb baj az, hogy minden esetben a marketing akarja megmondani, hogy már pedig mi a trend, és mi a jó, így gyakorlatilag minden ilyesmi elindít egy hype cunamit, amibe aztán sokan belebuknak, és az első néhány, a valós élettől kapott megfelelő méretű maflás után megtanulják a helyén kezelni a dolgokat.
--
PtY - www.onlinedemo.hu

Mindenesetre abban egyetértünk, hogy az üzemeltetés nagyot változott az utóbbi 10 évben, szerintem nagyobbat mint a szoftverfejlesztés; virtualizáció, SDDC, egy üzemeltetőnek sokkal több absztrakt dologgal kell foglalkoznia mint 10 évvel ezelőtt. Ezzel együtt elvárás lett, hogy a rendszer az alkalmazás köré épüljön, ne pedig fordítva, amihez szükséges a fejlesztők infrastrukturával kapcsolatos problémáinak megértése-megoldása is.
A devops szerintem ezt a folyamatot próbálja felcímkézni, fölöslegesen; ma már ez az üzemeltetés és kész.

( sj | 2013. 10. 21., h – 09:26 )

a PHP-t mennyien nem tartják komoly célra használható nyelvnek.

LOL. En is sok fikazast hallottam mar, de meg egy olyat sem, hogy mit nem lehet vele megcsinalni, amit a preferalt cuccal viszont igen.

Szerintem a PHP-nak jogos helye van minden programozó eszköztárában.

-1. Az, hogy neked bejott a php, egy dolog, de pl. python/perl hasznalataval is meg lehet azt oldani, amit php-val, IMHO. Ha pedig az jobban fekszik valakinek, akkor miert valtana php-ra?

tekintse egy erősebb bash-nak, mint egy gyengébb C-nek.

hat, en a C-vel azert nem vennem egy kalap ala a php-t.

ezek közül a képek közül ki kell venni azokat amik nem tartalmaznak használható információt. (pl. majdnem teljesen feketék, mert nem éjellátó kamerákról van szó)

Ti miben, hogyan oldanátok meg?

g/jocr. Mindket kamera elott levo falra feltennem a "hello world!" szoveget, aztan ha az ocr cucc nem tudja azt visszaadni, akkor sotet van ...

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

Na ez megint olyan, hogy úgy másfél éve olvastam valahol: fájlban nem tárolja (nem tárolja?) de betöltés után előbb bájtkódra fordul, azt futtatja az interpreter és ami belefér az interpreter memóriájába, azt csak az első betöltéskor fordítja (ahogy pl. az Oracle a futtatott SQL-eket is csak egyszer optimalizálja, utána ha megegyező SQL-t kap, csak futtatja, nem fordít és optimalizál újra)

ui: mintha erről is a weblaboron írt volna valaki, de szokás szerint nem jegyeztem meg, hogy hol. :(
http://en.wikipedia.org/wiki/List_of_PHP_accelerators - lehet, hogy erre emlékszem?

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Igen, ezeket hívják opcode cachenak, de ez még mindig fényévekre van a JIT-telt nyelvtől.

És ha nem tűnt volna fel, én arról beszélek, hogy elindítod az appservert és adatot töltesz bele. Mondjuk egy 80K-s cikktörzset készlet, cikkenként mondjuk 10-20 árral, készlet információkkal és az ott van osztottan a memóriában a worker threadek között. (Meg mondjuk van egy thread a háttérben, ami ül a pg-s signalon, hogy van-e változás.)

Na ezt csinálja meg PHP-ben az, akinek 6 anyja van.

(Az első embert, aki a memcached-el jön, tarkón vágom egy PHP 24 óra alattal...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

(Az első embert, aki a memcached-el jön, tarkón vágom egy PHP 24 óra alattal...)

A quercus er? :-) Amugy reszvetem. Na nem a 6-anyas taszk miatt, hanem hogy annak a dilettans hulyenek az etetesevel bunteted magad...

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

g/jocr. Mindket kamera elott levo falra feltennem a "hello world!" szoveget, aztan ha az ocr cucc nem tudja azt visszaadni, akkor sotet van ...

Ja. Atlagos fenyesseget szamolni az Y plane-re az tul olcso muvelet, valahogy muszaj elbonyolitani. Hatha nem szedik le azt a HELLOWORLD tablat a falrol. Gyonyszem ez a teljes topic.

---
pontscho / fresh!mindworkz

Ja. Atlagos fenyesseget szamolni az Y plane-re az tul olcso muvelet, valahogy muszaj elbonyolitani. Hatha nem szedik le azt a HELLOWORLD tablat a falrol. Gyonyszem ez a teljes topic.

legkozelebb kiteszem majd a szmajlit is, hogy neked is leessen, poenrol volt szo...

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

Én Perl-el kezdtem anno. És igen az is jó ilyen célokra.
Ellenben a hely az eszköztárban más dolgoknak is betehető. Az egyik ilyen az, hogy nagyon elterjedt. Pont ezért gondolom. hogy egy alap C-C++ ismeret. Bár valahol evvel is az van, hogy ami szembejön, azt megtanuljuk így-is úgy-is.
A következő nekem az Ocatave lesz.

Mint ahogy a bash-al sem feltétlen tartozik egy kalap alá. Az egész felvetés inkább használati, mint technikai.

Nem lenne egyszerűbb OCR helyett egy dekoratív hölgyeményt odaültetni egy gombbal... és megmondani, hogy ha nem látja a szöveget akkor tartsa nyomva a gombot. Ilyenkor kikapcsolná a kamrát, és még a hálózati sávszelet is megspóroljuk.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

"Nem lenne egyszerűbb OCR helyett egy dekoratív hölgyeményt odaültetni egy gombbal... és megmondani, hogy ha nem látja a szöveget akkor tartsa nyomva a gombot. Ilyenkor kikapcsolná a kamrát, és még a hálózati sávszelet is megspóroljuk."

Bar viccnek szantad - ahogy sj is, de sajnos nem az. Kinaban ezt valahogy igy oldanak meg.. :-/

--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.

Mert ott valòszìnûleg ez a problèma egyik "jò" megoldàsa.

Igen viccesnek szàntam, de az, hogy ez valahol reàlis nem teszi kevèsbè vicccessè szerintem. Ha mondjuk 72 òràra kène, nàlunk sem lenne a gondolat annyira elvetemült

### ()__))____________)~~~ #################
# "Ha én velet. ek, ki ellenetek?" # E130/Arch .

( PtY | 2013. 10. 21., h – 10:02 )

Bár nem értek a PHP-hoz nagyon, és nem is szeretem annyira mint a perlt, de egy kétségtelen: ma a PHP az, ami a leg dinamikusabban fejlődik és bővül azon nyelvek közül, amelyek scriptelésre és webalkalmazások fejlesztésére valók. Ez tény.
Az is tény, hogy a futtatókörnyezeteknek sokszor vannak biztonsági rései, ami miatt megtörnek oldalakat, de ezek zöme a hostmaster bűne, mert kimarad egy-egy upgrade.
Mivel az egyik legelterjedtebb webes parancsnyelvről beszélünk, nagyon sok a kókler a piacon, és önlik a szemét kód - ezt szokás a PHP hibájaként emlegetni, pedig szemétre való kódot bármilyen nyelven lehet írni.

Szóval szerintem lehet php.

Hogy a kérdésedre válaszoljak, az adott könyvtárra tennék egy incron-t, ami írás+zárásra ugrik, és perl scriptet hívnék meg.

--
PtY - www.onlinedemo.hu

( log69 | 2013. 10. 21., h – 10:27 )

ImageMagick-kel rányomnék egy nagy blur-t, majd az identify util-jával megnézném az átlag világosságát a képnek - és máris van egy egzakt adat, amelyre vizsgálhatsz.

Pl.
Image statistics:
Overall:
min: 0 (0)
max: 255 (1)
mean: 38.9121 (0.152597)
standard deviation: 62.0009 (0.243141)
kurtosis: 0.939962
skewness: 1.48068

Az AST-nél elakadtam. Most hallok róla először ebben a formában (mint ASyncron Trap ismerősebb volt :) )
De végeredményben a PHP egy template nyelvnek indult a HTML kibővítésére, hogy az lett belőle, ami...
"Hát van ez így" :)

ui: amikor olyat látok, hogy "LOL", arról a legtöbbször valami nagyképűsködő, a dolgok hátteréről mit sem tudó "megmondó emberekre" asszociálok.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

( shark | 2013. 10. 21., h – 19:07 )

Sub, 7 éve kódolok PHP-ban, van pár rossz tapasztalatom... :(