Tako kot ti je Roky predlagal, celotno formo serializiraj z jquerijem in server side validiraj podatke in preko ajax-a izpiši napake zraven fieldov.

Če pa ima user javascript izklopljen pa lahko isto metodo uporabiš za validacijo v POST-u.

IETester in debugbarje kar v redu.

Da, query cache sem upošteval.

Najlepša hvala za obširne odgovore in nasvete!

Zaenkrat sem ti 'prilimal' toliko plusov kolikor se je dalo v tej temi.

Ko te pa naslednjič srečam v živo, te pocukam za rokav in povabim na:

while(pivo) pivo++

Hvala in LP

Pomojem te strani odpira samo kak google-bot in kak user, če 'zaide' pregloboko.

Pravzaprav se to zgodi pri pagingu novic, ko kdo klikne na "zadnja stran". To sem pa ugotovil čisto slučajno, z logiranjem mysql querijev počasnejših od 0.5sekunde.

Saj zadeva ni problematična, ampak me firbec matra kako najbolje(s hitrimi poizvedbami) narediti paging npr 30k kategoriziranih novic urejenih po datumu.

še primeri različnih limitov s FORCE INDEX:

LIMIT 0,21 ~ 0.002s

LIMIT 500,21 ~ 0.02s

LIMIT 1000,21 ~ 0.04s

LIMIT 1500,21 ~ 0.08s

LIMIT 2000,21 ~ 0.20s

LIMIT 3000,21 ~ 0.32s

LIMIT 4000,21 ~ 0.41s

LIMIT 5000,21 ~ 0.52s

LIMIT 6000,21 ~ 0.61s

brez FORCE INDEX:

LIMIT 0,21 ~ 0.26s

LIMIT 500,21 ~ 0.25s

LIMIT 1000,21 ~ 0.26s

LIMIT 1500,21 ~ 0.26s

LIMIT 2000,21 ~ 0.27s

LIMIT 3000,21 ~ 0.27s

LIMIT 4000,21 ~ 0.29s

LIMIT 5000,21 ~ 0.29s

LIMIT 6000,21 ~ 0.29s

fatg: brez forcanega indexa se LIMIT 0,21 izvaja 250x počasneje ~ 0.25 sekunde

Sem probal odstraniti joinano tabelo 'url' pa se profitira le 0.05s

Kaj drugega 'predizračunanega' se pa ne morem domisliti, saj gre le za enostavne novice, ki so v več kategorijah.

Tale query z LIMIT 0, 21 se izvaja 0.001sekunde

SELECT n.news_id, n.title, n.news_id, n.short, n.picture, n.youtube, n.audio, n.gallery_id, n.inserted, u.url

FROM news AS n

JOIN news2category AS n2c

FORCE INDEX FOR JOIN (

news_id

) ON n2c.news_id = n.news_id

JOIN url AS u ON n.news_id = u.action_id

WHERE n2c.category_id =2

AND u.action = 'viewNews'

AND n.inserted < NOW( )

ORDER BY n.inserted DESC

LIMIT 0 , 21

Explain:

id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra

1     SIMPLE     n     index     PRIMARY     inserted     8     NULL     21     Using where

1     SIMPLE     u     ref     action_id     action_id     5     baza.n.news_id     1     Using where

1     SIMPLE     n2c     ref     news_id     news_id     5     baza.n.news_id     1     Using where

Isti query z LIMIT 6000, 21 se izvaja 0.6 sekunde.

Explain:

id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra

1     SIMPLE     n     ALL     PRIMARY     NULL     NULL     NULL     19182     Using where; Using filesort

1     SIMPLE     u     ref     action_id     action_id     5     baza.n.news_id     1     Using where

1     SIMPLE     n2c     ref     news_id     news_id     5     baza.n.news_id     1     Using where

Če odstranim FORCE INDEX FOR JOIN(news_id) pa naredi query z LIMIT 6000,21 polovico hitreje, v 0.3s. Čeprav explain pokaže "Using temporary"

Explain:

id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra

1     SIMPLE     n2c     ref     news_id,category_id     category_id     5     const     5360     Using where; Using temporary; Using filesort

1     SIMPLE     n     eq_ref     PRIMARY     PRIMARY     4     baza.n2c.news_id     1     Using where

1     SIMPLE     u     ref     action_id     action_id     5     baza.n.news_id     1     Using where

Kako bi lahko pospešil izvajanje querijev z višjimi limiti?

Ena ideja je, da bi preverjal LIMIT > COUNT/2 potem nebi forcal indexa - news_id ampak verjetno to ni najboljše.

Kakšna ideja?

Letos so na PHPkonferenci povedali, da se včasih splača zadevo naredit v 2 korakih.

In sicer, najprej

SELECT DISTINCT refId FROM visitstat WHERE type='P' AND date > '2010-10-02'

rezultate lepo spravit v string ločen z vejicami,

v 2. koraku pa

SELECT id, name FROM Product WHERE id NOT IN (23,45,67,...)

Tukaj moraš pazit, da dolžina queirja ne preseže 'maxallowedpacket'

Drugače pa malo experimentiraj z indexi. (indexe na tisto po čemer sortiraš, tisto kar selectaš).

Tabele lahko probaš spremenit v innodb, da vidiš če kaj profitiraš...

Ugotovil! Tip kampanje mora biti Remnant. To je neke vrste catch-all kampanja, ki se pokaže le v primeru, ko ni drugega bannerja. Simpel rešitev, ampak če ne veš ne znaš.

Tega sem se bal... še vedno iščem varjanto, ki se obnaša enako kot openX market, samo da ne prikazuje bannerjev iz openX-marketa ampak moje custom. Sporočim, če kaj najdem

Hvala, to sem sedaj naredil. Naredil sem "demo oglaševalca" in "demo kampanjo".

Ali lahko sedaj to kampanjo kako skopiram k ostalim spletnim stranem (v vse ostale user profile znotraj openx)? Da mi nebo treba vsakič kreirati "demo oglaševalce" in nalagati bannerje.

Kateri tip kampanje oz. ali se da nastaviti, da bannerje iz te kampanje prikazuje samo takrat ko ni drugih aktivnih kampanj za področje?