[RC5/OGR] alternatief voor ppstats

[Witlof]

Sja, in het verleden was het te doen met een dupechecker om te kijken of de blokjes dubbel waren en wie deze flushte. In een overzicht wat dagelijks meerdere malen geupdate wordt is het sneller terug te zien en kun je sneller handelen. Opzich zou ik het wel een prettige feature vinden als die erin zat maar als het niet zo is kijk ik wel bij DSmarty want daar flushen we naar toe. Moet ik nog wel kijken wie er verantwoordelijk voor is via mijn eigen logs.

[Webgnome]

Ramonp wat wordt er opgeslagen in 'blocks' in je sql? Als dat het id van het blokje is , dan is een simpele nieuwe tabel ( dupes ) en een aantal nieuwe queries toch voldoende?

[Webgnome]

Ramonp wat wordt er opgeslagen in 'blocks' in je sql? Als dat het id van het blokje is , dan is een simpele nieuwe tabel ( dupes ) en een aantal nieuwe queries toch voldoende?

.... een opnieuw inladen van de logs ontkom je dan inderdaad niet aan tenzij je natuurlijk alle blokcs in je block tabel laad. Dus ook als er dubbele instaan. dan volstaat het een simpele insert query met een select op de blocks tabel al om de dubes tabel te vullen

[ Voor 31% gewijzigd door Webgnome op 21-10-2005 18:48 ]

[ramonp]

Bij 'blocks' worden het aantal blocks opgeslagen in de database.

Als je alle blockid's gaat opslaan betekent het dat er voor iedere regel uit de logfile een record wordt gemaakt.
Nu is het zo dat de blocks met dezelfde datum, tijd en ip bij elkaar worden opgeteld en die wordt als één record weggeschreven in de database.

Het scheel een hoop ruimte om op te slaan, maar heeft als nadeel dat je geen dupes kan controleren.

[MeneerKrab]

er staat in de init.php dat gnuplot nu ook werkt op MS OSSEN, maar datis nog niet zo.
Op een vage manier heb ik toen zelf een grafiekje uit gnuplot weten te toveren door de rc572.ini in te laden en dat gaf me ook nog een verneukt grafiekje.

De plaatjes werken ook niet meer.
$baseurl = "/"; < zo staat mijn baseurl. Nu kan ik hem bekijken van intern en extern.

[ Voor 21% gewijzigd door MeneerKrab op 25-10-2005 17:54 ]

[Webgnome]

ramonp schreef op zaterdag 22 oktober 2005 @ 14:07:
Bij 'blocks' worden het aantal blocks opgeslagen in de database.

Als je alle blockid's gaat opslaan betekent het dat er voor iedere regel uit de logfile een record wordt gemaakt.
Nu is het zo dat de blocks met dezelfde datum, tijd en ip bij elkaar worden opgeteld en die wordt als één record weggeschreven in de database.

Het scheel een hoop ruimte om op te slaan, maar heeft als nadeel dat je geen dupes kan controleren.

dus je houd helemaal niet bij welk block id er is geflusht? nee dan is het inderdaad neit mogelijk om dupes te controleren.

[_reboot_]

@Ramonp:
Is het geen idee om de weekstats volledig via MySQL de laten gaan dan ben je ook van het wekenprobleem verlost? Volgens mij worden de weekstats (en misschien de rest ook wel) geparsed door PHP. Is het niet gemakkelijk om dit gelijk door MySQL te laten doen? Hoe meer je vanuit de database al doet, hoe sneller het meestal gaat.

Check bijvoorbeeld: http://dev.mysql.com/doc/...e-and-time-functions.html

[ramonp]

_reboot_ schreef op vrijdag 28 oktober 2005 @ 16:49:
@Ramonp:
Is het geen idee om de weekstats volledig via MySQL de laten gaan dan ben je ook van het wekenprobleem verlost? Volgens mij worden de weekstats (en misschien de rest ook wel) geparsed door PHP. Is het niet gemakkelijk om dit gelijk door MySQL te laten doen? Hoe meer je vanuit de database al doet, hoe sneller het meestal gaat.

Check bijvoorbeeld: http://dev.mysql.com/doc/...e-and-time-functions.html

Ik heb het probleem uiteindelijk toch maar via MySQL opgelost, in de laatste versie (v0.179).
Er werd in de query een verkeerde 'jaar' variable gebruikt. Het was %Y terwijl het i.c.m. weken %x moest zijn. (Dat staat ook op de link die je hebt gegeven.)

[ramonp]

Ik heb even het één en ander getest om dupes te controleren.

Er zit één groot nadeel aan, de tabel groeit enorm.

Als voorbeeld heb ik even mijn eigen database bekeken.

