Hirdetés
- Külföldi prepaid SIM-ek itthon
- Google Pixel 10 Pro XL – tíz kicsi Pixel
- Samsung Galaxy S23 Ultra - non plus ultra
- Google Pixel topik
- Fotók, videók mobillal
- Xiaomi 15 Ultra - kamera, telefon
- Samsung Galaxy S25 - végre van kicsi!
- MIUI / HyperOS topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen hagyományos (nem okos-) telefont vegyek?
Új hozzászólás Aktív témák
-
-
#8029
Tele von Zsinór
őstag
wolandino
#8027
Tele von Zsinór
őstag
válasz
wolandino
#8027
üzenetére
Az, hogy az html, js és css fileokat érdemes különválasztani, nem kérdés.
Template-nyelv tekintetében nagyon megoszlanak a vélemények, az egyik oldal (jogosan) arra hivatkozik, hogy tkp. a php maga is egy template-motor, a másik oldal viszont nagyon okos kibővítéseket tud, és valóban nagyon tudja egyszerűsíteni a templateket (na meg a designernek sem kell megtanulni php-ul).
Kipróbáltam a smartyt (és nem többesszám, mint nálad), nem győzött meg.
Nagyon sokáig tiszta php-t használtam a templateimben, kis odafigyeléssel: nem nyúlok már adatbázishoz (ami kell, azt megkaptam a controller rétegtől), illetve vezérlési szerkezetekben az alternatív szintaktikát használtam.
Mostanában fedezem fel magamnak a twiget, nagyon tetszik, még meglátjuk, hosszútávon beválik-e. Persze sokat segít, hogy beépített támogatása van az általam használt keretrendszerben.
-
válasz
wolandino
#8024
üzenetére
Szia! Én nem nagyon értem mit szeretnél. Ha jól tudom a Codeigniter nem tartalmaz külön "template engine" -t. Ez esetben javaslom a Smarty használatát, hogy el tudd különíteni a nézeteket. Természetesen a Controllerel küldöd ki a nézetet, de a nézetben már nem lesz semmi php, max változó név.
-
#8014
Peter Kiss
őstag
wolandino
#8008
-
#7882
Sk8erPeter
nagyúr
wolandino
#7880
Sk8erPeter
nagyúr
válasz
wolandino
#7880
üzenetére
Igen, gyorsabb lehet. De most itt már kicsit keverjük a dolgokat... Eddig csak arról volt szó, hogy akkor egyszerre jelenítsd meg az adatokat, és aztán szűkítsd simán kliensoldalon, vagy pedig kevesebb adatot jeleníts meg, és utána a többi adatot AJAX-szal kérd le.
Aztán arra jutottunk, hogy mivel nem egy szervert megterhelő adatmennyiségről van szó, amit annyira nagyon szűkíteni kéne, plusz már megoldottad a kliensoldali szűrögetést, ezért ezen a struktúrán egyelőre (az adathalmaz jelentős növekedéséig) nem is nagyon érdemes változtatni. Ahogy elmondtad, most a felhasználó így is megkapja az ömlesztett és szűrt adatait is, teljes oldalfrissítés nélkül. -
#7879
Sk8erPeter
nagyúr
wolandino
#7877
Sk8erPeter
nagyúr
válasz
wolandino
#7877
üzenetére
"Nyilván a javascript "lassabb""
Már hogy lenne lassabb?
Gondolj bele, AJAX-híváshoz fel kell építened a kapcsolatot a távoli szerverrel, az reagál, feldolgozza az adataidat, majd visszaküldi a választ, és bontja a kapcsolatot. Kliensoldalon meg még fel is kell dolgozni a kapott választ.
A sima JavaScriptes (távoli kommunikációt nélkülöző) megoldással meg eleve csak kliensoldalon kell átrendezni a már megjelenített adatokat, a DOM-ban rohangászva. Ez mindenképp gyorsabb.A Tele von Zsinór átal mutatott jQuery-plugin meg nagyon hasznosnak tűnik.
-
#7878
Tele von Zsinór
őstag
wolandino
#7874
Tele von Zsinór
őstag
válasz
wolandino
#7874
üzenetére
Felhasználóbarát táblázatokhoz ezt szoktam használni: datatables.
Ez egy jquery plugin, táblázatot okosít rendezéssel, kereséssel, elég jól testreszabhatóan. Tudja azt is, hogy megkap minden rekordot és kliensoldalon lapoz/rendez/szűkít, illetve azt is, hogy ajax-szal ugyanezt a szerverre bízza.
-
#7876
Sk8erPeter
nagyúr
wolandino
#7874
Sk8erPeter
nagyúr
válasz
wolandino
#7874
üzenetére
Nem vagyok én olyan tapasztalt róka, de köszi.
Azt kell átgondolni, a felhasználónak milyen adatokra lesz nagy valószínűséggel elsősorban szüksége, ettől függ, melyik a praktikusabb megoldás.
Ha mondjuk a legutóbbi 1 hónapra vonatkozó adatoknál több úgysem fogja az esetek többségében érdekelni a felhasználót, akkor nem is érdemes többet lekérni és megmutatni. A nagyon sok ömlesztett adatot úgyis nehéz átlátni, és azt nem nagyon szeretik a felhasználók, ennek megfelelően kell szűrni. -
#7873
Sk8erPeter
nagyúr
wolandino
#7869
Sk8erPeter
nagyúr
-
#7867
Sk8erPeter
nagyúr
wolandino
#7864
Sk8erPeter
nagyúr
válasz
wolandino
#7864
üzenetére
Ahogy joker írta, erre általános recept nincs, de esetedben mivel a felhasználó számára már jó eséllyel nehezen áttekinthető adatmennyiségről van szó, érdemes lenne széjjelbontani.
A felhasználói élményt mindenképp növeli, plusz a felhasználók valószínűleg nem fognak agyatlanul kattogtatni ide-oda, így nem lesz nagyobb terhelés, mintha teljes újratöltéssel szűrve kapnák meg a látogatók az őket érdeklő adatot.
Szűrni gondolom amúgy is kellene, akkor meg abban az esetben, ha teljes oldalbetöltéssel lehetne megtekinteni az új tartalmat, nem AJAX-szal, akkor meg olyan elemeket is be kellene tölteni, amiket jól megírt AJAX esetén nem (fejléc, lábléc, stb.), így annál meg az jelentene plusz terhelést.
Több a pro, mint a kontra. A felhasználói élmény javítása szempontjából meg mindenképp érdemes lenne belevágni. -
#7863
Peter Kiss
őstag
wolandino
#7862
Peter Kiss
őstag
válasz
wolandino
#7862
üzenetére
Magyarul alapból van egy nagy táblázatod, de, ha változtatják a dátumot, akkor más az eredményhalmazod (első oldalletöltéskor dátumfüggetlen jön le minden)? Mert ekkor lehet AJAX-szolni nyilván, az a legszebb megoldás (de illik biztosítani egy elküldő gombot arra az esetre, ha nincs Javascript).
-
#7773
Sk8erPeter
nagyúr
wolandino
#7769
Sk8erPeter
nagyúr
válasz
wolandino
#7769
üzenetére
"ezért nem akartam betenni, mert ha kiszedem az ordert úgy ahogy van, akkor se sokkal jobb a helyzet, 15 mp körüli."
Ezek szerint nem jött át, mire jó az EXPLAIN...
Azért akartuk látni, mert hátha ott MEGMAGYARÁZZA, hogy mi is az oka, hogy ilyen lassú fostalicska..."és nem szeretnék olyan lekérdezést tenni az alkalmazásba, ami több mint fél másodperc, mert engem már nagyon szokott idegesíteni, amikor többet kell várni."
Hát vazze, miért, szerinted az a normális, hogy max. fél másodperc legyen egy 150 ezres agyonrendezgetett adatmennyiség fájlba (???? ezt sem írtad) exportálása? Komoly adatbázisszervereknél simán, de az nem kevés teljesítményre képes akkor. 15 mp tényleg sok, ezen lehet faragni. De nehogy már napi probléma legyen (vagy ha az, fusson időzítve), és bárki pampogjon egy kicsit több idő miatt, pár másodpercet tud várni, amikor nem kis adatmennyiség kiírásáról van szó...
Mellesleg nem értelek, segítséget kérsz, akkor miért kell ennyire fukarkodni az infókkal. Gondolhatod, hogy nem ebből fogunk itt meggazdagodni, hogy beraksz egy komplett screenshotot az explainről... meg különösebben senkit nem érdekelnek az adataid, csak segíteni szeretnénk megoldani a problémádat.
-
cucka
addikt
válasz
wolandino
#7765
üzenetére
Például ez a részed elég szar:
ORDER BY year(1.date), month(1.date), 2.name
Itt ugye a year meg a month függvény az eredmény összes sorára le fog futni, az eredménye tárolódni fog majd utána 150k értéket még rendezni is kell.
Rendezhetnéd 1.date szerint, az gyorsabb.Az explain eredményét még mindig nem láttuk. Fosol, hogy ellopjuk a táblaneveidet, vagy mi van?
-
#7759
Sk8erPeter
nagyúr
wolandino
#7745
Sk8erPeter
nagyúr
válasz
wolandino
#7745
üzenetére
"explaint is nyomtam:
150k-s tábla 150k lekérdezést ad"
És ez önmagában miért lenne bizonyíték arra, hogy jók az indexek?
Nem értem a logikát."Az indexek rendben vannak."
Ezt honnan veszed? Esélyes, hogy mégsincsenek rendben, azért lassú a query.A többire: ha rejtélyeskedsz, és a lehető legkevesebb infót adod arról, hogy mi, miért, hogyan van megoldva, akkor nem fogunk tudni segíteni... lehetőleg ne tőmondatokban válaszolj, hanem írj le mindent részletesen, akkor érdemi segítséget is tudunk adni.
Pl. hadd lássunk már legalább részletet a query-ből (pastebinre fel tudod nyomni), meg elárulhatnád, milyen mezőid vannak, mi szerint indexeltél.Egyébként az exportálás nem időzítve, cronnal történik? Hanem egy felhasználói felületen?
Mert ha ilyen szinten sok adat van, és úgyis csak exportálás céljára használod, akkor a felhasználó ne sírjon, ha 150k adatra többet kell várnia... Nyilván nem félnaponta exportálgatod az adatokat.
A "chart" alatt itt most mit értesz? Egy Excel-fájlt? Legalábbis remélhetőleg nem egy felhasználói felületen megjelenő valamit...
===
(#7747) Speeedfire : Itt is ír az EXPLAIN-ről és sok hasznos trükkről: [link] (azért linkelem megint ezt a cikket, mert kivételesen nem egy terjengős, felesleges idióta tippekkel teli cikkről van szó...)
-
Coyot
őstag
-
#7677
Sk8erPeter
nagyúr
wolandino
#7675
Sk8erPeter
nagyúr
válasz
wolandino
#7675
üzenetére
Szívesen!
Hmm, hát ez fura. A phpmyadmin nem szokott ilyen lassú lenni. Amúgy milyen szerveren van a cuccotok? Apache?
Az 1280M beállításban biztos vagy? Nem véletlenül szokták lent tartani mondjuk 128M-nál, hanem "önvédelemből" is, nem túl jó, ha a kódod annál többet kajál... 
Persze egy-kétszer elmegy, de akkor is legfeljebb a duplájára állítsd, ne a 10x-esére... -
#7671
Sk8erPeter
nagyúr
wolandino
#7667
Sk8erPeter
nagyúr
válasz
wolandino
#7667
üzenetére
"Az egyik ismerősöm szerint azért lehet, mert az easyphp amit használok nagyon kevés cache-t enged a mysql-nek, és ezért lassú."
Hogy ismerősödet korrigáljam, az EasyPHP-nek ehhez legfeljebb annyiból van köze, hogy milyen default beállításokat tartalmaz a benne foglalt MySQL- és PHP-konfiguráció... Ezt viszont úgy bírálod felül, ahogy akarod. Fogod a my.ini, illetve php.ini fájlt, és tetszés szerint átkonfigurálod.
Az EasyPHP azért nem hibás, hogy bizonyos default beállításokkal érkezik, ha külön-külön telepíted a MySQL-t, PHP-t, azt is pontosan ugyanúgy át kell állítgatni igény szerint.
Az EasyPHP viszont kicsit megkönnyíti a dolgodat, monitorozza egy minta php.ini fájlban a változásokat, és aszerint módosít egy másik fájlt, amit végül is a PHP figyelembe vesz. Aztán újraindítod az Apache-ot, és megvagy.
Vagy ha my.ini-n változtattál, újraindítod a MySQL-t, hogy érvénybe lépjenek a változások.
Ehhez az EasyPHP kínál egy admin-felületet, hogy ezeket az újraindítgatásokat megtehesd (megteheted services.msc-ből is, amennyiben szolgáltatásként vannak telepítve a szerverek).Érdemes lehet beállítani MySQL-ben a query cache-t, valami ilyesmi módon:
query_cache_size = 268435456
query_cache_type=1
query_cache_limit=1048576Elvileg így legalábbis kihasználhatja néhány lekérdezésed a query cache szolgáltatást.
Itt van egy-két trükk még MySQL-hez: [link]. Itt megmutatja azt is, hogy érdemes néha az EXPLAIN-t használni, hogy megkukkantsd, hol lassú esetleg a lekérdezés, pl. valahol nincs indexelve egy mező.(#7668) wolandino: ezt írja: "Allowed memory size of 134217728 bytes exhausted". Eszerint 134217728 byte = 128 MB memória van beállítva nálad. Ezt lépte túl. Az a memóriahasználat sok. Valami nem stimmel a kódodban, ha ennyire leakel. Vagy óriásképeket kezelsz, vagy nem vágom...
-
#7666
Peter Kiss
őstag
wolandino
#7664
Peter Kiss
őstag
válasz
wolandino
#7664
üzenetére
Az SQL szerver cache-ébe nem nagyon szól bele a PHP, szóval tuti, hogy nem ez a baj.
Pár dolgot meg kellene nézni:
Mennyi "vas" is van a szerver alatt (és mi fut még azon)?
Elképzelhető, hogy index-hiányos a lekérdezés.
Optimalizálatlan a lekérdezés.Persze az adatokat PHP-val dolgozod fel, így a programkód is gyenge lehet.
Elég szépen összeszedett jegyzet, pedig igényes magyar nyelven írtakból azért nem lehet Dunát rekeszteni.
Azért akartuk látni, mert hátha ott MEGMAGYARÁZZA, hogy mi is az oka, hogy ilyen lassú fostalicska...
Nem értem a logikát.
Persze egy-kétszer elmegy, de akkor is legfeljebb a duplájára állítsd, ne a 10x-esére... 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Milyen processzort vegyek?
- exHWSW - Értünk mindenhez IS
- Black Friday november 29. / Cyber Monday december 2.
- Battlefield 6
- sziku69: Fűzzük össze a szavakat :)
- Külföldi prepaid SIM-ek itthon
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Google Pixel 10 Pro XL – tíz kicsi Pixel
- Azonnali informatikai kérdések órája
- Microsoft Excel topic
- További aktív témák...
- Dell Latitude 7410 Strapabíró Ütésálló Profi Ultrabook Laptop 14" -80% i7-10610U 16/512 FHD IPS MATT
- Lenovo ThinkVision LFD E65 65" LFD kijelző új
- Legion 5 Pro 16IAH7H Intel Core i7-12700H CPU / 32GB DDR5 RAM / 1TB SSD / Nvidia RTX3070 8GB
- Szép DELL latitude 5420 Tartós Üzleti Laptop 14" -70% i5-1145G7 4Mag 16Gb 256GB SSD FHD IPS
- TP-Link RE700X AX3000 Rage Extender
- Apple iPhone 15 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Panasonic CF-XZ6 AIO all-in-one laptop tablet 2k touch i5-7300u speciális ütésálló rugged
- Gamer PC-Számítógép! Csere-Beszámítás! I7 12700E / RTX 3060Ti / 32GB DDR4 / 512GB Nvme SSD
- LG 55QNED86T3A / QNED / 55" - 139 cm / 4K UHD / 120Hz / HDR Dolby Vision / FreeSync Premium / VRR
- GYÖNYÖRŰ iPhone 15 Plus E-SIM 128GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3355, 100% Akksi
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő