Sitemap erstellen dauert ewig und Load explodiert

[DSL-Vogel]

Hallo Community,
ich betreibe eine Communityseite und biete einige Downloads zu Spielen an. Pachtes, Demos etc.
Pro Tag habe ich ca. 10.000 Unique Visitors auf der Seite.

Jetzt dachte ich mir ich erstelle mal Sitemaps damitt google sich da was leichter tut.

Ich hab 43 tar.gz access files die habe ich nun einmal komplett durchladen lassen. Sind rund 250.000 Links drin. Jetzt dachte ich mir ich lasse die ersten 3 Access Files nur durchlaufen da das ja sonst immer 4 Tage dauert.

Wenn ich jetzt das Script anstosse dann läuft das vorneweg 7 Stunden. Der Server hat dabei eine Load von rund 5. Da da noch andere Crons ausgeführt werden wird mir das ganze bissel eng.

Wie handhabt ihr das so? Habt ihr alle Quad-CPU am start oder mache ich das einfach falsch? Ich will natürlich so viel wie möglich in die Sitemaps packen. Logisch, sonst brauch ich das nicht.

Mal eine Frage am Rand. Sagen wir mal ich stelle um 19h ein Demo online und möchte damit so schnell wie möglich bei google gelistet sein. Reiche ich dann einfach die Sitemap neu ein oder wie praktizuere ich das dann?

Sofern ihr für die Problemlösung noch Daten benötigt lasst es mich wissen.

Bis dahin danke ich euch schonmal für eure Zeit und Mühe mir zu helfen.

Gruß
Vogel

[seonewbie]

Hallo DSL-Vogel,

du mußt dem cronjob nur gewisse CPU resourcen
zuordnen b.z.w. dem Task den der cronjob starten
z.b. tar, sonst hat der Apache und der Rest der Task
zu wenig power.

Stichwort "CPU Loadbalancing" und
"hochverfügbarkeitsserver patch"


Gruß

Micha

[DSL-Vogel]

Hallo,
allet schön und gut aber dann brauch ich ja noch länger für das erstellen. dann rennt das ja immer und bleibt garnciht mehr stehen.

[DSL-Vogel]

Na, wo sind die Profis?

[To-Bi-As]

@DSL-Vogel
Bin in dem Fall zwar alles andere als ein Profi, aber ich habe meine Sitemaps auch mit über 375.000 Seiten. Die Erstellung dauert weniger als 90 Sekunden.

Was ich allerdings mache, ich nutze nicht die Apache-Logs, dann da kommt zu vieles doppelt und dreifach und sonstwas vor. Auch die 301er oder die 404er.

Ich schreibe meine gültigen URLs als Hash und URL in eine DB (unique) und aus der erstelle ich dann die Sitemaps 2x pro Tag per Cron. Die Tabelle dafür "frisst" zwar knapp 109 MB, aber damit kann ich leben. Der Load dabei ist bei mir auch etwas um die 7, aber eben nur sehr kurz, und ich hänge hier auf nem popligen vServer (Intel Celeron 2400 MHz mit 256 MB RAM).

Die 109MB aber auch nur, weil ich noch Statistiken über einen Ping zu GEO-Diensten und das Änderungsdatum speichere. (Will ja nicht ständig pingen ) Und die gespeicherte ID braucht es an sich auch nicht bei mir.

Gruß, Ingo

[DSL-Vogel]

Hallo To-Bi-As,
ich hab dir diesbezüglich nochmal eine PM geschickt da ich nicht verstehe wie das so umsetzbar ist.
Mich wundert nur dass du scheinbar der einzige bist der so eine Lölsung hat. Alle anderen scheinen da wirklich QuadCore Prozessoren am laufen zu haben

Gruß
Vogel

[linux]

als erster was für ein server

virtueller, root ,windows ...?

wenn es ein echter server ist also root server,sollte das kein problem sein,ok der ram kann ein problem sein denn 512 sollten es schon sein.

wenn eslinux ist und du ssh hast kannst du mit top sehen wie der ausgelastet ist, solltest du im top bein tar entpacken oft kswap sehen hast du ein problem. dann mit free nachsehen wieviel ram noch frei ist

sollte der sever auf den swap= virtuelle memory auf festplatte zugreifen hast du ein problem,denn dann ist das entpacken um den faktor 200 langsamer, denn soviel langsamer ist die festplatte im gegensatz zum ram


gruß

linux

[To-Bi-As]

@linux
Deine Gegenfragen sind gut, aber gerade bei den Google-Sitemaps nicht wirklich relevant. (oder schreibt uns Google nun schon die Hardware vor) Das Problem dort ist, dass man zig Logfiles durchchecken muss um an die URLs zu kommen und das sind dann dennoch nicht alle. Aber all die doppelten URLs und die nicht benötigten Bilder, CSS, JS, Header 404, 302, 301 oder sonstwas stehen da auch drinne.

Das Script von Google ist sicherlich brauchbar, aber nicht mehr wenn eine gewisse Größe der Webseite überschritten wurde. Da braucht man dann eigene Tools die effizienter arbeiten.

Ich für meinen Fall nutze bei jedem Aufruf Millisekunden extra um mir dann das Gedönse mit den Logfiles zu ersparen.

@DSL-Vogel
Hast eine Antwort per PN.

Gruß, Ingo

[linux]

@To-Bi-As

jupp denn ne mysql kann viel, und ein xml output aus der datenbank ist auch schnell gemacht die seiten müssen ja auch generiert werden. ab einer gewissen größe und user zahl geht nix über eigene entwicklungen.ich kenne so open source foren software die noch nie was indexen und so was gehört haben.


gruß

linux

[To-Bi-As]

@linux
Jep, so meine ich das. Alles rein in MySQL (oder was auch immer) und dann den XML-Output davon. Da muss dann nicht mehr sortiert, gefiltert oder sonstwas werden. Die Daten stimmen dann einfach wenn die Erfassung richtig war. Benötigt zwar weiteren DB-Speicherplatz, aber der ist in der Regel eh vorhanden. Und dann dauert das nur wenige Sek bis die Db ausgelesen ist und die Files angelegt wurden.

Wie gesagt, nix gegen das Tool von Google, das funzt schon, aber wenn wie bei mir bei jedem Aufruf der Seite min 20 Einträge im Log stehen ist das nicht effizient, denn nur einer davon ist für die Sitemap, wenn das nicht gerade die gleichen Seiten waren.

Zumal ja noch dazu kommt, dass in den Logs die Zugriffe der Sumas nicht berücksichtigt werden. Die sitemap_gen.py nimmt ja alles was da ist, auch wenn es der Google-Spider selbst war, oder der von Yahoo oder MSN ode sonstwas - Eintrag ist Eintrag.

Bezüglich den Foren. Die kenne ich auch. 1,4 GB im SearchIndex und Suchanfragen von über 2 Minuten.... Das Script nenne ich nun lieber nicht, ist aber kein OpenSource.

Gruß, Ingo