total 10767,79122 sec
sql 9872,687725 sec
php 895,1034923 sec
Kb. ennek megfelelő mértékben érdekel, hogy mennyire lassú a PHP.
- saxus blogja
- A hozzászóláshoz be kell jelentkezni
- 1755 megtekintés
Hozzászólások
Annál jobban kellene érdekeljenek az explain planek ;)
- A hozzászóláshoz be kell jelentkezni
Nyilván, csak mikor ilyen számok jönnek ki, akkor nem tudom komolyan venni azt, mikor valaki csak azzal tud jönni, hogy a PHP az lassú.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Itt az a kérdés, hogy a logikát mi végzi el. Az SQL szerver rögtön olyan adatokat tol vissza, ami szinte egy az egyben mehet ki az oldalra, és a PHP csak közvetít, vagy a SQL szerver csak nyers adatot tol ki és a PHP végzi a feldolgozás részét.
A második eset egyértelmű, az első esetben meg kéne vizsgálni azt is, hogy mi történne, ha a logika nagy része PHP-ban lenne írva.
- A hozzászóláshoz be kell jelentkezni
Logika 99%-a PHP-ben van, max 1-2 maradvány trigger, meg 1-2 tárolt eljárás. Szimplán összetettek a query-k.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
sub, már várom a flame-t :)
Ha tippelnem kéne a válaszok:
* rossz DBMS-t használsz
* rosszul írtad meg a lekérdezéseket
* rosszul tárolod az adatokat (aztán jönnek pro és kontra a normalizálás és indexelés viták)
* biztos rosszul van konfigolva a storage/rossz a hálózat, mert X DBMS az tökéletes
* ...
BlackY
- A hozzászóláshoz be kell jelentkezni
Igeeeeeeen, holott az egésznek nem ez a tárgya :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Az mindegy, de jól ki lehet siklatni a szálat ezekkel az "érvekkel" is.
- A hozzászóláshoz be kell jelentkezni
* krva sok adatot tárol
- A hozzászóláshoz be kell jelentkezni
* NoSQL-t kellene használnod, az sokkal jobb
* flat fileokat kellene használnod, az sokkal jobb.
* memcached
- A hozzászóláshoz be kell jelentkezni
* a fájlrendszer túl nagy overhead, block device-t kéne használnod fix hosszú rekordokkal
szerk.:
** természetesen a kezelőt assemblyben írva, egy C overheadje túl nagy
BlackY
- A hozzászóláshoz be kell jelentkezni
Tényleg...
* rosszul értelmezte a követelményeket és feleslegesen tárol gyakorlatilag zajt, dobja el a táblák felét
BlackY
- A hozzászóláshoz be kell jelentkezni
Eldobtunk néhányat a legutóbbi átalakítások, fejlesztések soran, mikor kidobaltunk nehany regi dolgot :)
Sot, képzeld, azota felugrott a CPU használat 2x-esete! :))
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
:D
Dobj el még több táblát, akkor még gyorsabb lesz :)
BlackY
- A hozzászóláshoz be kell jelentkezni
De hat lassabb lett! :))
A teljes sztori azert kiegeszitesre szorul: eddig ugy altag 150-200% kozott mozgott a CPU hasznalat atlagosan (valami 2009 koruli 2xQ Opteron), kis kiugrasokkal, ami most a kb. egy honappal ezelotti "icipici" update soran (ahol a felszin alatt jo sokmindent meg kellett varialni -- de legalabb volt lehetoseg egy-ket nagyon regi dolgot kidobalni is) jol meg is lett dobva ugy 250-350 korulire. Na meg jott megegy szolgaltatas a gepre, igaz ott egyelore tobb terhelest okoz a backend melo, mint a frontend (remelhetoleg csak jelenleg :). Es mivel elegge SOS melo volt az egesz, igy hat optimalizacioval nem igazan torodtunk, mert fontosabb volt a feature, minthogy most negyede vagy harmada van kihasznalva a gepnek.
Persze, majd muszaj lesz itt-ott, mert 1-2 dolog, ami eddig a meg nem rossz sebessegkategoriaban volt, az most atcsuszott az ez mar picit cink kategoriaba. Emiatt kezdtunk el most mericskelni. (Na meg mert kollega egy hete kirakott valamit, ami csunyan megugrasztotta olyan 500-650%-ra, amit mar kezdtem sokallni, es le kellett vadaszni, hogy mi baszodott el :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Így már ok, csak a "Sot, képzeld, azota felugrott a CPU használat 2x-esete! :))"-ről azt hittem, hogy eddig idle-ben malmozott a program, amíg várt a db-re, db-t megfelezted, így kevesebb io-ra várás -> magasabb kihasználtság.
BlackY
Szerk.: Amúgy egyre kevésbé vagyok biztos abban, hogy lejött, már az eredeti postban is a képzelt trollok várható érveit írtam arra, hogy de miért szar mégis a PHP.
- A hozzászóláshoz be kell jelentkezni
* fel kéne venni Mancikát, hogy készítsen minden lehetséges kimenetre egy statikus HTML oldalt, majd pedig: miért nem nginx-et használsz?
- A hozzászóláshoz be kell jelentkezni
Nem te kardoskodtál amellett a minap, hogy igenis a PHP lassú, mert nem lehet alkalmazás szerverként működtetni, nem lehet bájtkódra fordítani stb.? ;)
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Nem pont azt mondta, hogy ha lehetne AS-ként futtatni, akkor nem kellene ennyi DB lekérdezést indítani?
- A hozzászóláshoz be kell jelentkezni
Nem teljesen, de most mobilon vagyok, nem akarom részletezni.
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Pedig de, pont azt mondta. Azt mondta hogy alapbol nincs gond a PHP sebessegevel, de van, amit eselytelen benne gyorsra megirni (amihez app server kene, cache-eles felmegoldas db query-k szamanak csokkentesere)
- A hozzászóláshoz be kell jelentkezni
Na azert ezt sem irnam ala, van az a szint, ahol mar szamitott es at lett irva masra, mert tul sokaig futott valami nagyobb matekolas.
De amikor a PHP sebessegere hivatkoznak, akkor csak ezt tudom mondani: ameddig sokszor nem is a PHP a szuk keresztmetszet, addig nem erdekel. Ezt jol ismerem, meg mindig (sokkal) tobb a koder hozza, mint a pythnohoz vagy a rubyhoz (amiket sebesseg szempontjabol megint vicces emliteni, merthat azok is interpretaltak. Ok, tudom, abbol is van olyan, ami valami koztes kodra fordit, de most azokat hagyjuk.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Csak a korrektség miatt, van JIT-es Python is. Sebesség adatok.
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
És van .net-es változata is.
Szépséghibája mindkettőnek, hogy adódnak kompatibilitási gondok velük bizonyos esetekben.
(konkrétumot ne kérj! Rég volt, nem igazán emlékszem a részletekre)
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Bocs, nem néztem a linket, én a jythonra gondoltam.
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Cserebe meg kevesebb koder, mint PHP-hez. Ezt a szempontot valahogy szeretik egy-egy nyelv fanjai figyelmen kivul hagyni, holott nagyon nem elhanyagolhato szempont.
Es amikor ezzel az akar 6x-os gyorsulassal is osszessegben kb. 6-7%-ot nyerhetunk (bar gyanitom ez egy atlagertek), akkor tovabbra sem latom egy percig sem indokoltnak, mert HW igeny egy centivel sem lesz kevesebb (arrol nem is beszelve, hogy boven nincs kihasznalva a gep fele), az oldal meg nem lesz latvanyosan gyorsabb.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem baj, ha picit kötekszem?
Akkor mire véljem a múltkori PHP "fikázásodat"? ;)
(gyk: "kötekszem" + smiley!!! - mielőtt még véresen komolyan vennéd!)
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Talan, ha felfogtad volna egy minimalisan is, akkor nem poenkodnal itt most ekkora arccal.
HA lehetne a PHP-t normalisan AS-kent futtatni, ugy, hogy a worker _threadek_ kozott egy szep nagy osztott memoriaban ott lenne egy csomo adat elore betoltve, AKKOR az adatbazis muveleteink jelentos reszet meg tudnank sporolni, amivel a 90%-nyi terhelest ami az adatbaizra esik le lehetne csokkenteni mondjuk 30-40%-ra. Es akkor mondjuk nem 1:10 aranyban oszlana meg az adatbazis terheles 11 egysegnyi osszidovel, hanem 1:4 aranyban 5 egysegnyi osszidovel.
De mivel a PHP erre _gyakorlatban_ nem alkalmas (az, hogy elmeletben egy irrealis, es messze nem uzembiztos modon van ra lehetoseg, hogy ha osszetakolod mindent magadnak, az nem megoldas), emiatt kenytelenek vagyunk mindig mindent kiszipkazni adatbaizsbol.
Ezt "fikaztam" a PHP-ben (bar inkabb csak tenykent kozoltem), nem a sebesseget.
De ugy latom, neked nehezedre esik felfogni a kulonbseget akozott, hogy *egy* adott nyelv sebessege milyen es akozott, hogy *tobb* rendszerbol a kulonbozo kepessegeik kihasznalasaval milyen sebessegu rendszert lehet epiteni.
Avagy hup certificated autos hasonlat: hiaba van neked egy ferrarid, amivel tobb korben is elviszed ugyanazt, ha neked egy IFA-ra van szukseged, amivel egyszerre elviszel midnent es nem kell folyton oda-vissza szalingozni.
De semmi gond, egesd csak tovabb magad.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Na jó, hagyjuk... ez már a totális sötétség. :DDDD
Nem keresem vissza az eredetit, volt egy elejtett megjegyzésed, hogy önmagában a PHP is szar, mert nem lehet bájtkódra fordítani (vagy az nem te voltál?)
Erre nyitottad ezt a topikot, hogy mégis jó az a PHP, mert az SQL műveletek sokkal több időt elvisznek.
Mindegy, nincs jelentősége. Ennyi elborult "agyú" alakot rég láttam egy oldalon. :DDDD
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Azt a reszet felfogtad, hogy ha mukodne AS-kent a DB muveletek felet-ketharmadat meg lehetne sprolni? :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
MONDD B+! MEKKORA BETŰKKEL ÍRJAM, HOGY SMILEY?????
:D
Amit írsz az csak egy része volt annak a társalgásnak.
De mint említettem volt, írtál olyat is, hogy bájtkód hiánya. Annak meg semmi köze ahhoz amivel most magyarázkodsz.
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Ne cibald ide a bajtkodot. Semmi koze ehhez a temakorhoz.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Mondom: attól kezdve, hogy nem fogod fel a smiley jelentőségét, szerintem az egész szál értelmetlen.
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Nem baj, ha picit kotekszem?
Szarom le a szmajlid, ne probald arra fogni, hogy fogalmatlanul osztod az eszt egy olyan temaban, amihez halvany lila fingod sincs. ;) SZMAJLI!!!1111111
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Az a baj öcsi, hogy te szimplán agresszív vagy és hülye. Én meg csak szórakozok. Rajtad is.
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
^- utokornak megorizve.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Egészségedre! :D
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Temahoz valami, chief php architect ur? Oh wait...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Hogy a "leszarom" szövegű hozzászólásodat is őrizd meg az utókornak! :D
Te, kis mindentudó!
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Nem tehetek rola, hogy idejossz trollkodni mikor ketten is megmondtak rajtam kivul, hogy fassaggal jossz. Aztan most egy szmajlira hivatkozva probalod letagadni a fogalmatlansagod.
Masreszt, jo lenne, ha egy picit visszavennel az arcodbol es magadba neznel, mert szerintem nem en kezdtelek el sertegetni teged.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Felfogtad, hogy
1. Egy hozzászóláson belül volt a smiley és a "fasság"? Nem utólag magyarázom.
2. Végeredményben amire utaltam, az megtörtént: fikáztad a PHP-t, most meg gyakorlatilag véded.
Magyarán te sem tudod eldönteni, hogy mit is akarsz.
A trollkodás az az, amit te csinálsz, meg itt alattam ez a két izé.
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
2. Az a problema, hogy nem fogtad fel legutobb se, hogy _mit_ fikaztam a PHP-ben: a sebesseget is megemlitettem, de leginkabb a normalis AS hianyat. Sebesseg alatt egyebkent uzleti szempontbol erdekesebb tud lenni sok esetben az oldal sebessege, mintsem az, hogy mennyi az adott nyelv eroforras-igenye (ami kozott ordas nagy kulonbseg lehet).
Es ha vegre megertened, hogy ha a PHP tudna azt, amit en mondtam (hogy elore be lehessen tolteni egy csomo adatot es perzisztensen a memoriaban tarolni), akkor _az oldal_ lehetne lenyegesen gyorsabb, mivelhogy rengeteg SQL kerest meg lehetne sporolni. Ezen kijelentesemet pontosan az alapjan tettem, hogy mar akkor is ismertem azt, hogy nalunk kb. ilyen aranyok voltak, csupan nem volt a kezemben aktualis meres. n
Attol meg a PHP egy Java/.NET-hez kepest lassabb lenne, es ugyanugy egy alapvetoen lassu nyelv maradna, de az alkalmazasunkbol ki tudnank utni rengeteg lekerdezest, ahol a PHP nem csinal mast, csak az adatbazisra var. De ezzel az alkalmazasunk gyorsulna. Nem tudom, hogy ezt meirt olyan nehez megerteni.
Viszont, ameddig ebbol azt az egybites kovetkeztetest vonod le, hogy multkor a PHP-t fikaztam, most meg vedem, addig erdemi vitara nincs lehetoseg koztunk, sorry.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Te nem fogod fel, hogy piszkálódásként, poénként beírtam ide valamit és már fél napja azon rugózol, hogy mekkora fasság.
Úgy látszik, sokat ittam, mert azt képzeltem, hogy benned még van nyoma némi humorérzéknek.
Hogy nincs, arról nem én tehetek.
ui: az egyéb részleteket, ha folytatni óhajtod, az adatlapomon elérhető a privát üzenet, folytassuk ott, mert unom, hogy folyton olyanokat kell kerülgetni, akik az előzményekről sem tudnak. (egyébként már korábban is felfogtam, még abban a másik topikban, felesleges milliószor ismételgetni)
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Ha felfogtad volna, itt nem okoskodtal volna. Azzal nem leszel humoros, hogy irrelevans dologgal jossz.
Avagy, ha mar trollkodni akarsz, csinald jol.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"agresszív vagy és hülye"
Te meg nyugodt es helikopter ;)
- A hozzászóláshoz be kell jelentkezni
:D
Ez tetszett.
BlackY
- A hozzászóláshoz be kell jelentkezni
1. Senki sem vitatta a PHP kóderek számát.
2. Vagy nem tudsz angolul, vagy szándékosan csúsztatsz ezzel az "akar 6x-os gyorsulas" fordításoddal.
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
"The geometric average of all benchmarks is 0.16 or 6.2 times faster than CPython"
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
A legszebb, hogy alatta ott van a grafikon, egyértelműen 1.0-nak állítva be a CPython 2.7-et és egyértelműen feliratozva 6.19-el a PyPy-t. Tehát angol tudás sem szükséges, és csúsztatni sem lehet ugyanezen számok felhozatalával, de te nem tudsz angolul és eleve csúsztatsz :)
BlackY
- A hozzászóláshoz be kell jelentkezni
Es az a szep, hogy ez akkor igaz, ha pont olyan aranyban hasznaljuk ki, ahogy a fenti grafikonban is megoszlanak a dolgok. Nem lehet ezt igy altalanossagban letudni.
De tfh. nem 6 hanem 7x-ese. Attol, meg ugyanugy a 9%-nyi reszt optimalizalod az egeszbol.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"az akar 6x-os gyorsulassal is osszessegben kb. 6-7%-ot nyerhetunk"
Az átlaggal érvelni konkrét feladat esetén butaság.
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Ezt te "akar 6x-os gyorsulas"-nak fordítod?
A grafikon alapján nem úgy lenne korrekt, hogy átlagosan 6x, de bizonyos esetekben ennél lényegesen nagyobb gyorsulás? (pl. django 0.05)
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Nezd, ha picit tuvabb olvasod, akkor eljutsz odaig, hogy az nalunk meg mindig csak 6-7%, ami nem a 6,2x-es alapjan kiszamolt ertek. Most azon a 0,2-n mar nem sok mulik.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem a nálad kalkulált 6-7%-ot vitattam eddig sem, hanem a pypy sebesség grafikon "fordítását".
--
♙♘♗♖♕♔
- A hozzászóláshoz be kell jelentkezni
Jelezném, a python az importált modulokat "lefordítja" és a fordított kódot futtatja. (lásd még .pyc fájlok!)
Performancia adatokkal nem szolgálhatok, de érzésre gyorsabbnak tűnt, mint a PHP.
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
- A hozzászóláshoz be kell jelentkezni
Igen. Mellesleg ez szerintem boven a negyedere vagna a gyakran hasznalt oldalak generalasi idejet, ami a mi esetunkben nem picit lenne nagyszeru. Igyhat marad a DB optimalizalas.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Erre az egész threadre meg: http://reactphp.org/ :)
BlackY
- A hozzászóláshoz be kell jelentkezni
A facebookos PHP-s JIT-es fordítós HHVM-et kipróbáltátok? Az írt 6-szoros teljesítménynövekedés egész jól hangzik.
Nem tudom, mekkora változtatást jelentene egy ekkora kódon (ha egyáltalán), de ha már a DB-n nem lehet kis energiával javítani, akkor lehet érdemes kipróbálni.
- A hozzászóláshoz be kell jelentkezni
Ami nagyon hasznos lenne, mert így a mostani 10767 másodperc helyett 9872+(895/6)=10021 másodperc lenne. Bőven jó ezért lecserélni a de facto szabvány futtatókörnyezetet.
BlackY
- A hozzászóláshoz be kell jelentkezni