[ALG] Wat gebruiken voor extreme teller

[Verwijderd]

Het is de bedoeling om een teller te programmeren die zo'n beetje iedere klik vastlegt. Dat is gebeurt in PHP met MySQL. Werkt allemaal prima. Nu komen we echter in de problemen. De teller heeft inmiddels +100.000 hits/records geregistreerd, maar deze verwerken leverd grote problemen op. MySQL en/of PHP lijken het niet aan te kunnen. Hier zijn we slechts korte tijd mee bezig.

Welke platform kan worden aangeraden om zo'n tellersysteem te ontwikkelen wat een paar miljoen hits moet kunnen verwerken en natuurlijk zo goedkoop mogelijk. Het bekende webalizer is geen optie. Het moet volledig naar eigen wensen op te zetten zijn.

Alvast bedankt

[ATS]

Waarop baseer je dat PHP/MySQL het niet aankan? Wat voor soort gegevens wil je vastleggen? Wat voor gegevens wil je eruit afleiden?

[Verwijderd]

Iedere hits wordt opgeslagen als IP-nr in combinatie met datum.

Zo kunnen unieke hits bepaald worden en kan het aantal hits per dag bepaald worden. De server heeft nu, nu er 100.000 records in staan al meer als een kwartier nodig om gegevens van een bepaalde dag er uit te filteren. En dat gaat alleen maar erger worden naar mate er meer hits in komen.

[jan-marten]

Hier zijn we slechts korte tijd mee bezig.

Webalizer gebruiken?
NedStat icoon op de site.
Er zijn zat tellersystemen te vinden -> klik hier & zoek.

[P_de_B]

100.000 records is echt niet veel. Heb je wel goede indexen aangemaakt? Zijn je queries wel optimaal geschreven? Daar zou ik als eerste naar kijken.

[Verwijderd]

De index is zeker wel gelegd en hij wordt gewoon met een SELECT WHERE-query uitgelezen. Lijkt me niet veel effectiever te kunnen

[Creepy]

100.000 records is zo veel nog niet. Als je indexen goed liggen (1 gecombineerde index op al je where velden!) dan mag het opvragen echt geen kwartier duren.

Je query met explain uitvoeren kan ook erg verhelderend werken

[ Voor 19% gewijzigd door Creepy op 13-09-2004 15:54 ]

[Tweeker]

Dat is inderdaad niet veel als ik zie dat ik live statistieken uit mijn database kan toveren aan de hand van apachelogs in mySQL en dan praten we nu over ongeveer 1 miljoen hits met diverse statistische berekeningen. Dan moet 100000 records geen probleem geven tenzij het op een 486 allemaal draait of zo.

Wat doe jij om te berekenen??? haal je de hele set op in een recordset en ga je dan in PHP de nodige berekeningen doen, of heb je de nodig slimme queries opgezet en krijg je alleen de waarden terug die je uiteindelijk nodig hebt? Een goed uitgedachte (statistische) query is namelijk al de grootste winst van je tijd. En vergeet de indexen niet.

[ Voor 3% gewijzigd door Tweeker op 13-09-2004 15:55 ]

[Vaudtje]

Verwijderd schreef op 13 september 2004 @ 15:51:
De index is zeker wel gelegd en hij wordt gewoon met een SELECT WHERE-query uitgelezen. Lijkt me niet veel effectiever te kunnen

Nou, als je bijvoorbeeld je datum als een String opslaat, valt er dus veel te optimizen.

Ik moet bekennen dat je postings op mij overkomen alsof je alles al weet en niet geholpen wil worden.
Probeer zoveel mogelijk relevante informatie te geven en te begrijpen dat je medeTweakers altijd de beste bedoelingen hebben.

[Tweeker]

Verwijderd schreef op 13 september 2004 @ 15:51:
De index is zeker wel gelegd en hij wordt gewoon met een SELECT WHERE-query uitgelezen. Lijkt me niet veel effectiever te kunnen

als je alleen een aantal wilt hebben zou ik de berekening bij SQL neer leggen en moet je bepaalde doorsnijdingen hebben op ip nummer of datum zul je een group by query moeten bouwen.

[majornono]

Ik heb eenzelfde systeem ontwikkeld voor ons CMS. Iedere hit wordt geregistreerd, waarbij inmiddels meer dan 2 miljoen records in de database (SQL Server & ASP webserver) staan. Performed nog steeds prima.

Hits worden geregistreerd op pagina-ID & tijd, waarbij de tijd als sleutel is opgenomen.

[.oisyn]

Zoals gezegd ligt het echt niet aan php/mysql. Post je tabel layout en je query eens hier? Eens kijken wat daaraan te doen valt

[zneek]

