Inkrementelle Sitemap um Performance zu sparen

Na ja, wenn es eine Community ist und sich höchstens 2% ändern, dan brauchst Du doch gar keine Sitenmap - bei sowas sollte doch Google in der Lage sein, durch die anständige interne Verlinkung (wenn es diese gibt) alles auch ohne Sitenmap zu finden

Ich würde mir bei Communitys, Foren die Arbeit einer Sitenmap auch höchstesn 1x machen um Google & Co überhaupt mitzuteilen, was zu spiden ist und fertig

Trotzdem schließe ich mich CatCat an, wenn Du bei einem Projekt mit 300.000 Seiten schon Probleme hast, wenn mal viel gekrawelt wird, dann würde ich mir schon nach einem gescheiten Server umsehen

Gruß Dirk

Synonym hat geschrieben:Allerdings würde mich schon mal interessieren wie Du das technisch umsetzen willst.

Einfach die neuen Seiten an die Sitemap anhängen reicht ja nicht. Die Sitemap-Index gehört dann ja auch geändert.

Und was ist wenn eine URL gelöscht wurde? Wie entfernst Du die dann aus der entsprechenden Sitemap ohne die komplett neu zu erstellen (etwa per Cron)?

Meine Seiten sind alle dymanisch. Um genau zu sein Communities. D.h. wenn jemand ein neues Thema eröffnet oder ein Thema die zweite Seite erreicht, wird jeweils die URL automatisiert in die Sitemap gepackt. Dazu setze ich den Filepointer einfach auf das Ende der Datei, springe ein paar Zeilen zurück (um den Footer zu überspringen) und füge die neue Zeile ein.

Geht nun ein Mod hin und entfernt ein Thema, ist das Script weniger performant und geht zeilenweise durch die Datei und sucht die entsprechenden IDs. Wobei ich da die Idee hätte, dass man das Thema mit der ID 90.000 in der 2. Sitemap findet und zwar in Zeile 40.000. Falls Topic IDs nicht mehr vorhanden sind, werden diese Bereiche mit Leerzeilen gefüllt. So die erste Idee. Hab aber noch kein technisches Gesamtkonzept.

Japs hat geschrieben:

....da wir einfach keine Möglichkeit hatten die optimal auszuliefern, ohne gleich einen cronjob aufzubauen oder den Server mit dieser "unendlichen" Schleife ins Nirvana zu jagen etc.

Muß es doch gar nicht wenn Du 1x die Woche oder alle 14 Tage automatisch eine Sitenmap ersteleln läst, dann ist das doch absolut kein Problem.

Ich lasse über Cronjob 1x in 14 Tagen über https://www.xml-sitemaps.com/standalone ... rator.html mir eine neue Sitenmap erstellen und diese wird dann gleich korrekt abgelegt - alles sehr einfach

Gruß Dirk

Alle 14 Tage? Sorry, aber wie willst Du da jemals konkurrenzfähig sein? Also für meine Seite wäre das viel zu langsam und bei der Masse an Seiten auch nicht steuerbar, weil ich da für jede popelige Domain eine Eintragung vornehmen müsste. Dann doch lieber durch mich selbst und automatisiert.

Japs hat geschrieben:

Synonym hat geschrieben:@Japs
Ja und Nein. Das von Dir benannte Tool geht schon, aber wenn die Domain, so wie meine, etwa 300.000 Unterseiten hat, dann geht der Server schon fast offline wenn der Spider da durch jagt.

Sorry, aber dann hoste auf einem besseren Server
Wenn es hier schon Probleme gibt, was machst Du dann wenn Du zb. bei einer Aktion zeitgleich 300.000 Besucher hast - sowas sollte ein Server schon verkraften können Gerade wenn amn so ein großes Projekt laufen hat.

Gruß Dirk

300.000 Besucher zeitgleich? Also 1.000 sind ja schon übel, aber 300.000? Unter "zeitgleich" verstehe ich parallel laufende HTTP-Prozesse und da ist mein Server schon gut mit 100 ausgelastet.

xAaron hat geschrieben:Ist ja beides nur simples Textschieben. Die spannende Frage wäre aber, ob es nicht vielleicht performanter ist bei kleinen sitemap-Dateien wie der index sie einfach neu zu schreiben, als die bestehende zu öffnen, Text einzufügen oder zu ändern und wieder zu schreiben.

