O da, ako je loš query, može ti odaziv biti spor. Probaj jednostavan query napraviti (običan select bez join-a) i tada vidjeti odaziv. Odnah ćeš znati jer server ili loš query.
Da, sa obicnim upitom brzina je da kazem “normalnija”.
Probao sam JOIN upit (preko PhpMyAdmin svugde) za iste dve tabele, sa istim podacima i na drugom VPSu i na shared hostingu i tamo dobijam izvresenje upita bas brzo.
Na shared Stablehostingu: 0.0004 seconds
Na drugom cloud VPS hetznera gde imam VestaCP, nova instalacija: 0.2073 seconds
Dok na ovom sto mi je najsporije, dobijam: 4.2420 seconds sto je previse
Verovatno je nesto lose podeseno na tom VPS (stara podesavanja od pre 3 godine ili vise),
PHP 5.4, Apache 2.2.15
Server version: 5.5.47 - MySQL
isto je VestaCp.
Da li je do starih verzija php i mysql, i/ili je problem i u samim podesavanjima postojecih verzija?
Kako najlakse proveriti?
Kod Ramnode je, a server je u Holandiji.
Pisao sam njima, oni prebacili na drugi “node”, pa sad jos nesto sporije.
Inace, ovo je upit:
SELECT *, k.id as id, k.katid as kid, k.naslov as naslov, k.naslov1 as naslov1,
COUNT( o.id ) AS zbir
FROM `proizvodi_page` `k`
LEFT JOIN `proizvodi_new` `o`
ON (`o`.`idfirme` = `k`.`id` or `o`.`idfirme1` = `k`.`id` AND o.akt='Y' AND o.nalageru=1)
WHERE k.id_page='72' AND k.akt='Y'
GROUP BY k.naslov ORDER BY k.naslov ASC
Kad stavim samo ovako, dobijam istu brzinu svugde priblizno 0.0160:
SELECT *, k.id as id, k.katid as kid, k.naslov as naslov, k.naslov1 as naslov1, COUNT( k.id ) AS zbir
FROM `proizvodi_page` `k`
WHERE k.id_page='72' AND k.akt='Y' GROUP BY k.naslov ORDER BY k.naslov ASC
Uradio sam update mysql verzije u MariaDB
Sad taj jedan upit, sa JOINom ucita ispod secudne, od 0.5 do 0.9, kad ga zadam u phpMyAdminu.
Direktno, na samom sajtu, preko php, kada pozovem taj fajl sa jednim upitom, preko Gtmetrix kao ucita za 0.9 secunde, a na Google speed tulu ne pokazuje gresku da postoji problem sa odazivom servera.
Mada mi nestabilno radi, variraju te sekunde, zna da pokaze nekad i vise od sekunde.
Morao bih i php verziju da nadogradim, ali max na 5.6, jer mi je stariji sajt, nije jos pripremljen za 7, da bih video da li je i do PHP, ali mi se cini da je malo teze to da se uradi.
Mislim da idu jos neka polja, ali generalno, mogu da napisem tacne kolone koje su potrebne, ne mora bas zvezdica, nego mi tako lakse,
Evo probao bez *, ucitava duplo brze
Pravilo (nepisano) je koristiti nazive polja jer se može naknadno ispostaviti puno lakše za debug kad se mijenja kod ili struktura baze/tabele.
Ali ipak izgleda da je najveći problem taj JOIN.
Mislim da mi je poznato bilo da kad su definisane kolone, onda ide i brze iscitavanje, ali nisam praktikovao.
Sam sajt, ne sadrzi joine, osim tog jednog kojeg sam izdvojio u fajlu, svugde su jednostavni i gledao sam da se ne ponavljam sa upitima vec da smestam u niz, pa odatle vucem kad treba.
Inace za ceo sajt, sada, dobijam na Google Speed tulu:
In our test, your server responded in 1.4 seconds
a bilo je pre ovih cackanja 2.2 seconds.
Ostaje mi da probam da nadogradim php, apache i nginx, pa mozda dobijem jos na brzini.
Sklonio sam, za probu ta dva uslova, akt i nalageru, za probu, ali je ista brzina ucitavanja.
Ovo drugo, ne znam vec sta je, a trenutno nema veze, jer mene generalno muci sto iste dve tabele, sa istim upitom, razlicito brzo rade na razlicite VPS-ove i shared hostingu.
Sto znaci da nesto na serveru nije ok.
Da pitam, kako pravis te indexe, da se ucitava brze?
Ja to uradim preko phpMyAdmina, u opcijama koje nudi.
Verovatno moze i drugacije, pomocu mysql upita.
Budi oprezan sa indeksima u zavisnosti od toga kako često praviš insert (vidi ovaj artikal).
U svakom slučaju daju veći benefit nego da je tabela bez njih.
Njihova korist je u iščitavanju (SELECT), dakle dobro osmotri kako su INSERT i UPDATE korišćeni.
Tipa, da li 20 korisnika ima ovlaštenje da napravi insert preko csv fajla sa po 50000 proizvoda svaki itd.
Ima višestruki impakt na zauzeće baze i vremena upisa i izmjene podataka.
Nosi se činjenicom da kol’ko je sporiji unos, tol’ko je brži select i više.
