Vsi z založniki na čelu, pri Adsensovih cenah ;)

Eclipse + PDT

Poglej si Štamcarjev tečaj za PHP: http://www.stamcar.com/ (v seznamu FRI PHP tečaj).

Lucifix:

Ampak ali ne že preko te vrstice prek PHP-ja izvršimo zahtevek ali je to drugače?

$img_src = "image/sample.png";

Hvala za odgovor!

To ni request, v tem stavku samo nastaviš ime datoteke v vrednost spremenljivke.

V vrstici

$imgbinary = fread(fopen($img_src, "r"), filesize($img_src));

pa iz te datoteke lokalno prebereš vsebino datoteke v string. Enako lahko narediš z

$imgbinary = file_get_contents($img_src);

V bistvu pa ne vidim preveč smisla za tako uporabo. Dobiš bolj obremenjen strežnik zaradi branja v php, več prometa, slabše lahko izkoristiš caching ...

Ni povezava zakodirana, temveč je v HTML kar vsebina slike, enkodirana z base64, zato da nimaš v HTML datoteki binary znakov. Rezultat je en request manj (ker vsebina pride v HTMLju) in za 33% prometa več (ker je vsebina v base64).

REST je precej bolj enostaven in ravno tako "podprt" na vseh platformah.

@SpinX: to znanje je bolj rezultat neprespanih noči, kupa člankov z neta in MySQL dokumentacije, kot knjig :D. Knjige sem prebral samo kakšne osnovne, je pa High Performance MySQL: Optimization, Backups, Replication, and More baje zelo solidna in je tudi na mojem spisku. :)

blackmamba: se priporočam. :)

Jaz se ne bi sekiral zaradi teh časov. Važno, da so pogosti queryji hitri. Si pri meritvah upošteval query cache?

Ena opcija za paging je predpripravljena flat tabela, kamor filaš podatke iz tega queryja, s tem da zavržeš določene specifične pogoje (categoryid), obdržiš pa preverbo na insertedat in action. V njej hraniš samo polja, nujna za prikaz na seznamih. Potem pa po njej za prikaz queryjaš po categoryid in ORDER BY insertedat. Sicer ohraniš ta glavni požrešni del (LIMIT), tako da je vprašanje, koliko pridobiš, se pa znebiš joinov pa še indekse imaš lahko prilagojene branju (torej recimo samo 1 sestavljen index na insertedat + categoryid). Čim manj indeksov, toliko bolje tudi za pisanje, pri branju pa MySQL itak uporabi samo 1 indeks na posamezni tabeli.

Tabelo generiraš tako, da query v ozadju izvajaš npr. 1x na pet minut. Na ta način profitiraš še s query cacheom, ki se drugaže izprazni ob vsaki spremembi tabele (tukaj ti drži do naslednjega rebuilda). Če pa nimaš veliko podatkov, lahko "rezerviraš" npr. 100mb in narediš to tabelo MEMORY, tako da jo ima strežnik kar v ramu. Potreba po indeksih odpade, pa še queryji so super hitri.

Kolikokrat pa se realno izvajata LIMIT 0,21 in 6000,21? Serviraš to obiskovalcem, ali v backendu? Če imaš poizvedb za 6000,21 samo par sto na dan, potem ne izgubljaj več časa s tem.

Ne bo enostavno, po moje. Pri uporabi visokih vrednostih za LIMIT največ profitiraš z indeksom na ORDER BY polju, ker mora MySQL za zapise 6000 - 6021 najprej vedeti vrstni red vseh zapisov do vključno 6021, da lahko potem preskoči 6000 zapisov.

Tole s preverjanjem LIMIT > COUNT/2 je samo ugibanje, ne moreš predvideti, kako se bo stvar obnesla, ko se bo število zapisov spreminjalo. In načeloma MySQL v večini primerov bolje izbere indeks, kot ti, zato bi jaz FORCE INDEX uporabil le, če bi bil res kje velik problem z determinističnim in konstantnim rezultatom (kar tvoj očitno ni, saj se bolje obnese brez njega).

Kako dolgo se ti izvaja LIMIT 0, 21 brez FORCE INDEX? Če je to v znosnem rangu, odstrani to in pusti, da MySQL naredi, kar zna. Drugače pa spremeni pristop (kakšne vmesne predizračunane tabele? - ne poznam problema).