Egal wie groß eine Seite ist. Es ist immer schneller eine Datei zu erweitern, statt sie neu zu schreiben.

Oh'man die 300.000 sollten auch nur ein Beispiel sein - von mir aus auch nur 500!
Bei 1000 schon ausgelastet - dazu sag ich jetzt mal nix mehr

@marc, die Reihenfolge der einzelnen Sitemaps macht nur insofern einen Eindruck, als die ersten meiner Erfahrung nach auch zuerst gespidert werden. Mit zunehmender Dauer des Projekts ist das dann wieder egal.

Ein Tipp vielleicht noch: alte Sitemaps ändern sich in einem Forum häufig nicht. Achte dann darauf, dass sich auch die Binärdateien der alten Sitemaps nicht ändern (gleiche Dateigröße und Timestamps). Der Google-Crawler ist schlau und kann mit dem 304 gut umgehen. Du bekommst damit bei großen Sites die neuen Inhalte leichter gespidert.

catcat hat geschrieben:Aso. Ja bei Foren kann ich nicht mitreden. Aber der Server sollte doch trotzdem in der Lage sein ein paar hundertausend Seiten in die Sitemap zu packen?

btw: Ich mache nur 1x ne Sitemap. Magento legt sich selbst neue Sitemaps bei Änderungen an und avisiert die auch bei google/yahoo^^ (Shop für Faule)

Diese Argumentation bringt nichts, weil wir hier von verschiedenen Standpunkten ausgehen. Du sagst, dass Dir die Serverkosten egal sind. Ich denke wirtschaftlich. Nur durch solche Optimierungen kann ich mit einzelnen Servern arbeiten, wo andere schon mit Serverparks anfangen.

Eine Sitemap mag nur ein Teil eines großen ganzen sein, aber ich komme z.B. völlig ohne Cronjobs aus. Egal was für ein Cronjob "gebraucht" wird.

Ich habe z.B. mehrere Millionen Zwischenspeicher lokal hinterlegt. Bei mir wird fast nichts mehr live ausgegeben. Und die Zwischenspeicher werden nie in Intervallen erstellt, sondern immer nur dann, wenn sich die Inhalte geändert haben.

Und zur Argumentation mit den 14 Tagen bei einem Shop etc:
Wer ein neues Produkt erst 14 Tage später crawlen lässt, als er es eingestellt hat, landet sicher auf Seite 2.

Der Zeitpunkt wann eine Seite gecrawlt wird, ist wichtig, wenn man mit immer wieder aktuellen Inhalten arbeitet. Deswegen ist die allgemeine Antwortzeit des Servers auch so wichtig, damit der Suchmaschinencrawler auch ja im Sekundentakt vorbeischaut.

Japs hat geschrieben:Oh'man die 300.000 sollten auch nur ein Beispiel sein - von mir aus auch nur 500!
Bei 1000 schon ausgelastet - dazu sag ich jetzt mal nix mehr

Was wirfst Du denn aus bei 1.000 gleichzeitigen HTTP-Prozessen? Wenn ich so oft die DB konnektieren würde, würde das kein Server aushalten.

Wie gesagt spreche ich von "gleichzeitig" also das was im Apache-Monitor ausgeworfen wird und nicht was man sich mit Besucherstatistiken "ausdenkt".

profo hat geschrieben:@marc, die Reihenfolge der einzelnen Sitemaps macht nur insofern einen Eindruck, als die ersten meiner Erfahrung nach auch zuerst gespidert werden. Mit zunehmender Dauer des Projekts ist das dann wieder egal.

Ein Tipp vielleicht noch: alte Sitemaps ändern sich in einem Forum häufig nicht. Achte dann darauf, dass sich auch die Binärdateien der alten Sitemaps nicht ändern (gleiche Dateigröße und Timestamps). Der Google-Crawler ist schlau und kann mit dem 304 gut umgehen. Du bekommst damit bei großen Sites die neuen Inhalte leichter gespidert.

Also erstmal wollte ich die Sitemaps in Kategorien unterteilen. D.h. Profile, Kats, Topics, etc.