De tabel rc572 heeft nu 557 records en is 60 kb groot.
De tabel rc572 waar ook de blockid's worden opgeslagen heeft ruim 17.500 records en is 1,5 mb groot.

* ramonp vraagt zich dan ook af of dit de moeite waard is.

[Verwijderd]

Niet voor het een of het ander, maar 17.500 records is niets voor een database. En anderhalve megabyte is ook niets. Dat kan bijna op een floppy

Zowat anderhalf jaar geleden had ik nog een ECC2-109 proxy draaien, die ook een dupe checker had. De database daarachter (een simpel MySQL geval) had aan het einde van het project ruim een half miljoen records en een tiental tables. En die draaide prima op m'n oude getrouwe 486DX2-66 met amper 32MB geheugen! Ik geef toe dat je af en toe wel een handvol seconden moest wachten om stats te laten genereren als meerdere mensen gelijk stats gingen bekijken, maar dat was dan ook meer mijn schuld dan die van de database (slecht design met verschillende complexe queries die met een paar honderdduizend records gingen spelen), maar dat boeide uiteindelijk niet zoveel. Toen ik de database op het einde op m'n oude Athlon 750 ging draaien merkte je niet eens dat die draaide op wat geheugengebruik na, zelfs met het slechte design van de stats...

En zelfs dat is nog niets. Doet me denken aan dit bericht wat ik een tijdje geleden tegen kwam. Een database van 600GB met 3600 tables en 2 miljard records waar iedere 2 uur zowat 4 miljoen inserts worden gedaan. En dat zelfs met MySQL. Jij komt nog lang niet in de buurt van de limieten van je database denk ik

Zelfs de DPC topteams hebben nog maar een paar miljoen blokjes. Laat ons uitgaan van 100 miljoen blokjes, dan zijn dat honderd miljoen records met een ID. Een ID kun je in 40 bits opslaan. Laat ons nog zeggen dat je er 64 bit voor neemt, of 8 bytes. Da's een database van niet eens een gigabyte. Dat zie je niet eens staan op een moderne harddisk. Volgens mij wordt het meer een kunst om bijvoorbeeld een dupe check snel te laten verlopen met 100 miljoen andere IDs in de database...

Dus ik denk dat je je geen zorgen moet maken voor een paar duizend records en een paar megabyte data Gewoon een dupe check toelaten als optie. Wie het wil gebruiken zet het aan, de anderen laten het afstaan.

[Webgnome]

ramonp schreef op maandag 31 oktober 2005 @ 10:55:
Ik heb even het één en ander getest om dupes te controleren.

Er zit één groot nadeel aan, de tabel groeit enorm.

Als voorbeeld heb ik even mijn eigen database bekeken.

De tabel rc572 heeft nu 557 records en is 60 kb groot.
De tabel rc572 waar ook de blockid's worden opgeslagen heeft ruim 17.500 records en is 1,5 mb groot.

* ramonp vraagt zich dan ook af of dit de moeite waard is.

De database groeit inderdaad enorm maar wat daar tegenovestaat is wel de moeite waard. Dupechecking. Op dit moment heeft het stats systeem van [BVD]South in de main table +/- 1.307.570 (maal 8 kolommen ) records waarvan er in de dupetable 21.813 ( maal 4 kolommen ) geregistreerd staan.

In de blocks tabel worden de gegevens opgeslagen van de blocks op het momentd at ze binnen komen. Mocht er een dupe worden gegenereerd dan wordt deze in de blocks tabel opgeschreven. hiervan wordt alleen het ID opgeschreven van het zlefde block in de blockt table en de datum waarop het wordt geduped en het ip waarmee het is verzonden. Dat dit mischien niet de meest goede manier is ben ik wel met jullie eens

En om nou te zeggen dat de stats langzaam zijn?

grazestats nou nee met andere woorden waarom is het niet de moeite waard. Je moet pas gaan denken hieraan als door dit 'grapje' de tabel grensen worden bereikt en dat is voor mysql meen ik 4 miljoen records (waar ik dat vandaan heb ik weet ik ook niet ).

[ Voor 32% gewijzigd door Webgnome op 31-10-2005 17:28 ]

[Verwijderd]

Webgnome schreef op maandag 31 oktober 2005 @ 17:20:
Je moet pas gaan denken hieraan als door dit 'grapje' de tabel grensen worden bereikt en dat is voor mysql meen ik 4 miljoen records (waar ik dat vandaan heb ik weet ik ook niet ).

Dat zou bijzonder lomp zijn en kan ik me haast niet voorstellen. Ik zou verwachten dat het het ruim 4 miljard was ('4 billion'), toch voor een 32 bit systeem (2^32 is ruim 4 miljard). Uiteraard moet je dan nog wel rekening houden met de beperkingen van je file system. En voor 64 bit systemen zou ik zelfs nog een veel hogere limiet verwachten...

