Ú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
Hirdetés
- Hyundai, Kia topik
- Android alkalmazások - szoftver kibeszélő topik
- Nyaralás előtti hardverszemle
- Apple Watch
- Azonnali notebookos kérdések órája
- Temu
- Battlefield 2042
- Luck Dragon: Asszociációs játék. :)
- zebra_hun: Hűthető e kulturáltan a Raptor Lake léghűtővel a kánikulában?
- iPad topik
- További aktív témák...
- BESZÁMÍTÁS! Gigabyte B650M R7 7700 32GB DDR5 1TB SSD RTX 5070 12GB BE QUIET! Pure Base 500DX 650W
- Nintendo Switch OLED 20.1.1 okosított Dual-Boot Cfw + 256GB MicroSD + Atmosphere 1.9.1, 3 hó garival
- BESZÁMÍTÁS! Gigabyte A620M R5 7600 32GB DDR4 512GB SSD RTX 5060 Ti 16GB Zalman i3 NEO Enermax 650W
- BESZÁMÍTÁS! ASUS Z390 i5 9500 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA Thermaltake 500W
- BESZÁMÍTÁS! MSI B450 TomaHawk R5 5600X 32GB DDR4 512GB SSD RTX 3060 XC 12GB Rampage SHIVA 600W
- Bomba ár! Lenovo ThinkPad X395 - AMD Ryzen PRO 5 I 8GB I 512GB SSD I 13,3" FHD I Cam I W11 I Gari!
- BESZÁMÍTÁS! Gigabyte H610M i5 13400F 32GB DDR4 512GB SSD RTX 3070 8GB Zalman Z1 Plus Enermax 750W
- Noblechairs HERO RL valódi bőr Gamer Szék
- Felújított számítógépek/merevlemezek Számlával, garanciával! Ingyen Foxpost!
- Xiaomi Redmi Note 10 Pro 128GB Kártyafüggetlen, 1Év Garanciával
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest