nicht angemeldet
zufallswert von [a-z] bis datei gefunden
0 0 0 0
zufallswert von [a-z] bis datei gefunden
hallo
gibt es einen code der eine unbekannte datei sucht in dem der code alphabetisch von a-z und von 1-0 solange versucht bis er die datei gefunden hat, wenn der code dann unter allen versuchten zeichen keine datei gefunden hat ||datei nicht gefunden;
mfg
peter
-
Halihallo
gibt es einen code der eine unbekannte datei sucht in dem der code alphabetisch von a-z und von 1-0 solange versucht bis er die datei gefunden hat, wenn der code dann unter allen versuchten zeichen keine datei gefunden hat ||datei nicht gefunden;
Den Code gibt's, aber die aufzuwendende Zeit dazu ist nich zahlbar.
Selbst bei dem alten 8+3 Dateinamen wartest du Jahre auf ein Ergebnis... Dieses Verfahren nennt sich Bruteforce und ist nicht effizient.Viele Grüsse
Philipp
-
Sorry ich meine Ordner/ist ja vom Prinzip dass selbe
Z.B
datei/$sucheBistDuEinenOrdnergefundenhast || nix gefunden;Erklärung für die komplizierte/umständliche methode:
get(fremdeurlbesuchen) funktioniert manchmal nicht
mein cgi kann ja nicht von anderen servern die datei im ordner finden deswegen soll es versuchen bis es gefunden wird
mfg peter
-
Halihallo
Das ist, gelinde ausgedrückt, Schwachsinn. Mit dem wirst du nie was erreichen. Was willst du machen? - Die ganze fremde Website runterladen?
Gehen wir mal von kleinen Dateinamen aus (8+3), obwohl das nicht mehr gängig ist. Du beschränkst die Zeichen auf eine Anzahl von 26 + 10 (Achtung, es gibt bekanntlich auch Systeme, die Klein-/Grosschreibung unterscheiden + andere Zeichen erlaubt), dann hast du eine Datei in Durchschnittlich 36^8 / 2 Schritten gefunden (als Dateiextension nehmen wir mal pauschal .htm). Was meinst du, wielange dein Script selbst bei der besten INet-Anbindung für 36^8 HTTP-Zugriffe braucht? - Und wir sprechen hier immer noch von nur einer Datei!Lass dir was anderes einfallen.
Viele Grüsse
Philipp
-
Hi!
Habe übrigens zufällig mal wieder eine "alte" CT (18/02 S.174) rausgekramt, da gar es nämliche einige interessante Artikel bzgl. Server-Performance. Du erinnerst Dich sicher noch an unseren Test diesbezüglich? Jedenfalls war da ein Vergleichstest zw. einem Apple xServe (mit G4(7450), 1Ghz prozessor) gegen Dell (x86, Pentium III 1,4 Ghz, SCSI) beide mit 256 MB DDRRAM, lagen beide um 5000 EUR.
Apache konnte bei beiden ca. 1300 Seiten pro Sekunde ausliefern(html), nur wenn das ganze mehr Performance kostet war der x86 dem G4 haushoch überlegen, ca. 50%.
Bei CGI Scripten lag der Dell noch bei 200/s, bei PHP/MySQL 80/s, bei SSL 65/s(wobei sie das irgendwie mit "keepalive" auf ca. 400 steigern konnten, aber das habe ich nicht richtig verstanden - schade eigentlich, könnte ich gut gebrauchen ;-)).Worauf ich aber hinaus will, das sind keine geteilten/gehosteten Server, sondern eigene relativ aktuelle und hochwertige Modelle. bei den Servern wie wir das versucht hatten, die waren zum einen garantiert erheblich biliger und langsamer, außerdem teiltn wir die Performance mit alen anderen Kunden auf dem Server, also waren die Ergebnisse realistisch.
Ich verstehe zwar nicht, warum Server mit so schwachen Prozessoren so teuer sein können, ich denke man bekommt das schon erheblich schneller hin, z.B. mit 2 Xeon oder Athlon MP, oder noch besser man wartet auf den 64Bit von AMD. So wie ich mich jetzt informiert habe wird das erheblich performanter sein, als ein vergleichbar teuerer PowerPC oder Alpha, vor allem da bei den x86er Prozessoren die letzte Zeit erheblich mehr und schneller entwickelt wurde.
Dann braucht man eine schön schnelle SCSI Festplatte, am besten eine kleinere extrem schnelle und eine große, und eine vernünftige Internetanbindung, 144KB oder sowas kann man vergessen. Selbstverständlich so viel RAM wie möglich, möglichst 4GB, ECC, registered.
Wenn man das hat ist man schon recht flott denke ich, sonst hilft nur noch Load-balancing oder Clustering, aber davon habe ich noch weniger Ahnung und das wird dann immer teuerer. Ich weiß auch nicht ob man lieber einen professionellen Server von IBM oder Compaq einsetzen sollte, vermutlich sind die nicht so performant, aber dafür ausfallsicher und haben guten Support. Aber dafür könnte man ja zur Sicherheit einen 2. "backup-Server" verwenden, der zur Not einspringt, möglichst automatisch und ein einem anderen LAN, z.B. in einem Rechnezentrum bei einem Provider, nur wie das funktionieren könnte weiß ich nicht ;-)
Ich denke das größte Problem ist die Anbindung, denn das ist richtig teuer, denke das wird billiger wenn man den eigenen Server in irgendeinem gut angebundenen Rechenzentrum "housen" läßt.
Die 2. Sache ist die mit CGI gegen Apache, wie Du siehst kannst Du Deine Performance durch eine reine Apache-Lösung nochmal fast ver-sieben-fachen! Und wenn das nicht reicht, ich denke auch das performanteste wird sein sich einen eigenen schlanken "HTTP-Server" in C++ zu programmieren, das dürfte nochmal erheblich schneller sein, denn Du brauchst den Apache ja eigentlich gar nicht, es geht ja nur ums Loggen.Grüße
AndreasPS: Wens interessiert, ich beziehe mich auf folgenden Thread aus dem Archiv:</archiv/2002/7/18332/>
-
Hallo!
Wollte eigentlich den Titel ändern, aber da wars schon zu spät: </?m=147282&t=26964>
Grüße
Andreas -
Halihallo Andreas
Habe übrigens zufällig mal wieder eine "alte" CT (18/02 S.174) rausgekramt, da gar es nämliche einige interessante Artikel bzgl. Server-Performance. Du erinnerst Dich sicher noch an unseren Test diesbezüglich?
Ach, ja, das nenne ich ein schönes Wochenende :-)
Jedenfalls war da ein Vergleichstest zw. einem Apple xServe (mit G4(7450), 1Ghz prozessor) gegen Dell (x86, Pentium III 1,4 Ghz, SCSI) beide mit 256 MB DDRRAM, lagen beide um 5000 EUR.
Apache konnte bei beiden ca. 1300 Seiten pro Sekunde ausliefern(html),
Ja, wobei wir ja insbesondere mod_perl testen wollten.
Bei CGI Scripten lag der Dell noch bei 200/s, bei PHP/MySQL 80/s, bei SSL 65/s(wobei sie das irgendwie mit "keepalive" auf ca. 400 steigern konnten, aber das habe ich nicht richtig verstanden - schade eigentlich, könnte ich gut gebrauchen ;-)).
Hm. Ja, wir kamen ja leider nur auf 13/s, Matti hat's jedoch auch auf diese Grössenordnung geschafft.
Worauf ich aber hinaus will, das sind keine geteilten/gehosteten Server, sondern eigene relativ aktuelle und hochwertige Modelle. bei den Servern wie wir das versucht hatten, die waren zum einen garantiert erheblich biliger und langsamer,
Die Technik musste den Server, wo ich gehost werde, wohl wegen mir mit RAM auf 1GB aufrüsten, 512MB Std, 733MHz AMD (ich glaube Dual?). Naja, die schnellsten sind's bestimmt nicht...
außerdem teiltn wir die Performance mit alen anderen Kunden auf dem Server, also waren die Ergebnisse realistisch.
Stimmt. Wobei ich Samstag Nacht nicht grad relevant für Stat. Tests halte :-)
Ich verstehe zwar nicht, warum Server mit so schwachen Prozessoren so teuer sein können, ich denke man bekommt das schon erheblich schneller hin, z.B. mit 2 Xeon oder Athlon MP, oder noch besser man wartet auf den 64Bit von AMD.
s'ist ja nicht die Prozessorleistung, von der was erwartet wird (klar, auch), aber bei Servern sind ja andere Dinge zentraler.
Wenn man das hat ist man schon recht flott denke ich, sonst hilft nur noch Load-balancing oder Clustering,
Ja, Load-Balancing wird dann interessant, wenn man 2000/s aushalten muss... Dann stellt man 10 redundant ausgelegte Rechner hinter ein load-balancer, der eine virtuelle IP hat und die Requests gleichmässig auf die 10 Rechner verteilt und fertig...
aber davon habe ich noch weniger Ahnung und das wird dann immer teuerer. Ich weiß auch nicht ob man lieber einen professionellen Server von IBM oder Compaq einsetzen sollte, vermutlich sind die nicht so performant, aber dafür ausfallsicher und haben guten Support. Aber dafür könnte man ja zur Sicherheit einen 2. "backup-Server" verwenden, der zur Not einspringt, möglichst automatisch und ein einem anderen LAN, z.B. in einem Rechnezentrum bei einem Provider, nur wie das funktionieren könnte weiß ich nicht ;-)
Ich denke das größte Problem ist die Anbindung, denn das ist richtig teuer, denke das wird billiger wenn man den eigenen Server in irgendeinem gut angebundenen Rechenzentrum "housen" läßt.Weisst du, was in der Schweiz eine schnelle Inet-Anbindung kostet? - Musst dir mal die Webspace-Preise in der Schweiz ansehen, die Anbindungskosten werden auf den Kunden abgewälzt... Da ist es wesentlich sinnvoller in der EU eine Server housen zu lassen, da muss ich dir recht geben.
Die 2. Sache ist die mit CGI gegen Apache, wie Du siehst kannst Du Deine Performance durch eine reine Apache-Lösung nochmal fast ver-sieben-fachen! Und wenn das nicht reicht, ich denke auch das performanteste wird sein sich einen eigenen schlanken "HTTP-Server" in C++ zu programmieren, das dürfte nochmal erheblich schneller sein, denn Du brauchst den Apache ja eigentlich gar nicht, es geht ja nur ums Loggen.
Ich tendiere auf Letzteres. Da ich nach wie vor nicht ganz davon überzeugt bin, dass ich alles in den Log finden kann, was ich bräuchte (OK, man könnte ein eigenes Apache-Modul programmieren)... Zudem: Auswerten müsste ich dann dennoch alles und das ist ja das performanceverschlingende...
Viele Grüsse und besten Dank für die Infos
Philipp
-
Hallo Philipp!
Ach, ja, das nenne ich ein schönes Wochenende :-)
jep ;-)
Jedenfalls war da ein Vergleichstest zw. einem Apple xServe (mit G4(7450), 1Ghz prozessor) gegen Dell (x86, Pentium III 1,4 Ghz, SCSI) beide mit 256 MB DDRRAM, lagen beide um 5000 EUR.
Apache konnte bei beiden ca. 1300 Seiten pro Sekunde ausliefern(html),Ja, wobei wir ja insbesondere mod_perl testen wollten.
Ist doch wie CGI, oder?
Bei CGI Scripten lag der Dell noch bei 200/s, bei PHP/MySQL 80/s, bei SSL 65/s(wobei sie das irgendwie mit "keepalive" auf ca. 400 steigern konnten, aber das habe ich nicht richtig verstanden - schade eigentlich, könnte ich gut gebrauchen ;-)).
Hm. Ja, wir kamen ja leider nur auf 13/s, Matti hat's jedoch auch auf diese Grössenordnung geschafft.
Ja, das war wirklich nicht gut, bei meinem kamen wir immerhin auf über 30, wenn ich mich nicht irre. Ist halt alles ne Sache der Hardware und deren Auslastung!
Worauf ich aber hinaus will, das sind keine geteilten/gehosteten Server, sondern eigene relativ aktuelle und hochwertige Modelle. bei den Servern wie wir das versucht hatten, die waren zum einen garantiert erheblich biliger und langsamer,
Die Technik musste den Server, wo ich gehost werde, wohl wegen mir mit RAM auf 1GB aufrüsten, 512MB Std, 733MHz AMD (ich glaube Dual?). Naja, die schnellsten sind's bestimmt nicht...
Das glaube ich auch ;-) aber wie ist das eigentlich, braucht men hierfür überhaupt so viel Ram? Ich meine, es handelt sich ja um GET-Requests, und ausgeliefert wird ein 1x1.gif, oder? Das sollte doch in beide Richtungen höchtens 0,5 KB Übertragungsvolumen ausmachen, oder? Wird da großartig was in den Arbeitsspeicher geladen? Naja, ich weiß jetzt nicht wie rechenintensiv das schreiben in eine Log-Datei ist, vermutlich lächerlich. Und das auslesen und umwandeln der HTTP-HEADER Daten dürfte auch nicht so wild sein.
außerdem teiltn wir die Performance mit alen anderen Kunden auf dem Server, also waren die Ergebnisse realistisch.
Stimmt. Wobei ich Samstag Nacht nicht grad relevant für Stat. Tests halte :-)
Was ein schlechtes Licht auf die Hardware, Anbindung oder was weiß ich Deines Providers wirft!
Ich verstehe zwar nicht, warum Server mit so schwachen Prozessoren so teuer sein können, ich denke man bekommt das schon erheblich schneller hin, z.B. mit 2 Xeon oder Athlon MP, oder noch besser man wartet auf den 64Bit von AMD.
s'ist ja nicht die Prozessorleistung, von der was erwartet wird (klar, auch), aber bei Servern sind ja andere Dinge zentraler.
Was denn? Ich weiß eigentlich einigermaßen was in so ein Gerät rein sollte. OK, die nehmen dann hochwertige Komponenten, und testen das Zusammemnspiel dieser, bis das ganze sehr ausfallsicher läuft. Aber 5.000 EUR fand ich dann doch ein wenig übertrieben, und dann auch noch Dell, will nicht wissen was sowas von IBM,HP,Compaq oder SUN kostet!
Und gerade bei dieser Anwendung kommt es doch hochgradig auf die Prozessolleistung an, OK, die anderen Komponenten wie Festplatte, FSB... müssen entsprechend schnell sein, überhaupt die gesamten Datenleitungen müssen schnell genug sein, die ganze Power zu nutzen. Aber gerade das ist ja bei x86 auch verhältnismäßig schnell! PowerPC... sind doch auch hier langsamer, denn man hat da irgendwelche anderen Argumente, wie sie hier in einem vergangenen Thread von Euch auch aufgezählt wurden(wo ich es leider vepeilt habe zu antworten, sorry), aber am Ende, ich habe bisher keine aussagekräftigen Benchmarks gesehen, die sagen dass ein Server mit Alpha, oder PowerPC im Bereich um 5000 EUR schneller ist als ein X86 für einen vergleichbaren Preis. Eher umgekehrt! Aber ich finde da auch nichts vernünftiges bei Google :-(Wenn man das hat ist man schon recht flott denke ich, sonst hilft nur noch Load-balancing oder Clustering,
Ja, Load-Balancing wird dann interessant, wenn man 2000/s aushalten muss... Dann stellt man 10 redundant ausgelegte Rechner hinter ein load-balancer, der eine virtuelle IP hat und die Requests gleichmässig auf die 10 Rechner verteilt und fertig...
Wenn einer der oben beschriebenen Rechner über 1300 Seiten pro Sekunde ausliefern soll, würde ich mal behaupten, mit etwas schnellerer Hardware, wie beshreiben schafft man locker über 2000! Und wenn man sich dan noch den "Logging-Server" in C++ schreibt kann man das nochmal erheblich steigern denke ich mal.
Wobei Google mit dem Cluster von Billigrechnern(Celeron!) anscheinend auch ziemlich gut fährt, interessantes Thema!
Nochwas, die Werte bezogen sich auf eine 8KB große HTML-Datei, wenn das ganze über eine 1GB-Leitung angebunden wird, schafft der Apache fast 3000! Und die muß man erstmal haben! (Requests _und_ Gbit-Anbindung ;-))Die 2. Sache ist die mit CGI gegen Apache, wie Du siehst kannst Du Deine Performance durch eine reine Apache-Lösung nochmal fast ver-sieben-fachen! Und wenn das nicht reicht, ich denke auch das performanteste wird sein sich einen eigenen schlanken "HTTP-Server" in C++ zu programmieren, das dürfte nochmal erheblich schneller sein, denn Du brauchst den Apache ja eigentlich gar nicht, es geht ja nur ums Loggen.
Viele Grüße
Andreas-
Halihallo Andreas
Jedenfalls war da ein Vergleichstest zw. einem Apple xServe (mit G4(7450), 1Ghz prozessor) gegen Dell (x86, Pentium III 1,4 Ghz, SCSI) beide mit 256 MB DDRRAM, lagen beide um 5000 EUR.
Apache konnte bei beiden ca. 1300 Seiten pro Sekunde ausliefern(html),Ja, wobei wir ja insbesondere mod_perl testen wollten.
Ist doch wie CGI, oder?Das eine hat mit dem anderen weniger zu tun (bzw. ersetzt es nicht). auch in mod_perl gibt's die CGI-Schnittstelle. Das einzige, was mod_perl macht, ist, dass das CGI-Script nicht als neuen Prozess gestartet wird, sondern dass alle Scripts über denselben mod_perl Prozess abgearbeitet werden. mod_perl ist die Schnittstelle zwischen Apache-Webserver und Script. Authentification, Sessionmanagement, gemeinsamer Speicher, schnellerer start-up der Scripts, da der Interpreter bereits im Speicher ist... etc. etc. etc.
Bei CGI Scripten lag der Dell noch bei 200/s, bei PHP/MySQL 80/s, bei SSL 65/s(wobei sie das irgendwie mit "keepalive" auf ca. 400 steigern konnten, aber das habe ich nicht richtig verstanden - schade eigentlich, könnte ich gut gebrauchen ;-)).
Worauf ich aber hinaus will, das sind keine geteilten/gehosteten Server, sondern eigene relativ aktuelle und hochwertige Modelle. bei den Servern wie wir das versucht hatten, die waren zum einen garantiert erheblich biliger und langsamer,
Die Technik musste den Server, wo ich gehost werde, wohl wegen mir mit RAM auf 1GB aufrüsten, 512MB Std, 733MHz AMD (ich glaube Dual?). Naja, die schnellsten sind's bestimmt nicht...
Das glaube ich auch ;-) aber wie ist das eigentlich, braucht men hierfür überhaupt so viel Ram? Ich meine, es handelt sich ja um GET-Requests, und ausgeliefert wird ein 1x1.gif, oder?Nun, man kann nie genug haben :-)
Der Tag alleine bräuchte nicht soviel Speicher. Jedoch läuft die Synchronisation auf dem selben Rechner und dieses Programm braucht dann schon etwas mehr Speicher, da sozusagen eine Main-Memory-Database betrieben wird, um die Daten zu analysieren (Voranalyse) und die Sync-Datenstruktur aufzubauen, die dann auf den Hauptserver übertragen wird. Die Server für den Statistik-Tag benutzt keine mysql-Datenbank, diese liegt auf dem Hauptserver...Das sollte doch in beide Richtungen höchtens 0,5 KB Übertragungsvolumen ausmachen, oder? Wird da großartig was in den Arbeitsspeicher geladen?
Jeweils die Statistik mehrerer Websites/Pages über eine Stunde; jeder Request. Diese geben schon eine nette Main-Memory-Tabelle. Dann wird alles analysiert und auf Requests/Stunde kummuliert, diese Daten werden dann übertragen. Der Transport zum Hauptserver besteht dann nur noch aus 8-10 Statistikeinträgen pro Page und Stunde. Durch die Voranalyse wird der Hauptserver nicht so sehr belastet.
Naja, ich weiß jetzt nicht wie rechenintensiv das schreiben in eine Log-Datei ist, vermutlich lächerlich. Und das auslesen und umwandeln der HTTP-HEADER Daten dürfte auch nicht so wild sein.
Ja, der Tag alleine ist relativ simpel, obwohl bereits der ca. 20A4 Seiten Code hat. Die Sync braucht aber schon etwas mehr Performance. Aber da die Statistik-Server keine RDBMS verwenden und auf Flat-File-Basis arbeiten, ist die Performance doch ziemlich gut.
außerdem teiltn wir die Performance mit alen anderen Kunden auf dem Server, also waren die Ergebnisse realistisch.
Stimmt. Wobei ich Samstag Nacht nicht grad relevant für Stat. Tests halte :-)
Was ein schlechtes Licht auf die Hardware, Anbindung oder was weiß ich Deines Providers wirft!Ja, da muss ich dir recht geben :-)
Ich verstehe zwar nicht, warum Server mit so schwachen Prozessoren so teuer sein können, ich denke man bekommt das schon erheblich schneller hin, z.B. mit 2 Xeon oder Athlon MP, oder noch besser man wartet auf den 64Bit von AMD.
Wenn man das hat ist man schon recht flott denke ich, sonst hilft nur noch Load-balancing oder Clustering,
Ja, Load-Balancing wird dann interessant, wenn man 2000/s aushalten muss... Dann stellt man 10 redundant ausgelegte Rechner hinter ein load-balancer, der eine virtuelle IP hat und die Requests gleichmässig auf die 10 Rechner verteilt und fertig...
Wenn einer der oben beschriebenen Rechner über 1300 Seiten pro Sekunde ausliefern soll, würde ich mal behaupten, mit etwas schnellerer Hardware, wie beshreiben schafft man locker über 2000! Und wenn man sich dan noch den "Logging-Server" in C++ schreibt kann man das nochmal erheblich steigern denke ich mal.Ja, an Load-Balancing muss ich auch noch nicht denken. Es ist ja auch eine Kostenfrage... Ich denke, dass wir gut mit den "konventionellen" Methoden auskommen. Ich meine, stell dir mal diese Zahlen vor: 2000/s => 5.2 Milliarden Requests pro Monat... Darauf muss man schon mal kommen...
Wobei Google mit dem Cluster von Billigrechnern(Celeron!) anscheinend auch ziemlich gut fährt, interessantes Thema!
die 80%-Philosophie... Für die letzten 20% Zahlt man soviel, wie für die ersten 80%. Da kauft man sich lieber zweimal die 80% und kommt auf 160%, als wenn man einen 100%-er kauft...
Die 2. Sache ist die mit CGI gegen Apache, wie Du siehst kannst Du Deine Performance durch eine reine Apache-Lösung nochmal fast ver-sieben-fachen! Und wenn das nicht reicht, ich denke auch das performanteste wird sein sich einen eigenen schlanken "HTTP-Server" in C++ zu programmieren, das dürfte nochmal erheblich schneller sein, denn Du brauchst den Apache ja eigentlich gar nicht, es geht ja nur ums Loggen.
...und analysieren, ja. Jetzt müsste ich nur noch wissen, wie ich Sockets und Daemonen mit C++ programmiere :-)
Aber mit Zeit kommt Rat :-)
Bisher habe ich grad mal gelernt, wie ich txt-Dateien mit C++ bearbeiten kann und schon da scheiterts. Getestet unter cygwin/gcc beim einlesen einer txt-Datei: "STATUS_ACCESS_VIOLATION" - handle_exeption... Naja, wenn ich die Zeit habe, widme ich mich diesem Problem. Jetzt stehen noch einige pendentere Sachen auf meiner 4-A4 Seiten todo-Liste :-((Viele Grüsse
Philipp
-
HI!
Das eine hat mit dem anderen weniger zu tun (bzw. ersetzt es nicht). auch in mod_perl gibt's die CGI-Schnittstelle. Das einzige, was mod_perl macht, ist, dass das CGI-Script nicht als neuen Prozess gestartet wird, sondern dass alle Scripts über denselben mod_perl Prozess abgearbeitet werden. mod_perl ist die Schnittstelle zwischen Apache-Webserver und Script. Authentification, Sessionmanagement, gemeinsamer Speicher, schnellerer start-up der Scripts, da der Interpreter bereits im Speicher ist... etc. etc. etc.
Wolltst du auch http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Log.html benutzen?
Vielleicht könnte man auf diese Weise direkt in mySQL loggen, und wen man eine persistente Verbindung offen hält ist das vermutlich noch nichtmal so langsam!
Aber trotzdem würde ich es probieren direkt vom Apachen machen zu lasen, denn der apache bekommt schließlich alle Informationen, und gibt die seinerseits an ein PERL-Script weiter, man muß halt nur wissen wie man dran kommt.
Habe aber noch 2 Ideen:
1. Man könnte als Log-Format direkt INSTERT-Statements kreieren, so bräuchtest Du nur noch den kompletten Insert am Ende des Tages(um 4 Uhr morgens per Cronjob)
per batch-Mode in mySQL schreiben lassen, also das log Format muß dann in etwa so aussehen(habe sowas noch nie gemacht, also vermutlich mächtig falsch ;-)):LogFormat "(%h,%l,%u,%t,"%r",%>s,%b,"%{Referer}i","%{User-agent}i")," combined
CustomLog log/acces_log combinedDas sollte dann eine Logfle genereiren mit etwa folgendem Inhat:
(bla,bla,bla,...blub),
(bla,bla,bla,...blub),
(bla,bla,bla,...blub),
(bla,bla,bla,...blub),
...Was Du dann noch machst ist diese Datei in einen String zu lesen, nenne den jetzt mal $log, dann brauchst Du für den Cron nur noch:
$complete_sql_statement = "INSERT INTO log_table (spalte_bla,spalte_bla,spalte_bla,...spalte_blub) VALUES $log";
Und dieses übergibts Du noch eben an die Standardeingabe von mysql und hast so massenhaft Daten in kürzester Zeit in der DB. "Filtern"... muß man möglichst schon bem Apache.
2. Möglichkeit wäre, evtl direkt die Datendatei von MYSQL als logfile - Format zu schreiben, ud die eben nur umkopieren, aber da weiß ich nicht ob das geht.
Nun, man kann nie genug haben :-)
Der Tag alleine bräuchte nicht soviel Speicher. Jedoch läuft die Synchronisation auf dem selben Rechner und dieses Programm braucht dann schon etwas mehr Speicher, da sozusagen eine Main-Memory-Database betrieben wird, um die Daten zu analysieren (Voranalyse) und die Sync-Datenstruktur aufzubauen, die dann auf den Hauptserver übertragen wird. Die Server für den Statistik-Tag benutzt keine mysql-Datenbank, diese liegt auf dem Hauptserver...wie gesagt würde ich so viel wie möglich im Apache machen, und we die Tagesdaten in der DB sind denke ich, da sind gerade große Datenmengen besser zu analysieren, oder?
Was meinst Du mit "sync-Datenstruktur"?Jeweils die Statistik mehrerer Websites/Pages über eine Stunde; jeder Request. Diese geben schon eine nette Main-Memory-Tabelle. Dann wird alles analysiert und auf Requests/Stunde kummuliert, diese Daten werden dann übertragen. Der Transport zum Hauptserver besteht dann nur noch aus 8-10 Statistikeinträgen pro Page und Stunde. Durch die Voranalyse wird der Hauptserver nicht so sehr belastet.
Ach so!
Naja, ich weiß jetzt nicht wie rechenintensiv das schreiben in eine Log-Datei ist, vermutlich lächerlich. Und das auslesen und umwandeln der HTTP-HEADER Daten dürfte auch nicht so wild sein.
Ja, der Tag alleine ist relativ simpel, obwohl bereits der ca. 20A4 Seiten Code hat. Die Sync braucht aber schon etwas mehr Performance. Aber da die Statistik-Server keine RDBMS verwenden und auf Flat-File-Basis arbeiten, ist die Performance doch ziemlich gut.
Das kann ich mir gar nicht vorstellen(k.A., nur so vom Gefühl). Ich dachte gerade bei großen Datenmengen und vernünftiger Indezierung ist eine RDBMS erheblich schneller?! Siehe Self-Suche! Oder meinst Du nur die Schreibzugriffe?
Ja, an Load-Balancing muss ich auch noch nicht denken. Es ist ja auch eine Kostenfrage... Ich denke, dass wir gut mit den "konventionellen" Methoden auskommen. Ich meine, stell dir mal diese Zahlen vor: 2000/s => 5.2 Milliarden Requests pro Monat... Darauf muss man schon mal kommen...
Seid Ihr noch nicht? Schwach... ;-)
...und analysieren, ja. Jetzt müsste ich nur noch wissen, wie ich Sockets und Daemonen mit C++ programmiere :-)
Wenn Du das weißt sag Bescheid ;-)
Aber mit Zeit kommt Rat :-)
Bisher habe ich grad mal gelernt, wie ich txt-Dateien mit C++ bearbeiten kann und schon da scheiterts. Getestet unter cygwin/gcc beim einlesen einer txt-Datei: "STATUS_ACCESS_VIOLATION" - handle_exeption... Naja, wenn ich die Zeit habe, widme ich mich diesem Problem. Jetzt stehen noch einige pendentere Sachen auf meiner 4-A4 Seiten todo-Liste :-((Na dann mal viel Spaß ;-)
Grüße
Andreas-
Halihallo Andreas
Das eine hat mit dem anderen weniger zu tun (bzw. ersetzt es nicht). auch in mod_perl gibt's die CGI-Schnittstelle. Das einzige, was mod_perl macht, ist, dass das CGI-Script nicht als neuen Prozess gestartet wird, sondern dass alle Scripts über denselben mod_perl Prozess abgearbeitet werden. mod_perl ist die Schnittstelle zwischen Apache-Webserver und Script. Authentification, Sessionmanagement, gemeinsamer Speicher, schnellerer start-up der Scripts, da der Interpreter bereits im Speicher ist... etc. etc. etc.
Wolltst du auch http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Log.html benutzen?Gedacht habe ich daran, ja. Aber es ist nach wie vor die "Abneigung" gegen das Apache-Logging... Wenn ich einen Stat-Tag über C programmieren kann und dies sogar performanter ist, dann werde ich diesen Weg gehen.
Vielleicht könnte man auf diese Weise direkt in mySQL loggen, und wen man eine persistente Verbindung offen hält ist das vermutlich noch nichtmal so langsam!
Das stimmt. Über mod_perl wäre dies kein Problem, aber ohne ein wesentliches... Bei jedem Pageview eine neue Datenbank-Verbindung??? - Au waya...
Aber trotzdem würde ich es probieren direkt vom Apachen machen zu lasen, denn der apache bekommt schließlich alle Informationen, und gibt die seinerseits an ein PERL-Script weiter, man muß halt nur wissen wie man dran kommt.
Yo. Das Problem ist: Der Apache speichert nur, er verarbeitet nicht. Bei meiner Stat müssen Daten verarbeitet werden und die Ausgabe sieht je nach Besucher anders aus... Aus dem log kann ich nur Daten kriegen, nicht jedoch zum Kunden senden...
Habe aber noch 2 Ideen:
- Man könnte als Log-Format direkt INSTERT-Statements kreieren, so bräuchtest Du nur noch den kompletten Insert am Ende des Tages(um 4 Uhr morgens per Cronjob)
per batch-Mode in mySQL schreiben lassen, also das log Format muß dann in etwa so aussehen(habe sowas noch nie gemacht, also vermutlich mächtig falsch ;-)):
LogFormat "(%h,%l,%u,%t,"%r",%>s,%b,"%{Referer}i","%{User-agent}i")," combined
CustomLog log/acces_log combined[...]
Die Lösung finde ich eigentlich schon OK. Aber wie gesagt: Das Log ist das eine, die Verarbeitung (diese muss aus internen Zwecken zwingend bei jedem Pageview [Realtime] geschehen, um dann die Konsequenz(en) direkt wieder an den Client zu senden (eg. Cookie)).
Nun, man kann nie genug haben :-)
Der Tag alleine bräuchte nicht soviel Speicher. Jedoch läuft die Synchronisation auf dem selben Rechner und dieses Programm braucht dann schon etwas mehr Speicher, da sozusagen eine Main-Memory-Database betrieben wird, um die Daten zu analysieren (Voranalyse) und die Sync-Datenstruktur aufzubauen, die dann auf den Hauptserver übertragen wird. Die Server für den Statistik-Tag benutzt keine mysql-Datenbank, diese liegt auf dem Hauptserver...
wie gesagt würde ich so viel wie möglich im Apache machen, und we die Tagesdaten in der DB sind denke ich, da sind gerade große Datenmengen besser zu analysieren, oder?Keine Tagesdaten; wir haben uns auf stündliche Statistik geeinigt. Die Analyse (die finale-) findet natürlich über die MySQL Datenbank statt. Die Voranalyse in der Synchronisation ist lediglich ein kummulieren der Daten der Requests auf eine Stunde (bzw. Konsequenzen auf andere Stundeneinträge); dazu braucht man keine DB.
Was meinst Du mit "sync-Datenstruktur"?
Die Daten werden ja in einer gewissen Syntax auf den Hauptrechner übertragen. Diese Syntax unterscheidet sich von der eigentlichen Speicherung der Requests. Letzteres Format bezeichnete ich als sync-Datenstruktur. Die Requests werden auf ca. 10'000 Textdateien verteilt gespeichert; diese werden dann im Sync-Vorgang analysiert und die Informationen zusammengetragen (Voranalyse), dann wird die Synchronisations-Datenstruktur aufgebaut und die Daten an den Hauptrechner übertragen. Dieser zerpflückt die Daten wieder uns fügt sie in die mysql-Datenbank ein. Ach, auf einem Server werden natürlich Statistik von mehreren Websites/Pages gemessen...
Naja, ich weiß jetzt nicht wie rechenintensiv das schreiben in eine Log-Datei ist, vermutlich lächerlich. Und das auslesen und umwandeln der HTTP-HEADER Daten dürfte auch nicht so wild sein.
Ja, der Tag alleine ist relativ simpel, obwohl bereits der ca. 20A4 Seiten Code hat. Die Sync braucht aber schon etwas mehr Performance. Aber da die Statistik-Server keine RDBMS verwenden und auf Flat-File-Basis arbeiten, ist die Performance doch ziemlich gut.
Ich dachte gerade bei großen Datenmengen und vernünftiger Indezierung ist eine RDBMS erheblich schneller?!
Das muss man stark relativieren! - Beim Selektieren von Records werden die Indizies stark und sind gigantische Performancebringer. Jedoch beim Einfügen von neuen Records ist es genau umgekehrt. Die Indizies müssen nach dem Einfügen von neuen Records überarbeitet werden u. U. muss die Baumstruktur ziemlich stark geändert werden (Rotation und Doppelrotation von Unterbäumen, dass der ganze Index-Baum wieder ausgeglichen ist). Dies wäre bei meiner Anwendung der Statistik ein grosser Nachteil, da ich gar keine Daten selektieren muss, sondern diese nur eintrage und linear abarbeiten muss. Ein Index bringt mir gar nix.
Siehe Self-Suche!
kenne ich :-)
Oder meinst Du nur die Schreibzugriffe?
es sind eigentlich nur Schreibzugriffe. Deshalb o. genanntes. Klar, ich müsste auch vieles Einlesen, aber bei diesem Einlesen habe ich keine Kriterien und somit würden auch die Indizies nix bringen (im Gegenteil). Das Einlesen kann linear erfolgen (also jeder Record einzeln), das kann man mit flat-file sehr effizient (OK, wenn ich die Daten noch in einem binary-Format abspeichern tät, wärs noch performanter). Ich kann jedoch nicht sagen, ob eine DB performanter als die flat-file Variante von mir wäre; aber der Aufwand einen neuen Stat-Server in das "Netzwerk" einzupflügen wäre etwas grösser (müsste eine mysql-DB einrichten) :-)
Allgemein (also vorausgesetzt, die mysql wäre langsamer oder mindestens gleich schnell) würde ich dennoch zu Flat-File basieren, da dort die Verarbeitung wirklich sau-einfach ist.
Ja, an Load-Balancing muss ich auch noch nicht denken. Es ist ja auch eine Kostenfrage... Ich denke, dass wir gut mit den "konventionellen" Methoden auskommen. Ich meine, stell dir mal diese Zahlen vor: 2000/s => 5.2 Milliarden Requests pro Monat... Darauf muss man schon mal kommen...
Seid Ihr noch nicht? Schwach... ;-)Wenn wir's hätten, würde ich bereits auf den Bahamas hausen :-)
...und analysieren, ja. Jetzt müsste ich nur noch wissen, wie ich Sockets und Daemonen mit C++ programmiere :-)
Wenn Du das weißt sag Bescheid ;-)
Das mit den Sockets hab ich bereits herausgefunden. Durch einen Zufall... Musste mir swissflirt.ch antun (nicht aus eigenen Interessen! *g*), Admanager ist a) Falk und b) AdCycle; bei AdCycle wurde ich aufmerksam (den kannte ich noch nicht) => Website von AdCycle.com ansehen => aha, Shareware-AdManagementSystem, interessant und den Source kann man sich erst noch herunterladen, was ich mir nur für eine einmalige Einsicht antat. Was sehe ich da? - Ein C-Programm mit Sockets :-)
=> man braucht nicht einmal zu googlen :-)Aber mit Zeit kommt Rat :-)
ein Tag später war er da ;)
Bisher habe ich grad mal gelernt, wie ich txt-Dateien mit C++ bearbeiten kann und schon da scheiterts. Getestet unter cygwin/gcc beim einlesen einer txt-Datei: "STATUS_ACCESS_VIOLATION" - handle_exeption... Naja, wenn ich die Zeit habe, widme ich mich diesem Problem. Jetzt stehen noch einige pendentere Sachen auf meiner 4-A4 Seiten todo-Liste :-((
Na dann mal viel Spaß ;-)
ARGHHH! ;)
Viele Grüsse
Philipp
- Man könnte als Log-Format direkt INSTERT-Statements kreieren, so bräuchtest Du nur noch den kompletten Insert am Ende des Tages(um 4 Uhr morgens per Cronjob)
-
-
-
-
-
-
-