Autor Zpráva
Nah87
Profil *
Dobry den,

chcel by som sa opytat odbornikov na radu ohladom rychleho nacitavania clankov z databazy.
Mam vcelu uz velku tabulku clankov, cca. 6000 clankov, velkost: 100 MB.

Zaznamenavam pomale nacitavania obycajnych clankov podla ID paramatetra. Teda ak je id=4369, tak jednoducho cez mysql select vypisem ten clanok. Neviem ako je to mozne, ale cim viac je tam tych clankov, tak tak tym to dlhsie trva. Neda sa s tym nieco urobit? nejako to zeefektivnit? Nejake crony, alebo ja neviem co.

Nerozumiem, preco je to take pomale. Trva to aj 5 sekund a pri tom mam najlepsi webhosting.

Dakujem za rady.
keeehi
Profil
Nah87:
Zkus zjistit, zda je to databází. tabulku si zazálohuj, pak v ní vymaž 5990 příspěvků, a zjisti, jestli je vidět nějaký rozdíl, pokud ne, chyba bude jinde.
Joker
Profil
Nah87:
Tabulka o 6000 řádcích a 100MB zase není tolik, aby to mělo dělat nějaké potíže.
I když na tabulku článků mě teda zaráží ten poměr 16 kilobajtů na řádek- co se tam proboha ukládá?

Dál bych se zaměřil zhruba na dva směry:
1. Jak složité dotazy se musejí dělat?
1a. Zkusit si nějaký dotaz zkopírovat a pustit ho například v phpMyAdminu, tam je vidět, jak dlouho ten dotaz běžel
1b. Dát pozor na složitost dotazu, hlavně na kartézské součiny tabulek (JOIN bez podmínky)... pokud tabulka má tisíc řádků, tak tabulka JOIN tabulka JOIN tabulka už je miliarda.
2. Kolik dotazů se musí dělat? Hlavně bych si ohlídal, jestli se někde zbytečně neposílá dotaz do databáze v cyklu
Nah87
Profil *
1.) poznatok: V PhpMyAdmin nacita clanok za 0.0019 sek, u mna na stranke niekedy aj 5 sekund.

Potom som rozmyslal, ze tam mam select na "podobne clanky", ale to ked som vykomentoval, tak som nepocitil ziadny rozdiel. Aj ked aj to nieco bere, pretoze ten select je dost sialeny.

Ale uz som prisiel co to najviac zabera. Je to v pocitani "zobrazeni clanku". Totizto ja ked nacitam clanok, tak chcem zapociti ten clanok, ale ja tam mam kontrolu, ze ked ten isty clovek zobrazi clanok 2x za sebou, tak zapocita iba raz a teda ja najskor nacitam selectom, ci tam nahodou poslednu hodinu nebol en uzivatel na tom clanku a az potom to zapocitam. Dufam ze chapete. A to je ten problem, preco to dlho trva.

Len teraz rozmyslam ako efektivne zapocitat clanok, jedinecne, nie ze ked niekto da 10 x refresh, tak sa zapocita 10x. Mozno cron nejako.

Poradite?
Nah87
Profil *
A este som zistil ze tam mam dalsie zbytocne selecty:

1.) select na zdroje clanku (ina tabulka)
2.) select na to, ci uzivatel so svojou IP za poslednych 60 minut hlasoval za clanok
3.) select na to, ci uzivatel so svojou IP za poslednych 60 minut prezrel clanok
4.) select na podobne clanky


Ale v podstate vsetky selecty su potrebne, len mozno by sa dal urobit nejako jeden velky Select, v ktorom by to vsetko bolo.
joe
Profil
Jak máš dotaz na výběr podobných článků?
Jan Tvrdík
Profil
Nah87:
Zkus zvážit, zda by nebylo vhodné v sekci Práce a zakázky najít nějakého odborníka, který by ti s optimalizací pomohl.
Kajman_
Profil *
Pokud ty ostatní selecty jsou rychlé, tak se zaměřte zatím na pocitani "zobrazeni clanku". Zkuste sem hodit dotaz, kterým to řešíte, seznam dostupných indexů a výstup explain. Třeba bude třeba jen jednoduchá úprava.
DJ Miky
Profil
Kde hostuješ? Nebude to spíše problém pomalosti hostingu?
Joker
Profil
Nah87:
Len teraz rozmyslam ako efektivne zapocitat clanok, jedinecne, nie ze ked niekto da 10 x refresh, tak sa zapocita 10x. Mozno cron nejako.
Stačilo by uživateli uložit cookie, že už ten článek četl.
Každopádně jestli ten dotaz je nějak "Vyber ze zobrazených článků takové, kde IP je nějaká a čas větší než teď mínus hodina", nevidím důvod, aby byl nějak fatálně pomalý.
Nah87
Profil *
Joker
Kajman_

Moj select na zapis zobrazenia clanku:


$result = $conn -> query("SELECT
						id 
					FROM 
						zobrazenia
					WHERE 
						idclanok = ".$id" and ip = '".$_SERVER['REMOTE_ADDR']."' and (UNIX_TIMESTAMP()-UNIX_TIMESTAMP(datum)) < 600");		
                       
			$videnia = $result -> num_rows; 
	
			if ($videnia == 0)
			{
				$conn -> query("UPDATE clanky SET videnia = videnia + 1 WHERE id = ".$id."");
				$conn -> query("INSERT into zobrazenia (idclanok, datum, ip, hosting) VALUES (".$id.", NOW(), '".$_SERVER['REMOTE_ADDR']."', '".gethostbyaddr($_SERVER['REMOTE_ADDR'])."') ");
			}




Takze toto je ten problem. Toto strasne dlho trva, pretoze ta tabulka zobrazenia ma uz teraz niekolko milionov riadkov a velkost 250 MB.
Ako by sa to dalo zeeftivit? Mozno mam zle nastavene take veci, ze primarny kluc, jedinecny, ... v tom to sa priznam velmi nevyznam.
Ak mi poradite, budem velmi velmi rad, a zaroven vam velmi vdacny.

Daakujem.

DJ Miky
Som na najlepsom slovenskom webhostingu.
Kajman_
Profil *
(UNIX_TIMESTAMP()-UNIX_TIMESTAMP(datum)) < 600

přepiště na
datum > date_sub(now(),interval 1 hour)


Pak může použít index na datum. Další optimalizací by bylo to zmenšené datum vygenerovat v php, aby se mohla použít i sql cache.
Nah87
Profil *
Takze mam zmenit iba ten kusok?

Pak může použít index na datum.
Mam vytvorit index? ako?
Kajman_
Profil *
Takze mam zmenit iba ten kusok?
Zkuste to, tam by měl být největší kámen úrazu.

Mam vytvorit index? ako?
Pro ten dotaz bude nejlepší jeden vícesloupcový index (idclanok,ip,datum). Ale jestli tam budou nějaké přehnané režie, těžko říct. Asi ho můžete zkusit vytvořit, není-li už to primární klíč. Je dobré mít v tom indexu datum až jako poslední.
Nah87
Profil *
1.) „Asi ho můžete zkusit vytvořit
Ako mam vytvorit ten index?
Som v PhPMyADMIN, a neviem co dalej. Budem rad, ak mi to trocha pordrobnejsie popisete.
Dakujem velmi pekne.


2.) Este by som sa chcel opytat, ci sa da nejako efektivnejsie napisat select na to, ze kolko bolo zobrazeni vsetkych clanokov za dnesny den.
Ja mam:

SELECT id FROM `zobrazenia` WHERE datum >= curdate()
a tiez mam pocit, ze to nie je najrychlejsie.

Dakujem.
Kajman_
Profil *
1. já phpmyadmin nepoužívám, přesné naklikání neporadím, výsledkem klikání by mělo být něco jako
ALTER TABLE `zobrazenia` ADD UNIQUE INDEX `djpw_index`(`ip`, `idclanok`, `datum`)



2.
SELECT count(*) pocet FROM `zobrazenia` WHERE `datum` >= '2009-08-06'

S indexem jen na datum by to nemuselo být zlé.
Nah87
Profil *
Kajman_
Kajman_, dakujem Vam velmi pekne za vase rady. Velmi ste mi pomohli.
Predtym sa mi stranky nacitali aj 5 az 8 sekund a teraz je to bezne do 0,1 sekundy nacitane. Niekedy sa stane, ze to je "az" do 1 sekundy, ale kto vie, preco to niekedy dlhsie nacitava, ale to je uz zanedbatelny cas.

Dakujem.
Toto téma je uzamčeno. Odpověď nelze zaslat.