Nur wenn ich z.B. 50.000 Topics in eine Sitemap packe, behaupte ich mal, wird sich jede Sitemap jeden Tag ändern, da immer mindestens ein Topic dabei ist wo sich lastmod ändert (neuer Beitrag, Beitrag bearbeitet, etc.).

Deswegen dachte ich schon an einer Sortierung nach letztem Änderungsdatum, statt nach ID, da bei sehr alten Themen tatsächlich wenig Fluktuation vorhanden ist.

Oh'man die 300.000 sollten auch nur ein Beispiel sein - von mir aus auch nur 500!
Bei 1000 schon ausgelastet - dazu sag ich jetzt mal nix mehr

Also ich erinnere mich, dass Du Dich beschwert hast in einem anderen Thread, dass es auf eine einfach Frage keine einfache Antwort gab.

Wenn das nun alles nur "Beispiele" waren, dann teste es mal aus in 1-2 Jahren, wenn Du mal mehr als 1000 Unterseiten hast. Datenbank, dynamische Content-Erstellung, dynamische Bilderanpassung und vieles mehr. Und dann jage mal einen Spider drüber der mit 100 Prozessen gleichzeitig fährt (simultan), nicht mit Millisekunden oder Sekunden Abstand.

Ich erinnere mich gut, dass der Server hier vom Forum auch down wahr bei einer gewissen Anzahl User die gleichzeitig online waren und so geht es dir dann auch.

Kannst aber natürlich einen dementsprechenden Server nutzen der das dann simultan verkraftet. Apache auf bohren, Datenbank auch usw. Dumm nur, dass der Server dann nur dazu da ist um den Spider zu bedienen und im normalen Betrieb nichts zu tun hat.

Synonym hat geschrieben:Kannst aber natürlich einen dementsprechenden Server nutzen der das dann simultan verkraftet. Apache auf bohren, Datenbank auch usw. Dumm nur, dass der Server dann nur dazu da ist um den Spider zu bedienen und im normalen Betrieb nichts zu tun hat.

Das meine ich mit wirtschaftlich

Also ich erinnere mich, dass Du Dich beschwert hast in einem anderen Thread, dass es auf eine einfach Frage keine einfache Antwort gab.

Was hat denn nun das Eine mit dem Anderen zu tun ?
Eventuell habe ich ja auch was falsch missverstanden, aber ich kann mir beim besten Willen nicht vorstellen, dass wenn man eine Sitenmap erstellt, wo das Projekt 300.000 Seiten hat, dass dies kein Server aushalten sollte :)

Aber nix für ungut :)
Gruß Dirk

mgutt hat geschrieben: Was wirfst Du denn aus bei 1.000 gleichzeitigen HTTP-Prozessen? Wenn ich so oft die DB konnektieren würde, würde das kein Server aushalten.

Wie gesagt spreche ich von "gleichzeitig" also das was im Apache-Monitor ausgeworfen wird und nicht was man sich mit Besucherstatistiken "ausdenkt".

Also für mich hört sich das nach nicht so viel an. Mit einer persistenten Verbindung dürfte das auch für einen kleinen Server machbar sein.

Aber ne andere Frage: ist es eigentlich möglich die sitemaps baumartig zu strukturieren mit mehr als zwei Ebenen? D.h. index-sitemap, die wieder nur index-sitemaps enthält usw.

ja, das müsste gehen

Creating an index of Sitemap index files
You can also have an index of Sitemap index files. A Sitemap index file can be a maximum of 10MB as well, so if you have a really large site, you may have to use this additional organization step to keep the file sizes to a manageable level. We have a size limitation for Sitemaps and Sitemap indexes so that when we download the files, we don't overwhelm your bandwidth.

https://sitemaps.blogspot.com/2005/08/u ... files.html

xAaron hat geschrieben:Also für mich hört sich das nach nicht so viel an. Mit einer persistenten Verbindung dürfte das auch für einen kleinen Server machbar sein.

Wenn die Zielseite die DB konnektiert, also eine PHP-Seite und kein starres HTML, ein Bild oder sowas ist, dann schafft das kein Server alleine.

Bau mal einen Chat in AJAX/PHP, der von mehr als 100 Leuten genutzt wird. Dafür brauchst Du schnell einen eigenen Server, wenn man das Script nicht intelligent aufbaut und mit Caches arbeitet.