Miért húzzák le állandóan a php-t

Miért húzzák le állandóan a php-t
2021-11-19T21:58:07+01:00
2021-11-24T09:21:28+01:00
2022-10-17T07:05:40+02:00
  • igen az OPcache nagyon hasznos, bináris formába tárolja,
    illetve van memória cache is, ami még ezt is gyorsítja mert memóriában marad.
    Enélkül akár 3~4× load idő is lehet egy méretes FW esetén.
    Amit írtál a java -nál, hogy folyamatosan fut, az is megoldható,
    de ahogy írtad, jönnek különböző gondok amiket le kell kezelni.
    Talán a legnehezebb, hogy ne fogyjunk ki a RAM -ból.
    Nagyon hamar elpárolog 32GB is.
    Mutasd a teljes hozzászólást!
  • Nem csak a OnePage app -ok töltenek be halom JS / CSS -t...
    Sajnos tipikus hiba, hogy minden ilyent első lapbetöltéssel lejön,
    majd utána cacheből tölti be minden oldalváltásnál.

    Meg lehetne oldani hogy egy base rész legyen,
    aztán ahogy kell, úgy tölti be a többit.
    csak így meg a szükséges CSS / JS függőséget kellene lekezelni,
    megnézni, hogy mik kellenek az adott tartalomhoz, és be töltöttük -e már.
    De ha függőségi fát is kezelni akarjuk, akkor bele őszülőnk.
    Így jelenleg a bevett szokás, hogy főbb felosztáson túl (css),
    minden kiegészítő részt asynchronba töltjük be.
    Mutasd a teljes hozzászólást!
  • Dolgoztam C#-ban és .net core-ban is, nekem nem jöttek be.
    A kérdés lényege nem az volt, hogy melyik jobb vagy nem jobb, hanem hogy úton útfélen f*kázzák a php-t, amit nem értettem hogy miért :)



    A “tanulj meg mást is” dologgal kapcsolatban, annyi hogy szívesen próbálgatok ki más nyelveket, de közel 38 évesen 2 kisgyerekes apukaként esélytelen annyi időt találni, hogy normális megtanuljon az ember egy új nyelvet :)
    Mutasd a teljes hozzászólást!
  • En mondjuk hasznalom ezeket is, meg sok mast is, de php siman jobb weboldal epitesre.
    Az a vicc, ha ugy tetszik a php egy microservice kornyezett, vagy inkabb delta funkciok, ehhez kepest egy java webservice, vagy egy asp.net oldal is inkabb monolite. Felreertes ne essek a monolitnek is megvan a helye a vilagban.
    Mutasd a teljes hozzászólást!
  • Próbálj meg valami mást is megtanulni. Pl. C#, asp.net core, és használni azt úgy egy évig. Esetleg nagyobb (több mint 10 emberéves) projekten. Szerintem te is rá fogsz jönni. Bár, ha valamit ennyire sokáig használtál, arról nem könnyû váltani. Egy dolgot nehéz úgy megítélni ha nem nagyon használtál mást.
    Mutasd a teljes hozzászólást!
  • Írtam is, hogy szubjektív megfigyelés :)
    Ezt eleve elég nehéz objektíven mérni :D
    Mutasd a teljes hozzászólást!
  • Egyszer mondjuk ezt valaki elmagyarázhatná, hogy a PHP miért vonzza be a totál nulla fejlesztőket, miközben más nyelveknél ezen fejlesztők aránya szvsz érezhetően alacsonyabb.

    Én még nem láttam olyan statisztikát, ami ebben az állításban megfogalmazott premisszimát alátámasztotta volna, illetve jobban alátámasztotta volna, mint más nyelvek esetében. Te igen? Akkor kérlek dobj már egy linket rá!
    Mutasd a teljes hozzászólást!
  • Jogos. Ez tipikusan az a téma, ahol mindenkinek igaza lehet egyszerre.

    Viszont ezt a válaszod inkább H.Lillának kellene céloznod. Én bármikor bevallom, hogy PHP vonalon nem mozgok túl otthonosan, ellentétben Asp.Net vonallal. PHP-ban már csak API-khoz buta kis faék SDK-kat fejlesztek full primitív PHP fejlesztőknek. Egyszer mondjuk ezt valaki elmagyarázhatná, hogy a PHP miért vonzza be a totál nulla fejlesztőket, miközben más nyelveknél ezen fejlesztők aránya szvsz érezhetően alacsonyabb.

    Én csak leírtam neki, hogy a PHP-nek nem az az előnye, a nagy keretrendszereknek pedig nem az a hátránya, amit ráadásul az ezek szerint hiányos tudása alapján gondol. :)

    Egy alap PHP telepítés esetében igaza lehet, más kérdés, hogy neked is igazad van, mert lehet úgy konfigurálni, futtatni a PHP-t, hogy Lillának ne legyen igaza :D
    A PHP egyik nagy előnye szvsz pont ez a fajta lazaság (ami egyben hátránya is, bár manapság a konténerizációval ez kb. lényegtelenné vált), hogy akár csak futtatni, konfigurálni is kismillióféleképpen lehet.
    Mutasd a teljes hozzászólást!
  • Az említett nagy enterprise webes környezetekben ugyanúgy a request idejű élettartam a default (sőt DI esetében a default a használat erejéig tartó scope, ami jellemzően a requestnél is rövidebb idő). Csak épp HA akarod, akkor faék könnyen memóriában tudod tárolni a dolgokat hosszú időn keresztül is. 

    PHP esetében is. Már nem is tudom mióta (de legalább 6-7 év óta) van erre (is) alkalmas default op- és memcache is az alap disztribúcióban is, de előtte is évtizedek óta volt hozzá azon kívül. Olyan processzt írni benne pedig, ami kérésektől függetlenül kvázi állandóan fut, szintén időtlen idők óta lehet PHP-ban is.

    Ugyanakkor ennek igazából semmi köze a nyelvhez, ahogy mellesleg "enterprise webes környezetben" sem, mert nem annak, hanem az alkalmazott keretrendszer vagy futásidejű környezetnek a képessége ez. 

    Sőt, ez sem igaz igazából, mert pl. az adatbáziskezelőket vagy meghajtókönyvtáraikat is általában meg lehet kérni query cache-elésre vagy akár memóriatáblák kezelésére, amik mellett elmosódnak az adatéletciklus határai, és amely módszerek lehetnek ugyanolyan hatékonyak vagy akár hatékonyabbak is - attól függően mire és hogyan használja az ember - mint a platform által valamiféle perzisztencia vagy szerviz jellegű futás céljára biztosított eszközök.

    Szóval ez kb. megint jó példája annak, amikor azért néz ki kevesebbet a PHP-ből, mint amit az valójában tud, mert egyrészt nem is tudja mit tud a PHP, vagy annál hogyan lehet megvalósítani egy adott gyakorlati koncepciót, másrészt mert még az általa preferált eszközök esetében sincs igazából tisztában a koncepcionális háttérrel.
    Mutasd a teljes hozzászólást!
  • Azért nem, mert a szerveren nem fut a PHP, csak a request ideje alatt. Ott mondjuk az apache, vagy az nginx fut állandóan, mint service. Ezzel szemben egy node.js esetén a node.js alkalmazás fut és az kezeli a requesteket, az tartalmazza a webszervert is. Ami elkészült adat vagy objektum vagy osztály példány, az ott van készen a memóriában, nem táblában, nem adatbázisban, nem fileban, hanem a memóriában. Nem kell újból és újból az egészet inicializálni, vagy példányosítani.
    Persze készíthetsz saját PHP webszervert, de ez nem annyira ismert eljárás PHP esetében.
    Mutasd a teljes hozzászólást!
  • Szia,
    röviden és tömören: eddig mindent meg tudtam benne csinálni, amire szükségem volt. Írtam benne egy saját "keretrendszert", amivel 100+ weboldalt készítettem már el az évek során. Kvázi egy saját igényekre alakított "wordpress" vagy "wix" vagy bármi ilyen "felületről összekattintható" weboldal készítő. De én a konkrét rendszert csináltam meg, nem pedig azt használva weboldalakat.
    Idővel kinőtte magát olyanra, hogy könnyedén át tudtam alakítani ennek a tartalomkezelő rendszernek az adminisztrációs részét arra, hogy bármi komolyabb/összetettebb, több felhasználós zárt webalkalmazást csináljak (kórházi rendszerek, kutatás-fejlesztéshez használt webalkalmazások...stb).

    Az tetszik a nyelvben, hogy könnyen lehet dinamikusan változó "végeredményt" generálni a weboldal kódjában. Egyszerűen bele lehet építeni bármi js framework-öt, ami javítja a felhasználói élményt.
    Nekem a szintaktikával semmi bajom, szerintem könnyen átlátható.

    Kb :)
    Mutasd a teljes hozzászólást!
  • Szia,

    En nem php teruleten dolgozom. De ha mar feldobtad a temat, megtudhatjuk, hogy mi az amiert te tobb, mint 20 eve preferalod? Mi az amit szeretsz benne vs mi az ami idegesit, lehetne jobb? Elonyok/hatranyok mas piaci szereplokkel szemben? Van olyan, amit a mai napig gyermekbetegsegnek tartasz, ennek ellenere megis ugy szereted ahogy van?
    Az is jo, ha az a valasz, hogy imadod a szintaktikat :)
    Sok nyelvet lehet szeretni

    Udv
    Mutasd a teljes hozzászólást!

  • Milliószor cáfolt hülyeségek tárháza, aminek jelentős része már akkor sem volt igaz, amikor a cikk született (csak a szerző nem értett a PHP-hez, illetve úgy általában a dinamikus programozáshoz), azóta meg már a maradékból is kb. semmi sem igaz már a nyelvre.
    Mutasd a teljes hozzászólást!
  • kíváncsi lennék arra, hogy miért van az hogy állandóan ekézik a php nyelvet?Valaki mondjon már konkrétumot, hogy miért is “gáz, rossz, gagyi… stb” a php nyelv?

    PHP: a fractal of bad design / fuzzy notepad

    Őszintén megvallom, hogy én magam PHP-ban pár sornál többet nem írtam, a fentiek valószínüleg sokat javultak már azóta, viszont rettenetesen jót szórakoztam az irományon. Elég precíz :)
    Mutasd a teljes hozzászólást!
  • Lazy load fecth-el 2 sor (esetleg nemi css), es nem kell hozza semmilyen JS library.
    De persze meg lehet csinalni szepen JS-el. En is nagy baratja vagyok a JS-nek, csak az nem szimpi, mikor keretrendszerekkel hatalmas JS-eket epitunk, jo sok dependenciaval.
    Plusz ha szerver oldalon is JS van, akkor meg plane van ertelme.
    Mutasd a teljes hozzászólást!
  • Lazy load, tree-shake JS oldalon mára nagyon elterjedt. Azaz ha nem vagy leragadva, akkor bizony manapság már JS oldalon is csak az van behúzva, ami éppen kell.
    Mutasd a teljes hozzászólást!
  • "Ugyanakkor pont amiatt, hogy nem long-running a program, hanem csak egy request kiszolgálásáig él, nagyon sok olyan problémát megold - ha figyelsz a programod tervezésénél - amire extra odafigyelés szükséges a nagy enterspájz webes környezetekben (ASP.NET Core, Spring stb.)."

    Nem tudod, hogy mit beszélsz :D Az említett nagy enterprise webes környezetekben ugyanúgy a request idejű élettartam a default (sőt DI esetében a default a használat erejéig tartó scope, ami jellemzően a requestnél is rövidebb idő). Csak épp HA akarod, akkor faék könnyen memóriában tudod tárolni a dolgokat hosszú időn keresztül is. Ez nem hátránya ezeknek a rendszereknek, hanem óriási előnye.
    Mutasd a teljes hozzászólást!
  • React mennyiben is koveti az "objektumorientált paradigmát" ?
    Amugy megertem a posztolot, de a vilag mar csak ilyen, mindenutt vannak fikagepek, ha Angulraozni akarnak am tegyek, az ugy is zsakutca Elleben az UK -ban a php programozok keresnek a legjobban.
    Mutasd a teljes hozzászólást!
  • Véleményem szerint sokakban az a kép él, hogy PHP-ban készülnek a leggagyibb/legfejleszthetetlenebb apik.
    Ennek az egyik oka a php engedékenysége miszerint spagetti formában is lehet benne dolgozni nem követeli meg az objektumorientált paradigmát, lehet profi de agyrém kódot is produkálni. 
    Backend rendszerekre a mai napig tökéletes, noha az tény hogy ha websocket, ffmpeg vagy hasonlókra van szükség ezeket eléggé "baltás" módon lehet kivitelezni, ilyen esetekben célszerű inkább a nodejs-t választani..
    A frontendhez manapság én inkább valamilyen erre tervezett framework-ot használnék..
    Mutasd a teljes hozzászólást!
  • Én azért elég sok js-t és komplex css megoldásokat alkalmazok a munkáimban, viszont pont amit írtál (és ahol mindig megszakad a lelkesedés egy másik technológiánál), a dinamikus, kismillió feltételtől, jogosultságtól függő kód felépítés.
    Simán lekérdezi a kód egy osztály metódusban hogy pl van-e jog erre arra és attól függően include-ol be az ember akár egy egész komponens működtető php kódot vagy tesz ki gombokat ide oda…
    Mutasd a teljes hozzászólást!
  • 1. Azt gondolják, hogy reszponzivitást csak jQuery és társaival lehet megoldani. CSS-sel tán kicsit bonyolultabb (egyes esetekben ). Ezt egyébként egy fordítóprgrammal is meg lehetne oldani, mint régen a C -ben ( némelyikben) , hogy volt egy C -> ASM fordító, aztán egy ASM -> OBJ , aztán egy lineklő.
    2. MVC miatt. Ezt is meg lehetne fordítóval oldani.

    Én direkt csak minimum szinten használom JS-t és társait.

    Mennyivel egyszerűbb egy include('fejlec.php'); mint ugyanez javascriptben.

    Találkoztam már olyannal, hogy nagy nemzetközi cég honlapja nem működött egy olcsó telefonon JS miatt.
    Mutasd a teljes hozzászólást!
  • De ha meg nincs JS, akkor ott az a halom HTML kód, ami többszöröse is lehet a JS-nek.  Ráadásul a  HTML-es esetben a HTML az ami dinamikusan változik, míg a JS futhat statikusan akár egy másik kiszolgálóról is, csak az adatok cserélődnek. A JS-t a kliens elkesseli, az adatokkal együtt jövő HTML-t meg nem lehet. Persze nyilván mindennek megvan a helye, ha csak egy cég/személy bemutatkozó oldaláról van szó, akkor nincs érelme a pár bytenyi oldalra felpakolni mondjuk  a több megás Angulart.
    Mutasd a teljes hozzászólást!
  • Ez azert osszetettebb, a one page appokkal betoltesz egy holom olyan dolgot is amit az user lehet soha nem hasznal, es igy lesznek 1.5 Mbyteos JS-ek. PHP-nel ugyan mindent ujra toltesz, de  joval kisebb a szkop a felepitesbol adodoan.
    Mutasd a teljes hozzászólást!
  • Igen, itt van az is a repóban.

    symfony-rabbit-appserver/RequestConsumer.php at master · Padam87/symfony-rabbit-appserver

    Csak átadja a requestet a kernelnek, pont úgy mint gyárilag, ezért drop-in replacement tudna lenni elvileg.

    Ugyanúgy a controllerek dolgozzák fel: symfony-rabbit-appserver/DefaultController.php at master · Padam87/symfony-rabbit-appserver
    Mutasd a teljes hozzászólást!
  • Erdekes elgondolas. Lehet gRPC jobban megerne, tippre gyorsabb mint rabbitmq-n keresztul. Amugy a consumer is symonfy-s volt?
    Mutasd a teljes hozzászólást!
  • Még 16 ban, just for fun jelleggel csináltam egy olyan projektet symfony alapon, ami nem direktben generálja a responset, hanem egy rabbitmq RPC call-t tol le, amit a háttérben futó (szintén PHP) consumer dolgoz fel, és válaszol rá.

    GitHub - Padam87/symfony-rabbit-appserver
    TLDR: request per second 188 vs 280-300

    Érdekes kis teszt volt, lehet ideje lenne egy frissített verziót PHP8 al, opcache preload-al letolni. Szerintem mára ez a különbség jelentősen csökkent.

    (Persze azóta vannak erre dobozos megoldások is, mint a PHP-PM)
    Mutasd a teljes hozzászólást!
  • Ne lass mindenhol szoget, mert kalapacs van a kezedben ;)
    Mutasd a teljes hozzászólást!
  • kíváncsi lennék arra, hogy miért van az hogy állandóan ekézik a php nyelvet?Valaki mondjon már konkrétumot, hogy miért is “gáz, rossz, gagyi… stb” a php nyelv?


    Mert nem értik, hogy amiket hátrányként rónak fel, az egyben az előnye is. Ilyen pl. a shared nothing aspektusa a nyelvnek.

    Nyilván nem véletlenül használja sok top weboldal is.

    Ja a lényeg kimaradt az okok közül: ha szidod a PHP-t (annak ellenére, hogy tök hülye vagy hozzá), akkor automatikusan jobb programozóvá válsz bizonyos körök szemében... :)
    Mutasd a teljes hozzászólást!
  • A PHP és alapvetően a Web legnagyobb hibája a "felesleges" ismétlődő műveletek.

    Itt azért nem szabad összekeverni a PHP-t általában a Webbel. A PHP kéréseknél tényleg minden "nulláról indul" (persze ott is van mindenféle cache a háttérben, hogy pl. a fájlokat ne kelljen mindig elölről interpretálni), de ez nem törvényszerű minden webes környezetben. Java környezetben például hosszan futó kiszolgáló JVM processz van, amin belül külön-külön szálon megy az egyes kérések kiszolgálása. A framework elemei egyszer inicializálódnak (vagy az alkalmazás indulásakor, vagy az első kérés hatására), illetve egyszerűen lehet a memóriában cache-elni dolgokat a későbbi kérések kedvéért.

    Mindkettőnek van előnye és hátránya. PHP-ban nagyon nehéz bármi erőforrást szivárogtatni és nincsenek konkurencia problémák, cserébe minden kérésnél fel kell építenie a környezetet. Javában oda kell figyelni a szálbiztonságra és az erőforrások felszabadítására, de cserébe nem kell egy csomó dolgot újra és újra lefuttatni.
    Mutasd a teljes hozzászólást!
  • Először is, szerintem a legjobb nyelv BackEnd oldalra, egyszerű - rugalmas, rengeteg lehetőséggel

    Egy bizonyos meretig(mind kod mint rajta dolgozo fejlesztok szamat tekintve) + ha nem kell evekig maintain-elni. Ha ezek kozul legalabb egy nem teljesul akkor a forditas ideju tipusok hianya miatt a rugalmassaga inkabb hatrannya valik(persze ezen segit pl a HHVM+type hints).
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd