zakaj imaš LEFT JOIN? navaden join ne bi bil v redu? A je pogoj n.inserted < NOW() smiseln? Če nimaš insertov v prihodnosti, to odstrani.

MySQL uporabi samo 1 index na posamezno aktivno tabelo v queryju. EXPLAIN pokaže, da izbere PRIMARY index za tabelo news. Na tej tabeli ti izvajaš sledeče operacije: WHERE (polje inserted), ORDER (priority in inserted). Mogoče je torej boljši index inserted, kar lahko sforsiraš (išči FORCE INDEX), lahko pa probaš tudi forsirati index na priority (čeprav dvomim, da bo bolje).

Za tabelo news2category izbere index categoryid, vendar to pomeni, da mora delati scan tabele za pogoj n2c.newsid = n.newsid, namesto da bi poiskal z indexom. Probaj spremeniti zadevo v navaden join in forsirati index newsid za tabelo n2c.

Tole je takole na hitro na pamet. Drugače pa 1.5 sekunde ni čas za sekiranje. :)

če gre za 1500 poizvedb, imaš resen problem, če pa 1500 zapisov v bazi, pa samo manjšo neprijetnost. :)

se pridružujem Rokyju. Poraba RAM-a postane problem šele takrat, ko nekaj zaradi tega ne dela. Do takrat odmisli porabo, to te samo ovira pri reševanju problemov.

Daj še 20€ v Httpool in boš lahko direktno primerjal.

Httpool operira tudi na Hrvaškem, z enakim sistemom, kot tu.

Aja, sem narobe razumel, da se šele uvajaš v spletno programiranje. :)

Večina spletnih zadev je v PHP-ju, z Javo delajo v glavnem večje firme na večjih projektih, tako da če ciljaš na takšno službo, potem je to predznanje koristno. Imaš pa precej različnih platform in application serverjev, tako da ni nekega standardnega pristopa. Vsekakor se malo vrži not, če ti je všeč, škodilo ti ne bo.

kot šolski in izhodiščni jezik je PHP najbrž boljši, ker je napredek hitrejši in infrastruktura bolj enostavna. Če si resen, boš moral s časom itak znati več jezikov, tako da je v končni fazi vseeno.

http://www.w3schools.com/tags/attatarget.asp

verjetno bi se dalo kaj sčarati v tem stilu, vendar toplo odsvetujem, ker je eval nevaren in počasen in koda v stringu je izven dosega parserja (IDE ne razume in napake se odkrijejo šele pri evalu). Ta pristop po moje ni v redu.

Poleg tega imaš še varnostno luknjo. Kaj če ti kdo poda parameter id=); zlobna_koda(? :)

Keširaj ali posamezne končne HTML kose, ali pa objekte/arraye in uporabi wrapper za cache:

class NewsCategoryCacher {

  function get($id) {

    if (news $id is in cache)

      return from cache

    else

      $nc = new NewsCategory($id);

      write to cache

  }



  function getMostViewedByCategory($category) {

    if (most viewed $category->id is in cache)

      return from cache

    else

      $most_viewed = $category->getMostViewed();

      write to cache and return

  }

}

in potem uporabljaš:

$category = NewsCategoryCacher::get(234);

$most_viewed = NewsCategoryCacher::getMostViewed($category);

To je osnovna ideja, da se jo precej raztegniti.

BTW, če te zanima framework za večplastno keširanje v PHPju, si oglej LayerCache. Omogoča zelo elegantno večplastno keširanje z zelo malo kode. Na enem projektu recimo uporabljam 3-plastno: izvor je mysql tabela, cachi pa so memcache, apc in še lokalen PHP array.

pa ne pozabi poklicati escapeshellarg() na podanih parametrih ($param1 in $param2), preden jih sestaviš v ukaz za exec().