uuhhh waarom heeft een webserver logfiles? Die meet toch alles al voor je? Je hoeft alleen die stats nog maar te visualiseren. Dat kan webalyser voor je doen, Livestats (kost geld, maar is erg compleet en ziet er gelikt uit), of je kan het zelf uitlezen, al dan niet in PHP (of Java of whateva). Waarom zou je je PHP engine belasten met iets dat al lang opgeslagen wordt?

[ Voor 12% gewijzigd door zneek op 13-09-2004 19:43 ]

[muba]

zneek schreef op 13 september 2004 @ 19:40:
uuhhh waarom heeft een webserver logfiles? Die meet toch alles al voor je? Je hoeft alleen die stats nog maar te visualiseren. Dat kan webalyser voor je doen, Livestats (kost geld, maar is erg compleet en ziet er gelikt uit), of je kan het zelf uitlezen, al dan niet in PHP (of Java of whateva). Waarom zou je je PHP engine belasten met iets dat al lang opgeslagen wordt?

Dat was ook het eerste waar ik aan dacht. De (web)logs van de (web)server.

[zneek]

MUBA schreef op 13 september 2004 @ 20:00:
[...]


Dat was ook het eerste waar ik aan dacht. De (web)logs van de (web)server.

Precies, je gebruikt waarschijnlijk IIS of Apache, en als ik me niet vergis kun je met beide W3C extended logfiles mee uitpoepen. Daar staat echt alles in wat je nodig bent.

Kijk maar eens op www.deepmetrix.com wat Livestats op basis van de stats al weet te produceren. Als je zelf de logfiles inleest kun je ook nog dingen gaan met de inhoud van de request, zoals bijvoorbeeld bekeken content items bepalen oid.

[P_de_B]

zneek schreef op 13 september 2004 @ 23:51:
[...]


Precies, je gebruikt waarschijnlijk IIS of Apache, en als ik me niet vergis kun je met beide W3C extended logfiles mee uitpoepen. Daar staat echt alles in wat je nodig bent.

Kijk maar eens op www.deepmetrix.com wat Livestats op basis van de stats al weet te produceren. Als je zelf de logfiles inleest kun je ook nog dingen gaan met de inhoud van de request, zoals bijvoorbeeld bekeken content items bepalen oid.

Maar dat is niet altijd genoeg, misschien wil je wel gegevens bijhouden van de ingelogde gebruiker oid(die je zelf middels een tabel in een db hebt ingelogd). Dat kan volgens mij niet met het analyseren van IIS/Apache logs.

[zneek]

P_de_B schreef op 14 september 2004 @ 08:21:
[...]


Maar dat is niet altijd genoeg, misschien wil je wel gegevens bijhouden van de ingelogde gebruiker oid(die je zelf middels een tabel in een db hebt ingelogd). Dat kan volgens mij niet met het analyseren van IIS/Apache logs.

Ok, maar dan nog. Sla de gebruiker en de sessie op in de db (dus 1 insert per bezoeker) en zorg ervoor dat je die sessie terug kunt vinden in de logfiles (hang een sessie-id aan elke request oid)

[Polderdijk]

Misschien moet je eens kijken om over te stappen naar ASP en MS SQL server. Ik heb zo'n zelfde soort waarbij ik IP, Datum/Tijd, Refferer, Cookie, Browser etc. etc. van al mijn website's in 1 tabel bijhoud. Hierin zitten op het moment zo'n 430.000 records in en deze worden binnen 2 seconde geheel gefilterd en gegroepeerd op bijv. refferer getoond op mijn scherm.

Neem contact met me op als je een voorbeeld wil zien!

[ Voor 5% gewijzigd door Polderdijk op 14-09-2004 10:18 ]

[Creepy]

Polderdijk schreef op 14 september 2004 @ 10:16:
Misschien moet je eens kijken om over te stappen naar ASP en MS SQL server. Ik heb zo'n zelfde soort waarbij ik IP, Datum/Tijd, Refferer, Cookie, Browser etc. etc. van al mijn website's in 1 tabel bijhoud. Hierin zitten op het moment zo'n 430.000 records in en deze worden binnen 2 seconde geheel gefilterd en gegroepeerd op bijv. refferer getoond op mijn scherm.

En hij moet gaan overstappen omdat? Ook in MySQL kan dit opvragen stukken sneller.

[Woy]

idd het overstappen naar asp en MS SQL zal echt geen groot performance verschil opleveren als je het nog steeds op dezelfde manier blijft doen.

Er zit duidelijk iets verkeerd in je methode. 100.000 records is echt helemaal niet veel en daar kan je echt binnen een fractie van de tijd die het nou bij jou duurt zat informatie uit halen. Post dus eens iets meer over hoe je het aan hebt gepakt, dan kan er mischien nog iemand een zinnig antwoord geven. Op dit moment is dat ieder geval niet mogelijk