[ Voor 9% gewijzigd door Verwijderd op 31-10-2005 20:17 ]

[ramonp]

Nou goed. Ik zal het eens verder uitwerken.

Kijken of het een beetje gaat werken.

[Webgnome]

ramonp schreef op dinsdag 01 november 2005 @ 08:40:
Nou goed. Ik zal het eens verder uitwerken.

Kijken of het een beetje gaat werken.

als er iets niet lukt dan ben ik wel bereid om je te helpen

[ramonp]

Het is op zich wel gelukt, maar ik weet niet of ik voor de snelste methode heb gekozen.

Ik heb een extra tabel aangemaakt dupes_rc572 wat een exacte kopie is van rc572.

Daarna heb ik de update query aangepast. Bij het inlezen van de log file wordt eerst gekeken of het blockid voorkomt in rc572. Zo niet dan wordt ie in de tabel rc572 bijgeschreven. Komt ie al wel voor dan wordt ie in de tabel dupes_rc572 weggeschreven.

Hetzelfde geldt natuurlijk voor ogr.

Het gaat allemaal wel goed, alleen gaat het updaten wat langzamer.

[Webgnome]

Zo heb ik het ook gedaan bij mijn stats system. Ik ben de laatste dagen mezelf ook aan het afvragen of dit niet beter kan ( met een of andere subquery ).

[ParaNoiMia]

