View tæller

Det lyder i mine øre meget mærkeligt, at de skulle kunne gøre dit site meget tungere ved at have tællere, det er jo bare "hvis lavet rigtigt" en værdi der forøges i din database, altså en almindelig query lige en select insert etc.

Youtube derimod tracker meget mere end bare views når du klikker ind, alt fra tid til ip osv. og de har sikkert en tabel hvor hver view danner en row, og har et FK til en video. Jeg kender dog ikke strukturen hos YouTube, men det er sikkert noget advanceret snask.

Er du sikker på det er din tæller der sænker dit site? Du siger du har fået meget trafik, måske det er tid til at opgradere din server?

Tak for dit svar Martin!

Jeg har fra den server ansvarlige fået at vide at vores database bruger længere tid på at læse og skrive nu..
Ét banner har på lidt over 10 dage fået 600'000 eksponeringer.. Og da der er flere i rotation betyder det at de andre har fået ligeså meget..

Jeg opdaterer ved at udføre dette query:

update banners set views=views+1 where id=ID_PÅ_BANNER


Det er vel den nemmeste metode at gøre det med?

Får du lukket dine forbindelser til databasen korrekt, så der ikke er en mass åbne og ikke nødvendige connections der bruger ressourcer?

Ikke umiddelbart nej..

Har overtaget "jobbet" fra en anden programmør.. Så det at gennemskue noget af hans kode der lidt svært for mig..
Men nej, jeg mener ikke at jeg kan se nogen mysql_close(); nogle steder..


Så det er dét som er synderen?


Kan man evt. i mysql se hvor mange åbne connections der er igang..
Og så se om loaded går ned efter jeg indsætter mysql_close(); ?

I MySql administratorsiden kan man se "Active connections". Jeg vil dog ikke lægge hovedet på blokken, at det kan betyde noget. Men det er da en mulighed.

En mulighed kunne dog være, at genstarte serveren og se om det hjælper på problemet et stykke tid.

I det tilfælde ville jeg slet ikke have tælleren, eller banneret på samme server & database som hoved sitet.
Jeg ville have en server der bare viste banner ud fra id, køre et script der tællede i egen database når der sker en visning.
Det ville umiddelbart være en måde at dele trykket.

Og ja vil mene det er en fin metode til at tælle på .

Brian: Jeg prøver lige at forhøre mig i morgen ang. connections.. Prøvede lige at søge lidt.. Og det er noget med en mulig grænse på maks. antal connections.. Og det kunne jo godt være den som sænker farten lidt..

Martin: Så du forslår egentlig at sætte en helt anden database op som skal sørge for at tælle hver gang der sker noget.. Og det er både på bannere, men også andre sider, så som forum indlæg?

Jeg er også i gang med at lave en like funktion.. Der vil jo også kun blive talt op hele tiden.. Og det ville vel være fornuftigt nok at putte det over i en anden database også?

Det er ikke skrivningerne der tager tid. Det er læsningerne, og her er der en række ting som kan gøres.

Du får dem lige i kort liste form:
1. Åben først forbindelse til databasen, når den skal bruges.
2. Luk den, når du er færdig. Men først når du er helt færdig med at bruge den i den enkelte request.
3. Kode optimering. Undgå queries på samme data flere gange.
4. Database normalisering.
5. SQL optimering.
6. Data indeksering. Tabeller der ikke er sat op med de rigtige indeks, tager lang tid at læse.
7. Mellemregninger. Man kan godt samle sammen i statistikken. F.eks. behøver man ikke sammentælle alle hits for en dag, hver gang. Det kan sagtens lægges sammen til een række.
8. Sidste udvej. Mere RAM i kassen.
9. Allersidste udvej, hvis denne ikke tidligere er brugt: flyt database til sin egen server.
10. aller-aller-sidste udvej. Flere servere... (det bli'r tekniknørder så glade for)

Ikke at jeg tror dette på nogen måde kører bedre, men det en ide til spørgsmålet "Mit spørgsmål er så, hvordan får jeg det til at blive forsinket?".


Du kan have en tabel A, hvor du bare indsætter rækker for hvert view.

Når banner id 2056 er set indsætter du en række med id 2056.

Så kan du senere, når du har færrest besøgende, formentlig om natten.

Lave et cronjob, der sammentæller antallet af rækker i tabel A grupperet efter ID og opdatere den reelle view tabel med tallet, hvorefter A tømmes.



Eneste måde jeg kan se det skulle være hurtigere på er, at insert ikke kræver at du finder en specifik række i forhold til update.

Det er ikke skrivningerne der tager tid. Det er læsningerne, og her er der en række ting som kan gøres.

Bare så det ikke bliver misforstået. En sql-update udfører både læse og skrive operationer.