[DaCoTa]

Mocht je gaan sleutelen, zorg er dan wel voor dat de indexen van die tabel volledig in memory passen. Ander gaan op een gegeven ogenblik de updates en inserts van die tabel ontzettend lang duren ivm de extra diskaccess die nodig is. Als je nu al op 450.000 zit, kun je problemen verwachten als je in de order van miljoenen records komt en je geheugen is te krap.

[Janoz]

Ikzelf heb het vermoeden dat de bottleneck absoluut niet bij de php of de mysql ligt. Zoals ook al eerder aangegeven lijkt het mij erg handig waneer de topicstarter wat meer info over de gebruikte techniek geeft.

Ik heb zo het vermoeden dat de datum ip combo beiden als string worden opgeslagen ipv met een date en een long.

[Polderdijk]

Creepy schreef op 14 september 2004 @ 10:29:
[...]

En hij moet gaan overstappen omdat? Ook in MySQL kan dit opvragen stukken sneller.

Omdat ik regelmatig hoor dat MySQL slecht om kan gaan met JOIN en GROUP BY op grote databasen en dat dit je performance gigantisch onderuit trapt.

Ikzelf zat eerst ook (via ASP) op een MySQL server. Deze site had niet schrikbarend veel record maar wel een berg JOINS en dat soort speelgoed. Dit ging een beetje traag worden en heb geprobeerd om dit precies het zelfde te maken op een MS SQL Server. Dit leverde een gigantisch verschil op en sindsdien wil ik echt niet meer terug naar MySQL!

Het verschil tussen APS/PHP kan ik ook niet direct verklaren, maar vind persoonlijk dat ASP veel logischer is dan PHP. Zeker qua variabelen aanroepen enzo.

[gorgi_19]

Het verschil tussen APS/PHP kan ik ook niet direct verklaren, maar vind persoonlijk dat ASP veel logischer is dan PHP. Zeker qua variabelen aanroepen enzo.

Modbreak:

Even preventief een berichtje plaatsen. Graag dit topic niet ombouwen tot een ASP vs. PHP discussie. Daar is in het verleden al vaak genoeg over gediscussieerd welke van de 2 beter is. Mocht iemand behoefte hebben er aan, dan kan dit in een eigen draadje, niet in deze.

[Janoz]

Zoals de topicstarter zelf al aangeeft gaat het al langzaam bij non join queries. De bottle neck zit dus niet in de mogenlijke trage joins, maar zeer waaarschijnlijk in het database ontwerp. Door MSSql te gebruiken los je dat probleem niet op.

[Polderdijk]

Oke logisch dat het geen ASP vs. PHP mag worden.

Maar ik gaf aan wat ik voor alternatief zal vinden, de topicstarter vroeg namelijk:

Welke platform kan worden aangeraden om zo'n tellersysteem te ontwikkelen

Ik raad de topicstarten dus MS SQL en ASP aan

[Verwijderd]

Kijk even heel erg goed naar het ontwerp van je database. De kans is ERG groot dat je een probleem is opzet van je database hebt. Is de database bijvoorbeeld goed genormaliseerd?

[Verwijderd]

Polderdijk schreef op 14 september 2004 @ 11:38:
Oke logisch dat het geen ASP vs. PHP mag worden.

Maar ik gaf aan wat ik voor alternatief zal vinden, de topicstarter vroeg namelijk:


[...]


Ik raad de topicstarten dus MS SQL en ASP aan

MS-SQL en ASP is inderdaad erg stabiel maar ik verwacht niet dat de huidige problemen een resultaat zijn van de platform keuze want in principe kan een teller ook prima op basis van andere technieken ontwikkeld worden.
(ben zelf trouwens ook MS SQL - ASP/ASP.NET fan)

[zneek]

De hele ASP/PHP MySql/MsSql discussie doet er niet toe. De efficientste manier van oplossen is (voor een deel) gebruik maken van de webserver logs. De webserver kan gewoon efficienter die gegevens wegschrijven.

Hoe je er dan vervolgens mee om gaat maakt niet zoveel uit, zo lang je de bewerkte gegevens maar in een goed opgezette db zet. Zelf zou ik er eerder voor kiezen om gegevens samen te gaan vatten. Dus na een week de afzonderlijke views op een item weggooien en alleen het totaal bewaren.

[intermusic]

Nou jah...
Heb alles ff gelezen, maar het gaat nergens naar toe, er komen geen verbeteringen.
Ook heeft de topic starter niet meer gereageerd.
Kan ie dicht toch?