Ik heb dat op een andere manier opgelost met een klein undupe proggie. Als je een unieke key maakt op het block in je tabel en je doet insert query, dan ontstaat er een fout, omdat de key niet uniek is. Met foutafhandeling kan je dat block daarna alsnog in de dupetabel inserten. Werkt sneller dan een select (zeker met de miljoenen wu's die NC in de DB zou krijgen )

[ramonp]

Het is idd sneller, maar echt een mooie oplossing vind ik het niet.

[ParaNoiMia]

ramonp schreef op woensdag 02 november 2005 @ 14:13:
Het is idd sneller, maar echt een mooie oplossing vind ik het niet.

Ik zie niet wat er mis mee is ? Sterker nog, je maakt gebruik van errorhandling en de controle wordt door je DB afgehandeld en niet programmatisch

[ Voor 12% gewijzigd door ParaNoiMia op 02-11-2005 15:48 ]

[ramonp]

ParaNoiMia schreef op woensdag 02 november 2005 @ 15:48:
[...]


Ik zie niet wat er mis mee is ? Sterker nog, je maakt gebruik van errorhandling en de controle wordt door je DB afgehandeld en niet programmatisch

Ik heb het even heel simpel gedaan, dus er word niet gekeken wat er fout gaat.

PHP:

$sql = "insert in de tabel";
if (!mysql_query($sql)){
  $sql = "insert in de dupes tabel";
  mysql_query($sql);
}

[ge-flopt]

Heeft iemand de zelf gemaakte updates al gebundeld en opnieuw uitgebracht?

[ramonp]

ge-flopt schreef op maandag 07 november 2005 @ 10:20:
Heeft iemand de zelf gemaakte updates al gebundeld en opnieuw uitgebracht?

Welke updates bedoel je?

Het 'dupes' gebeuren moet eerst even goed worden uitgewerkt en worden getest.
Voor de rest zijn er geen nieuwe updates meer sinds de laatste versie.

Maar momenteel heb ik andere problemen, de harddisk uit m'n Linux machine staat op het punt om dood te gaan
Dus ik ben nu bezig om alles te backuppen en daarna moet ik alles opnieuw installeren.

[ramonp]

Zo een nieuwe Linux machine is up-and-running
Dus weer tijd om het e.a. te doen.

Goed er is wederom een nieuwe versie uit v.0.180, er zijn een aantal kleine dingen aangepast.

• Geen database wijzigingen, dus alleen de bestanden moeten worden vervangen.
• Gnuplot aangepast, zodat het (nu wel) goed onder Windows werkt.
• E.a. aangepast m.b.t. de update
• Updatelog.php aangepast, zodat deze goed werkt met deze versie.
• Serverinfo aangepast, zodat er geen eventuele lege velden kunnen ontstaan wanneer de proxy niet draait.

Het dupes gedeelte ben ik nog mee bezig, maar is nog niet klaar. Komt waarschijnlijk in de volgende versie.

[luie-steffie]

Is er nog work in progress op een van de 2 stats ?
Die van Madman81, of die van Ramonp ?

[ramonp]

luie-steffie schreef op maandag 27 februari 2006 @ 23:19:
Is er nog work in progress op een van de 2 stats ?
Die van Madman81, of die van Ramonp ?

Ik heb er momenteel niet veel tijd voor, dus blijft het een beetje liggen.

[Brede P]

luie-steffie schreef op maandag 27 februari 2006 @ 23:19:
Is er nog work in progress op een van de 2 stats ?
Die van Madman81, of die van Ramonp ?

Voor zover ik weet, zijn die van Madman81 volledig up and running (kijk maar op de statspagina van www.dsmarty.com ).

[ge-flopt]

KICK!!! (Zie het topic gaan als een raket omhoog)

Weer eens aan het stoeien geweest met stats. Uiteindelijk PHPstats er maar opgezet. Nu kom ik alleen bij 1 probleem. Ik kan niet ingelogd komen met het admin account. Ik heb geprobeerd om met admin, Admin ed in te loggen en het standaard wachtwoord password . Maar helaas. Ook nog een ander account aangemaakt, maar helaas. Krijg constant de melding: Login failed .

het geheel draait op Mysql 5, Apache 2 en PHP 5. Iemand een idee?

[radial]

ge-flopt schreef op vrijdag 09 juni 2006 @ 14:47:
KICK!!! (Zie het topic gaan als een raket omhoog)

Weer eens aan het stoeien geweest met stats. Uiteindelijk PHPstats er maar opgezet. Nu kom ik alleen bij 1 probleem. Ik kan niet ingelogd komen met het admin account. Ik heb geprobeerd om met admin, Admin ed in te loggen en het standaard wachtwoord password . Maar helaas. Ook nog een ander account aangemaakt, maar helaas. Krijg constant de melding: Login failed .

het geheel draait op Mysql 5, Apache 2 en PHP 5. Iemand een idee?

Probeer eens met admin/admin ? er staat me iets van bij dat het best wel simpel was

[ge-flopt]

Ik heb getest door het originele wachtwoord met md5 te bewerken en dan krijg ik de zelfde hash string terug als in de database staat.

UPDATE extra info:
Wat ik overigens wel vreemd is dat in de 0.175 zip file de aq directory niet gevuld is. Ik heb dus uit de 0.175 Beta zip deze dir overgenomen.

[ Voor 39% gewijzigd door ge-flopt op 10-06-2006 18:08 ]

[ge-flopt]

Kick, anyone?

[MeneerKrab]

ik kreeg het niet werkende onder windows. Toen ik linux probeerde draaide hij als een zonnetje. misschien dat het daar aan ligt.

[ge-flopt]

Ik draai het ook onder linux

[Wortelsoep]

Werkt phpstats eigenlijk ook goed voor OGR? Ik meen dat ik het ooit eens had geprobeerd maar dat ik er niet echt wijs uit werd..
Het ziet er namelijk wel erg mooi uit allemaal. ppstats wordt nu toch wel echt oud.

[ge-flopt]

Kan inmiddels inloggen. Ben wat aan het spitten geweest, en heb wat aangepast. Denk dat het een groot verschil maakt of je phpstats op php4 en/of php5 draait.

[ge-flopt]

Heb uiteindelijk ook besloten omdat ik op wat dingetjes uit kwam die ik niet prettig vond, om eens te kijken of ik zelf iets kan bouwen. U hoort nog van me

[D2DM]

ip samenvoeg vraagje; ppstats 7.2.0c (debian)

(Alle clients .ini bestand hebben hetzelfde e-mail adres/domein.)
Er staan een aantal inactieve ip's in m'n host lijst, hoe voeg ik deze toe aan actieve ip's.
Bijv. inactief ip: 10.0.0.157 samenvoegen met actief ip 10.0.0.159, zonder .158.

Ranges zijn hiervoor ongeschikt
http://www.dutchpowercows.org/doc.php?id=61
Je kunt met rc5-ip.cons instellen dat ip ranges als 1 'host' vermeld moeten worden.

en uit: Config in "Hulp nodig met mijn stats pagina"
# Consolidate numbers in hosts? ie, host12.myisp.com -> host?.isp.com
# See rc5-ip.cons for a list of ip addresses you wish to manual consolidate.

--
Stripcache?
Striplog, de downloadlinks die ik tegenkom werken niet. Waar is dit te halen?
http://users.belgacom.net/pinball/ + doorverwijzing werkt niet.
--
Voor evt. volgende versie:
- hitparade day, month, alltimehigh pakt rc5.flags wijziging (NL op .com) goed op.
hitparade week en By domain niet.
- Serversysteem specs optioneel weergeven. Zoals onderaan op deze page: http://www.dsmarty.com/stats-rc5.html
- Executive Team Summary Total CPU vervangen door Total CPU Types

[ Voor 36% gewijzigd door D2DM op 06-10-2006 15:03 ]