Optimieren von Office SharePoint Server für WAN-Umgebungen

Inhalt dieses Artikels:

• Entwerfen von Topologien für das WAN

• Optimieren des Crawlvorgangs für Inhalte

• WAN-Beschleuniger und andere Tools von Drittanbietern

• Entwerfen von Seiten für schnelleres Herunterladen

• Optimieren der Zwischenspeicherung für WAN-Umgebungen

In diesem Artikel werden spezifische Methoden beschrieben, mit denen Sie die Leistung Ihrer Microsoft Office SharePoint Server 2007-Lösung in WAN-Umgebungen verbessern können.

Entwerfen von Topologien für das WAN

In einer Microsoft Office SharePoint Server 2007-Farm können Sie Serverrollen flexibel konfigurieren und im Hinblick auf bestimmte Leistungs- oder Verfügbarkeitsanforderungen optimieren. In einer WAN-Umgebung müssen mehrere technische Eigenschaften von Serverrollen berücksichtigt werden. Zusätzlich zum Planen der gesamten Leistungs- und Verfügbarkeitsanforderungen kann das Verständnis dieser Eigenschaften Ihnen dabei helfen, Ihre Serverfarmtopologie für WAN-Umgebungen zu optimieren.

Optimieren der Topologie für das Crawlen von Inhalten

Standardmäßig werden in Microsoft Office SharePoint Server 2007 alle Webserver verwendet, um Inhalte in der Serverfarm zu crawlen. Wenn die Serverfarm so konfiguriert ist, dass für das Crawlen alle Webserver verwendet werden, werden vom Indexserver Anforderungen an jeden Webserver in der Farm gesendet.

Das Crawlen von Inhalten in der Farm belastet die Webserver beträchtlich. Dadurch können beim Netzwerkverkehr Belastungsspitzen entstehen und die CPU und sowie der Arbeitsspeicher stark belastet werden. Das Crawlen von Inhalten in der Farm kann potenziell mehr Datenverkehr im Netzwerk verursachen als Benutzeranfragen. Dieser Netzwerkverkehr kann die Leistung aller Webserver in der Serverfarm beeinträchtigen, sodass Benutzeranforderungen nach Inhalten auf den SharePoint-Websites nicht mehr so schnell beantwortet werden.

In WAN-Umgebungen wird empfohlen, einen dedizierten Webserver für das Crawlen von Inhalten zu konfigurieren, insbesondere beim Crawlen einer Serverfarm mit mehr als 500 GB an Inhalten oder beim Crawlen von Inhalten über das WAN. Damit Benutzeranforderungen durch das Crawlen von Inhalten nicht beeinträchtigt werden, müssen Sie den dedizierten Webserver von der Netzwerkauslastungsausgleichs-Rotation ausnehmen. Dies ist besonders in globalen Umgebungen wichtig, in denen die Nebenzeiten einer regionalen Farm (zu denen am ehesten Crawlvorgänge geplant werden) mit den Hauptzeiten der zentralen Farm zusammenfallen.

Konfigurieren eines dedizierten Webservers für das Crawlen lokaler Inhalte

Für optimale Leistung beim Crawlen von Inhalten einer lokalen Farm sollten Sie den Indexserver als dedizierten Webserver für das Crawlen konfigurieren, sofern der Indexserver über ausreichend Speicherkapazität für beide Rollen verfügt.

In der folgenden Abbildung ist eine Webfarm dargestellt, die mit einem dedizierten Webserver für die Indizierung von Inhalten optimiert wurde.

Indem derselbe Server als Indexserver und dedizierter Webserver verwendet wird, entfällt beim Crawlen von Inhalten das Senden von Anforderungen vom Indexserver an einen anderen Server. Folglich verbessert sich die Crawlleistung, und der Datenverkehr im Netzwerk ist allgemein geringer. Wenn dies nicht möglich ist, können Sie einen anderen Server in Ihrer Serverfarm verwenden.

Sie können den Indexserver für die Verwendung des dedizierten Webservers konfigurieren. Wenden Sie dazu eine der folgenden Methoden an:

• Konfigurieren des Office SharePoint Server-Suchdienstes in der SharePoint-Zentraladministration

• Direktes Bearbeiten der Hostdatei

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Konfigurieren eines dedizierten Front-End-Webservers für Crawlvorgänge (Office SharePoint Server 2007).

• Konfigurieren eines dedizierten Front-End-Webservers zum Crawlen mithilfe der Benutzeroberfläche (Office SharePoint Server 2007)

• Konfigurieren eines dedizierten Front-End-Webservers für Crawlvorgänge durch Bearbeiten der Hostdatei (Office SharePoint Server 2007)

Konfigurieren eines dedizierten Webservers für das Crawlen von Remotefarmen

Konfigurieren Sie den Indexserver in der zentralen Farm so, dass beim Crawlen von Inhalten einer regionalen Farm ein dedizierter Webserver in der regionalen Farm verwendet wird, um optimale Leistungen zu erzielen.

In der folgenden Abbildung sind zwei regionale Farmen dargestellt, die jeweils mit einem dedizierten Webserver für die Indizierung von Inhalten optimiert wurden.

• In der regionalen Farm 1 übernimmt ein dedizierter Server die Webserverrolle. Sowohl die zentrale Farm als auch die regionale Farm 1 verwenden für das Crawlen von Inhalten diesen dedizierten Webserver.

• Die regionale Farm 2 ist ähnlich wie die zentrale Farm konfiguriert, wobei die Webserverrolle auf dem Indexserver bereitgestellt ist.

Beachten Sie, dass der Indexserver in der zentralen Farm zum Crawlen von Inhalten einer Remotefarm nicht die Webserverrolle in der zentralen Farm verwendet. Stattdessen kontaktiert der Indexserver direkt die Webserver in den Remotefarmen.

In der Darstellung in der vorherigen Abbildung wäre bei der Konfiguration der regionalen Farm 1 die Leistung besser, wenn in den regionalen Farmen Inhalte zum gleichen Zeitpunkt gecrawlt werden wie in der zentralen Farm:

• Die lokale Crawlleistung in der regionalen Farm 1 wird verbessert, da der dedizierte Webserver 1 sich auf einem separaten Server befindet. Daher beeinträchtigt die zentrale Farm die Leistung des Indexservers nicht.

• Die Crawlzeiten über das WAN werden verbessert. Das Crawlen benötigt weniger Zeit, da der dedizierte Webserver in der regionalen Farm schneller reagiert, als dies der Fall wäre, wenn er sich mit dem Indexserver auf einem gemeinsamen Server befinden würde.

• Der Crawlvorgang der zentralen Farm wird verbessert, da der Indexserver in der zentralen Farm mit einem dedizierten Webserver kommuniziert.

Wenn Sie die Topologiekonfiguration wie in der regionalen Farm 2 implementieren, können Sie die Leistung optimieren, indem Sie Crawlvorgänge in den beiden Farmen so planen, dass sie nicht gleichzeitig stattfinden.

Zum Verwenden eines dedizierten Webservers in einer Remotefarm für das Crawlen von Inhalten müssen Sie die Hostsdatei direkt bearbeiten. Achten Sie darauf, dass Sie die Hostsdatei in der Farm bearbeiten, von der die Inhalte gecrawlt werden, nicht die Hostsdatei in der Remotefarm.

In einer globalen Lösung, in der eine zentrale Farm Inhalte in regionalen Farmen crawlt, müssen Sie die Hostsdatei bearbeiten und einen Eintrag für jede Webanwendung in jeder regionalen Farm hinzufügen, die gecrawlt werden soll. Ein Eintrag in der Hostsdatei besteht aus der IP-Adresse des dedizierten Webservers gefolgt vom Namen der Webanwendung. Beispiele:

• 10.10.10.4 Teamwebsites

• 10.10.10.4 MeineWebsites

• 10.10.10.4 Marketing

• 10.10.10.4 Vertrieb

Weitere Informationen finden Sie unter Konfigurieren eines dedizierten Front-End-Webservers für Crawlvorgänge durch Bearbeiten der Hostdatei (Office SharePoint Server 2007).

Optimieren im Hinblick auf die Abfrageleistung

Bei der Implementierung von Microsoft Office SharePoint Server 2007 in einer WAN-Umgebung ist die Abfrageleistung für Benutzer ein wichtiger Aspekt. Wenn ein Benutzer eine Abfrage durchführt, wird die Abfrage an einen Webserver gesendet. Der Webserver kommuniziert mit dem Abfrageserver und erstellt eine Ergebnisliste. Anschließend kommuniziert er mit dem Computer mit Microsoft SQL Server, um die Ergebnisliste mit Zusammenfassungstexten, URLs und der Einschränkung aus Sicherheitsgründen zu vervollständigen.

Da die Kommunikation zwischen den Servern erforderlich ist, um Abfrageergebnisse zurückzugeben, können Sie die Topologie so konfigurieren, dass die Abfrageleistung optimiert wird. Durch kleine Optimierungen in der Serverfarm können Sie die subjektive Gesamtleistung zwischen Clientcomputern und Servern über das WAN deutlich erhöhen.

Die wichtigste Optimierung ist die Verwendung eines dedizierten Webservers für das Crawlen von Inhalten, wie im vorherigen Abschnitt beschrieben. Dadurch wird sichergestellt, dass Webserver für Benutzeranforderungen zur Verfügung stehen und nicht durch Indizierungsaufträge überlastet sind.

Als Nächstes stehen mehrere verschiedene Optionen für die Bereitstellung der Abfragerolle zur Verfügung, wobei jede eine andere Optimierungsart ermöglicht. Jede Option schafft ein anderes Gleichgewicht zwischen der optimalen Bearbeitung von Abfrageanforderungen und der Verringerung des Datenverkehrs im lokalen Netzwerk zwischen den Farmservern. In der folgenden Tabelle werden diese Konfigurationsoptionen zusammengefasst und die Vor- und Nachteile der einzelnen Optionen vorgestellt.

Konfiguration	Vor- und Nachteile
Bereitstellen der Abfragerolle auf allen Webservern	Sie können die Abfragerolle auf Webservern hosten, um die Roundtripkommunikation zwischen Servern in der Farm zu reduzieren. Dadurch wird die Abfrageleistung optimiert. Da jedoch zwei Serverrollen auf denselben Servern gehostet werden, kann bei starker Nutzung die Leistung der Webserver insgesamt beeinträchtigt werden. Daher müssen Sie sicherstellen, dass Sie genügend Webserver zur Verarbeitung der Benutzeranforderungen während der Hauptzeit bereitstellen. Durch diese Konfiguration wird zwar die Abfrageleistung für Benutzer optimiert, sie hat aber einen Nachteil auf dem Back-End der Farm. Vom Indexserver wird der Indexkatalog an jeden Abfrageserver in einer Farm weitergegeben. Wenn die Abfragerolle auf mehreren Webservern bereitgestellt wird, sind für diesen Vorgang während der Indexweitergabe mehr Serverressourcen erforderlich.
Bereitstellen von mindestens einem dedizierten Server für die Abfragerolle	Indem Sie mindestens einen dedizierten Server für die Abfragerolle bereitstellen, werden diese Server so optimiert, dass alle verfügbaren Ressourcen für eine effiziente Ausführung der Rolle genutzt werden. Bei dieser Konfiguration müssen für gewöhnlich weniger Abfrageserver implementiert werden. Diese Konfiguration erfordert allerdings eine größere Anzahl von Roundtrips zwischen Servern in der Farm, um die Abfrageanforderungen von Webservern zu verarbeiten und die Inhaltsindizes während der Indexweitergabe zu aktualisieren.
Bereitstellen der Abfrage- und der Indexrolle auf demselben Server	Sie können die Abfragerolle und die Indexrolle auf demselben Server bereitstellen. Dadurch wird die Farmkommunikation optimiert, da keine Indexweitergabe mehr notwendig ist. Allerdings wird durch diese Konfiguration die Anzahl von Servern, auf denen die Abfragerolle gehostet werden kann, auf einen einzigen Server begrenzt. Der Grund dafür ist, dass durch die Bereitstellung der Abfragerolle auf einem Indexserver der Indexserver die Fähigkeit verliert, Inhaltsindizes an andere Server in der Farm weiterzugeben.

Neben der Optimierung einer einzelnen Farm im Hinblick auf die Abfrageleistung steht auch eine Reihe von Optimierungsoptionen für Szenarien mit mehreren Farmen zur Verfügung:

• In einem Szenario, in dem Dienste von Farmen gemeinsam genutzt werden und eine übergeordnete Farm den Suchdienst für eine untergeordnete Farm bereitstellt, ermöglicht die Bereitstellung eines dedizierten Abfrageservers in der übergeordneten Farm dieser die Verarbeitung von Suchabfragen der untergeordneten Farmen, ohne dass dadurch die Leistung anderer Benutzeroptionen in der übergeordneten Farm beeinträchtigt wird. In einem Szenario, in dem Dienste von Farmen gemeinsam genutzt werden, kontaktiert der Webserver in der untergeordneten Farm den Abfrageserver und den Datenbankserver der übergeordneten Farm direkt, anstatt über den Webserver in der übergeordneten Farm zu kommunizieren. Beachten Sie, dass die gemeinsame Nutzung von Diensten zwischen Farmen, bei der eine übergeordnete Farm der untergeordneten Farm Dienste bereitstellt, über das WAN nicht unterstützt wird. Große Organisationen können jedoch einen zentralen Standort mit einer übergeordneten Farm bereitstellen, die Dienste bereitstellt, und einer untergeordneten Farm, die Websites und Inhalte bereitstellt. In diesem Szenario kann die übergeordnete Farm so konfiguriert werden, dass Inhalte in regionalen Farmen in einer geografisch verteilten Umgebung mit mehreren Farmen gecrawlt werden, ohne dass die Leistung der untergeordneten Farm am zentralen Standort, von der Benutzern am zentralen Standort Websites und Inhalte bereitgestellt werden, beeinträchtigt wird.

• In einer geografisch verteilten Umgebung mit mehreren Farmen, in der eine zentrale Farm Inhalte in regionalen Farmen crawlt, können Sie sowohl das Crawlen von Inhalten als auch die Abfrageleistung optimieren, indem Sie die Server folgendermaßen konfigurieren:

  • Stellen Sie die Webserverrolle in allen Farmen auf dem Indexserver bereit. Entfernen Sie diesen Server aus der Netzwerkauslastungsausgleichs-Rotation, und konfigurieren Sie den Crawlvorgang der übergeordneten Farm so, dass für das Crawlen von Inhalten dieser dedizierte Webserver verwendet wird.

  • Stellen Sie den Abfrageserver auf allen Webservern mit Lastenausgleich in den einzelnen Farmen bereit.

Geografische Trennung von Farmservern

Für die Kommunikation zwischen Servern in einer Serverfarm sind stabile Netzwerkverbindungen erforderlich, um Benutzeranforderungen angemessen zu verarbeiten und Leistungsengpässe zu vermeiden. Standardmäßig müssen sich alle Server in einer Serverfarm im selben Rechenzentrum im selben lokalen Netzwerk (Local Area Network, LAN) befinden. Die Trennung von Farmservern über WAN-Verbindungen wird nicht unterstützt.

Zusätzlich zu dieser Vorgabe gibt es spezifische Anforderungen, die es ermöglichen, dass sich ein oder mehrere Webserver an einem anderen geografischen Standort als die übrigen Farmserver befinden. In diesem Szenario befinden sich die Webserver in einem anderen Rechenzentrum, sind jedoch mit demselben LAN wie der Computer mit SQL Server verbunden.

Dieses Bereitstellungsszenario sollte die vorläufigen Unterstützbarkeitsanforderungen erfüllen, sofern die folgenden Bedingungen gegeben sind:

• Die Netzwerkverbindung zwischen einem Webserver und dem Datenbankserver hat eine Wartezeit von weniger als 1 Millisekunde (ms). Um diese Wartezeit zu erreichen, sollte der Webserver nicht mehr als 16 Kilometer vom Datenbankserver entfernt sein. Bei einer idealen Netzwerkkonfiguration kann in seltenen Fällen eine Wartezeit von weniger als 1 ms bei Entfernungen von bis zu 160 Kilometern erreicht werden. Bei Entfernungen zwischen 16 und 160 Kilometern sollten Sie sich bei Ihren Netzwerk- und Hardwareanbietern erkundigen, ob ein Servicelevel mit einer Wartezeit von weniger als 1 ms möglich ist. Das Trennen von Farmservern über Entfernungen von mehr als 160 Kilometern wird nicht unterstützt. Beim Messen der Wartezeit zwischen zwei Rechenzentren, die als Hosts für Server derselben Farm fungieren, verwenden Sie das Tool "Ping", um die Wartezeit von einem Webserver im Remoterechenzentrum zum Datenbankserver im primären Rechenzentrum zu messen. Dividieren Sie das Roundtripergebnis durch zwei.

• Die Verbindung verfügt über ausreichend verfügbare Bandbreite, um den Datenverkehr zwischen dem Webserver und den anderen Servern in der Farm zu bewältigen.

• Alle Serverrollen, die zu gemeinsamen Diensten beitragen, befinden sich im selben Rechenzentrum wie der Datenbankserver. Dazu gehören die Index-, Abfrage- und Excel Services-Rollen.

• Alle Servercomputer in der Farm befinden sich im gleichen Netzwerksegment. Auf Datenebene findet kein Switchen durch die Router statt. (Die Bitübertragungsschicht bildet die Verbindung zwischen den Servern.) Router und Switches erhöhen die Wartezeit auch bei extrem schnellen Verbindungen.

• Wenn der Lastentyp, der vom Webserver bedient wird, eine Teilmenge von Benutzersuchanforderungen ist, sollte von Microsoft Office SharePoint Server 2007 eine gewisse Wartezeit zwischen dem Webserver und dem Datenbankserver toleriert werden. Andererseits können bei Seiten mit zahlreichen oder benutzerdefinierten Webparts, bei Stsadm-Befehlen und Suchcrawls Probleme auftreten.

• Server innerhalb der Serverfarm dürfen keine Zeitzonen überschreiten. Alle Servercomputer innerhalb einer Serverfarm müssen mit derselben Zeitzone synchronisiert werden.

Optimieren des Crawlvorgangs für Inhalte

Die Art, wie Sie Crawlvorgänge planen und konfigurieren, kann Einfluss auf die Leistung und die Zuverlässigkeit haben. Die folgenden Prozesse können optimiert werden, um das Crawlen über das WAN zu verbessern:

• Koordinieren des Crawlens von Inhaltsquellen

• Konfigurieren der Crawlhäufigkeit und Koordinieren vollständiger und inkrementeller Crawls

• Konfigurieren der Crawleinstellungen

Koordinieren des Crawlens von Inhaltsquellen

In globalen Umgebungen, in denen eine zentrale Farm Inhalte in regionalen Farmen über WAN-Verbindungen crawlt, müssen Inhaltsquellen geplant werden, da sie die Inhaltseinheiten darstellen, die geplant und verwaltet werden können.

Fügen Sie eine Inhaltsquelle für die Suche hinzu, wenn die folgenden Vorgaben erfüllt werden müssen:

• Crawlen verschiedener Repositorytypen

• Crawlen von Repositorys mit abweichenden Zeitplänen

• Einschränken oder Erhöhen der Menge der gecrawlten Inhalte

Alle diese Faktoren können bei der Optimierung des Crawlens von Inhalten über das WAN berücksichtigt werden. Erstellen Sie mindestens eine andere Inhaltsquelle für jede regionale Farm. Dadurch können Sie das Crawlen jeder regionalen Farm unter Berücksichtigung der Nebenzeiten und des Wartungszeitplans der lokalen Farm planen.

Darüber hinaus sollten Sie auf Grundlage der folgenden Kriterien verschiedene Inhaltsquellen für eine einzelne regionale Farm erstellen:

• Erstellen Sie separate Inhaltsquellen für Inhalte, die häufiger (z. B. gemeinsame Inhalte) oder weniger häufig gecrawlt werden (z. B. veröffentlichte Inhalte).

• Erstellen sie eine separate Inhaltsquelle für Inhalte, die regelmäßig veröffentlicht werden. Wenn Sie beispielsweise wissen, dass Inhalte auf bestimmten Websites nur freitags aktualisiert werden, können Sie eine separate Inhaltsquelle erstellen, um die Crawlzeitpläne mit den Inhaltsaktualisierungen zu synchronisieren.

• Erstellen Sie Inhaltsquellen basierend auf der Inhaltsmenge, die während der Nebenzeit einer regionalen Farm über eine WAN-Verbindung gecrawlt werden kann. Wenn beispielsweise ein umfangreiches Repository einmal pro Woche gecrawlt werden soll, können Sie das Repository in fünf bis sieben Inhaltsabschnitte aufteilen, die über Nacht gecrawlt werden können, und dann im Verlauf der Woche die einzelnen Crawlaufträge zeitlich verteilt planen.

• Erstellen Sie eine separate Inhaltsquelle für Inhalte, die sich nicht auf Microsoft Office SharePoint Server 2007-Websites befinden. In Microsoft Office SharePoint Server 2007 und Windows SharePoint Services 3.0 werden im Änderungsprotokoll geänderte Objekte aufgezeichnet, einschließlich Aktualisierungen von Zugriffssteuerungslisten (Access Control List, ACL). Das Änderungsprotokoll bietet die Möglichkeit, nur geänderte Inhalte inkrementell zu crawlen. Dadurch wird der Zeitaufwand für das erneute Crawlen der Inhaltsquelle erheblich reduziert. Inhalte, die in externen Quellen gespeichert sind, können nicht inkrementell gecrawlt werden. Folglich sollte der Crawlvorgang für diese Inhaltsquellen separat verwaltet werden. Weitere Informationen finden Sie unter Änderungsprotokoll (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=106007&clcid=0x407) (in englischer Sprache).

Weitere Informationen zur Planung von Crawlvorgängen und Inhaltsquellen finden Sie unter Planen des Crawlens von Inhalten (Office SharePoint Server).

Konfigurieren der Crawlhäufigkeit und Koordinieren vollständiger und inkrementeller Crawls

Wie im vorherigen Abschnitt erläutert, besteht der Hauptgrund für die Erstellung separater Inhaltsquellen darin, Inhalte nach verschiedenen Zeitplänen zu crawlen. Dies ist besonders in Umgebungen von Bedeutung, in denen Inhalte über WAN-Verbindungen mit hohen Wartezeiten gecrawlt werden. Berücksichtigen Sie beim Planen von Crawlaufträgen für regionale Farmen die folgenden Faktoren:

• Geplante Ausfallzeiten und Spitzenauslastungszeiten in der regionalen Farm

• Die Häufigkeit, mit der Inhalte geändert oder aktualisiert werden

• Die verfügbare Bandbreite und Wartezeit der WAN-Verbindung. Berücksichtigen Sie auch andere Prozesse, die die WAN-Verbindung verwenden.

Für jede Inhaltsquelle in Microsoft Office SharePoint Server 2007 und Windows SharePoint Services 3.0 können Sie die Zeit für vollständige Crawls und inkrementelle Crawls separat angeben. Beachten Sie, dass Sie einen vollständigen Crawl für eine bestimmte Inhaltsquelle durchführen müssen, bevor inkrementelle Crawls möglich sind. Wenn Sie für noch nicht gecrawlte Inhalte einen inkrementellen Crawl auswählen, wird vom System ein vollständiger Crawl durchgeführt.

Beachten Sie beim Planen der Crawlzeitpläne für eine WAN-Umgebung die folgenden bewährten Methoden:

• Legen Sie die Crawlzeitpläne zeitversetzt an, sodass die Verwendung der WAN-Verbindungen zeitlich verteilt wird und die WAN-Verbindungen nicht überlastet werden.

• Führen Sie vollständige Crawls nur aus, wenn dies notwendig ist. Vollständige Crawls sollten seltener durchgeführt werden als inkrementelle Crawls.

• Planen Sie inkrementelle Crawls für die einzelnen Inhaltsquellen zu Zeiten, in denen die Server, die die Inhalte hosten, verfügbar sind und die Serverressourcen nur wenig beansprucht werden.

• Einige administrative Änderungen in Microsoft Office SharePoint Server 2007 und Windows SharePoint Services 3.0, z. B. die Anwendung eines Service Packs oder das Wiederherstellen einer Datenbank, lösen automatisch einen vollständigen Crawl beim nächsten regelmäßig geplanten Crawl aus. Planen Sie administrative Änderungen, die einen vollständigen Crawl erfordern, unmittelbar vor einem geplanten vollständigen Crawl. Beispielsweise wird empfohlen, Crawlregeln unmittelbar vor dem nächsten vollständigen Crawl zu erstellen, sodass kein zusätzlicher vollständiger Crawl notwendig ist. Weitere Informationen zu administrativen Änderungen, die einen vollständigen Crawl erforderlich machen, finden Sie unter "Gründe für einen vollständigen Crawl" in Planen des Crawlens von Inhalten (Office SharePoint Server).

Zusätzlich zu diesen bewährten Methoden für das Crawlen von Inhalten an verschiedenen regionalen Standorten müssen Sie darauf achten, dass der Crawlzeitplan einer zentralen Farm insgesamt den Indexserver nicht überlastet. Berücksichtigen Sie bei der Planung gleichzeitiger Crawlvorgänge die Kapazität des betreffenden Indexservers. Die Leistung des Indexservers und der Server, von denen die Inhalte gehostet werden, bestimmt, in welchem Umfang Crawlvorgänge zeitlich überlappen dürfen. Sie können nach und nach eine Strategie für Crawlzeitpläne entwickeln, wenn Sie mit dem typischen Zeitaufwand für das Crawlen der einzelnen Inhaltsquellen vertraut sind.

Weitere Informationen zur Planung von Crawlvorgängen und Inhaltsquellen finden Sie unter Planen des Crawlens von Inhalten (Office SharePoint Server).

Konfigurieren der Crawleinstellungen

Sie können mehrere spezifische Crawleinstellungen für WAN-Umgebungen optimieren, um die Zuverlässigkeit der Crawlaufträge zu erhöhen. Die folgenden Einstellungen sind verfügbar:

• Timeouteinstellungen für die Suche

• Regeln für Crawlerauswirkungen

Timeouteinstellungen für die Suche

Farmadministratoren können angeben, wie lange der Server warten soll, bis eine Verbindung mit anderen Diensten hergestellt und bis eine Inhaltsanforderung bestätigt wird. Wenn Sie Inhaltsquellen hinzufügen, die über WAN-Verbindungen gecrawlt werden, sollten Sie die Timeouteinstellungen basierend auf der gesamten Wartezeit der Verbindung vorbeugend erhöhen. Sie können die Timeouteinstellungen jederzeit entsprechend der tatsächlichen Leistung beim Crawlen von Inhalten über eine WAN-Verbindung anpassen.

Verwenden Sie das folgende Verfahren, um die Timeouteinstellungen für den Office SharePoint Server-Suchdienst anzugeben.

Angeben von Timeouteinstellungen

1. Klicken Sie in der Zentraladministration auf der Registerkarte Anwendungsverwaltung im Abschnitt Suchen auf Suchdienst verwalten.

2. Klicken Sie auf der Seite Suchdienst verwalten im Abschnitt Sucheinstellungen auf Farmebene auf Sucheinstellungen auf Farmebene.

3. Führen Sie auf der Seite Sucheinstellungen auf Farmebene verwalten im Abschnitt Timeouteinstellungen die folgenden Schritte aus:

   • Geben Sie im Feld Verbindungszeit (in Sekunden) die Anzahl der Sekunden ein, die der Server warten soll, bis eine Verbindung mit anderen Diensten hergestellt wird.

   • Geben Sie im Feld Anforderungsbestätigungszeit (in Sekunden) die Anzahl der Sekunden ein, die der Server warten soll, bis eine Anforderung zum Herstellen einer Verbindung mit einem anderen Dienst von diesem bestätigt wird.

4. Klicken Sie auf OK.

Regeln für Crawlerauswirkungen

Regeln für Crawlerauswirkungen bieten eine Möglichkeit, die Anzahl der Dokumente zu steuern, die gleichzeitig angefordert und gecrawlt werden. Mithilfe von Regeln für Crawlerauswirkungen können Administratoren die Auswirkungen von Crawlaufträgen auf WAN-Verbindungen verwalten.

Für jede Regel für Crawlerauswirkungen können Sie eine einzelne URL angeben oder mithilfe von Platzhalterzeichen im URL-Pfad einen Block von URLs einfügen, auf die die Regel angewendet wird. Anschließend können Sie angeben, wie viele gleichzeitige Seitenanforderungen an diese bestimmte URL erfolgen. Sie können auch angeben, dass immer nur ein einzelnes Dokument angefordert und zwischen den Anforderungen eine von Ihnen angegebene Anzahl von Sekunden gewartet wird.

Legen Sie bei der ersten Bereitstellung die Regeln für Crawlerauswirkungen so fest, dass WAN-Verbindungen so effizient wie möglich genutzt und dennoch genügend Inhalte gecrawlt werden, sodass die Aktualität der gecrawlten Inhalte sichergestellt ist. Sie können die Regeln für Crawlerauswirkungen später, während der Betriebsphase, basierend auf Ihren Erfahrungen und den Crawlprotokollen anpassen.

Verwenden Sie das folgende Verfahren, um eine Regel für Crawlerauswirkungen hinzuzufügen.

Hinzufügen einer Crawlerauswirkungsregel

1. Klicken Sie in der Zentraladministration auf der Registerkarte Anwendungsverwaltung im Abschnitt Suchen auf Suchdienst verwalten.

2. Klicken Sie auf der Seite Suchdienst verwalten im Abschnitt Sucheinstellungen auf Farmebene auf Regeln für Crawlerauswirkungen.

3. Klicken Sie auf der Seite Regeln für Crawlerauswirkungen auf Regel hinzufügen.

4. Geben Sie auf der Seite Crawlerauswirkungsregel hinzufügen im Abschnitt Website im gleichnamigen Feld den Namen der Website ein, die dieser Crawlerauswirkungsregel zugeordnet werden soll.

   Hinweis

   Geben Sie die URL ohne das Protokoll ein. Geben Sie beispielsweise http:// oder file:// nicht ein.

5. Wählen Sie im Abschnitt Abfragehäufigkeit eine der folgenden Optionen aus:

   • Bis zur angegebenen Anzahl von Dokumenten gleichzeitig anfordern und nach den Anforderungen nicht warten. Wenn Sie diese Option auswählen, verwenden Sie die Liste Gleichzeitige Anforderungen, um anzugeben, wie viele Dokumente auf einmal der Crawler beim Crawlen dieser URL anfordern soll. Sie können die maximale Anzahl von Anforderungen angeben, die der Office SharePoint Services-Suchdienst beim Crawlen der URL auf einmal ausführen kann.

   • Jeweils nur ein Dokument anfordern und nach jeder Anforderung eine bestimmte Zeit warten. Sie können zwischen den Anforderungen beim Crawlen dieser URL eine Verzögerung (in Sekunden) angeben. Wenn diese Option ausgewählt ist, sendet der Office SharePoint Server-Suchdienst eine Anforderung pro Website und wartet dann die angegebene Zeitspanne, bevor die nächste Anforderung erfolgt. Geben Sie im Feld Wartezeit (in Sekunden) die Wartezeit in Sekunden zwischen den Anforderungen ein. Die minimale Wartezeit zwischen Anforderungen beträgt eine Sekunde, die maximale Wartezeit 1.000 Sekunden.

6. Klicken Sie auf OK.

Weitere Informationen zu Crawlerauswirkungsregeln finden Sie in den folgenden Artikeln:

• Verwalten von Crawlerauswirkungen (Office SharePoint Server 2007).

• "Crawlerauswirkungsregeln" in Einschätzen von Leistungs- und Kapazitätsanforderungen bei Suchumgebungen.

WAN-Beschleuniger und andere Tools von Drittanbietern

In diesem Abschnitt werden Optionen zur Optimierung von WAN-Umgebungen mit Lösungen von Drittanbietern in den folgenden Kategorien beschrieben:

• WAN-Beschleuniger

• Ablade- und Zwischenspeichergeräte

• Clientlösungen

• Datenreplikation, Multimastersynchronisierung und Konfigurationsverwaltung

• Verwaltbarkeit und Berichterstattung bei mehreren Farmen

• Replikation auf Byteebene oder hardwarebasierte Replikation

Da alle Umgebungen unterschiedlich sind, wird keine bestimmte Partnerlösung empfohlen. Darüber hinaus werden in Partnerlösungen Möglichkeiten anders genutzt. Daher hat jede Lösung andere Stärken. Es ist wichtig, jede Lösung im Hinblick auf die speziellen Anforderungen Ihrer Umgebung und die relativen Stärken der Partnerlösung zu bewerten.

Es gibt viele Partner, die Lösungen anbieten, mit denen Microsoft Office SharePoint Server 2007-Lösungen erweitert oder optimiert werden können. Eine aktuelle Liste mit Partnern finden Sie unter Office System-Lösungen (https://go.microsoft.com/fwlink/?linkid=108591&clcid=0x407).

WAN-Beschleuniger

WAN-Beschleunigungslösungen gibt es schon lange. Algorithmen mit kurzen Pfaden und Tools für die Paketkomprimierung werden seit Jahrzehnten angeboten. Die größten Innovationen in den letzten Jahren zielen auf die Optimierung des TCP/IP-Stapels und des Server Message Blocks (SMB) ab.

Die meisten WAN-Beschleuniger arbeiten paarweise. Ein Gerät wird im Rechenzentrum neben den Servern mit SharePoint-Produkten und -Technologien installiert, ein anderes Gerät in der Zweigstelle. Die beiden Geräte optimieren den WAN-Datenverkehr mithilfe von Zwischenspeicherung, Komprimierung, Differenzierung und proprietären Methoden zum Optimieren der Pakete, die zwischen den beiden Paketen gesendet werden. Unabhängig davon, ob es sich um Inlinegeräte oder einfache Netzwerkgeräte mit Aktualisierungen für Zwischenspeicher handelt, ist das Konzept vergleichbar. Die verschiedenen Partnerlösungen haben ihren Schwerpunkt auf der Optimierung verschiedener Ebenen innerhalb des Netzwerkstapels.

Bei der Auswahl eines Netzwerkbeschleunigers sollten Sie die beiden folgenden Punkte berücksichtigen:

• Die Sicherheitsanforderungen Ihrer Organisation. Anforderungen wie IPsec oder HTTPS haben einen Einfluss auf die Optionen.

• Die Anwendungen, die in Ihrer Organisation verwendet werden. Wenn Sie ein Gerät möchten, dass auch Optimierungen für Microsoft Exchange Server und den Datenverkehr auf Dateifreigaben bietet, beeinflusst dies Ihre Optionen ebenfalls.

Beispiellösungen: Cisco, Citrix, Packeteer, Riverbed und F5.

Ablade- und Zwischenspeichergeräte

Während Zwischenspeicherungstechniken in SharePoint unnötigen Back-End-Datenverkehr verringern können, können Ihnen Partner, die Ablade- und Zwischenspeichergeräte bieten, dabei helfen, die Lücke zwischen den Clients und Servern zu schließen, auch im Bezug auf WAN-Verbindungen.

Wenn Sie Ihre SharePoint-Website über das Internet hosten und den Netzwerkverkehr sowie die Anzahl der Anforderungen optimieren möchten, die bei Ihren Servern eingehen, sollten Sie Ablade- und Zwischenspeichergeräte in Betracht ziehen. Es gibt eine Vielzahl von Partnern, die Lösungen anbieten, um das Hosten von Inhalten für das Internet zu optimieren. Hierbei werden Strategien wie das Zwischenspeichern und ähnliche proprietäre Techniken, die Abladekomprimierung mit verschiedenen Algorithmen, Aufwärmen und Vorabruf sowie verschiedene Einkaufswagentechniken eingesetzt. Einige Partner bieten hervorragende Lösungen für die sichere und effektive Bereitstellung von Inhalten für bestimmte Clients an, z. B. öffentliche Kioske, Computer in Internetcafes weltweit und andere schlanke Geräte ohne leistungsfähige Verbindung.

Auch im Internetbereich gibt es Partner, die Techniken für globale Zwischenspeicherung und optimiertes Netzwerkrouting bieten, durch die verworfene Pakete reduziert werden können. Einige Lösungen optimieren beispielsweise den Netzwerkverkehr, sodass nur die Deltas innerhalb der Clientanforderungen an den Server gesendet werden. Derartige Lösungen reduzieren den WAN-Datenverkehr und beschleunigen den Seitenabruf, wobei die Menge der Roundtrips zwischen dem Client und dem Server oder zwischen anderen Zwischengeräten reduziert wird.

Ähnlich wie Microsoft ISA bieten einige Lösungen abgeladene oder delegierte Authentifizierung als Gateway für den Zugriff auf Informationen. Diese Lösungen fügen eine zusätzliche Sicherheitsebene hinzu. Suchen Sie nach Produkten oder Lösungen, die eine Firewall, Lastenausgleich sowie Intelligenz für das Abladen und Zwischenspeichern bieten, um mehreren Anforderungen gerecht zu werden. Sie können davon ausgehen, dass derartige Features in Zukunft noch stärker konsolidiert werden.

Beispiellösungen: Cisco, F5, Inktomi, Microsoft ISA Server und Microsoft Internet Application Gateway.

Clientlösungen

Einige Partner konzentrieren sich auf die Optimierung der Clienterfahrung statt auf die Netzwerk- und Serverinfrastruktur. Techniken wie Vorabruf, Synchronisierung im Hintergrund, Komprimierung, Anzeigenblocker und Grafikfilter können die Leistung beim Abrufen von Inhalten im Internet beträchtlich verbessern. Dies ist insbesondere dann der Fall, wenn der Text im Vordergrund steht und keine Grafiken benötigt werden.

Es gibt verschiedene Clientanwendungen, die eine automatische Synchronisierung mit SharePoint-Websites ermöglichen. Nach der ersten Synchronisierung des Clients mit der Website werden die Inhalte der Website automatisch auf dem Clientcomputer gespeichert, im Hintergrund oder während der Client online ist. Wenn ein Benutzer beispielsweise auf ein Dokument klickt, ist das Dokument bereits lokal verfügbar, und der Benutzer ist nicht auf WAN-Verbindungen angewiesen. Ähnlich verhält es sich, wenn ein Benutzer ein Dokument hinzufügt oder aktualisiert: Die Clientanwendung synchronisiert die Änderungen mit der Onlinewebsite. Von diesen Clientanwendungen werden für gewöhnlich alle auftretenden Konflikte verwaltet, und Benutzer können entscheiden, wie Konflikte gelöst werden sollen.

Einige Clients bewältigen diese Aufgabe besser als andere. Manche bieten nur Unterstützung für Dateien. Einige Anwendungen unterstützen sowohl Listen als auch Dateien. Es gibt kaum Offline-Wiki-Websites, aber Sie können RSS-Reader einsetzen, um die meisten Listen lokal oder offline zu verwenden. Office Outlook 2007 ist beispielsweise ein Client, mit dem Sie SharePoint-Blogs oder -Listen offline verwenden können, indem Sie RSS mit einem RSS-Reader verwenden. Außerdem können Sie eine Synchronisierung mit Dokumentbibliotheken durchführen. Office Groove 2007 ermöglicht ebenfalls ein gutes Offlineerlebnis und bietet Funktionen für Peer-zu-Peer-Zusammenarbeit und Dateikomprimierung im WAN. Weitere Informationen zu Microsoft-Clientlösungen finden Sie unter Erweitern von globalen Office SharePoint Server-Lösungen mit Office Outlook 2007 und Office Groove.

Partner in diesem Bereich konzentrieren sich auf die Optimierung der Benutzererfahrung in Fällen, in denen WAN-Verbindungen die Leistung beeinträchtigen oder Clients häufig offline sind. Durch Zwischenspeicherung (lokale Kopien), Komprimierung und die Synchronisierung im Hintergrund kann ein Arbeitserlebnis wie über ein LAN geschaffen werden. Wenn Sie Benutzern Clientanwendungen anbieten möchten, müssen Sie angemessene Schulungen bereitstellen, damit die Benutzer möglichst effizient arbeiten können.

Partner: Colligo. Microsoft: Microsoft Office Outlook 2007, Office Groove 2007

Datenreplikation, Multimastersynchronisierung und Konfigurationsverwaltung

In Bereitstellungsplänen ist Replikation oftmals unverzichtbar, sei es aufgrund langsamer WAN-Verbindungen zwischen zwei Niederlassungen oder infolge von Notfallwiederherstellungsanforderungen mit einer Multimasteranforderung. SQL Server 2005 bietet Protokollversand und Datenbankspiegelung für Notfallwiederherstellung oder Standortfailover. Wenn jedoch zwei getrennte Serverfarmen erforderlich sind, die beide Lese-/Schreibzugriff bieten, sind entsprechende Lösungen von Partnern verfügbar.

Einige Partnerlösungen umfassen einen Servercache, der mit einem WAN-Beschleuniger vergleichbar ist. Die Lösungen stellen beim Ausfall einer WAN-Verbindung an einem Remotestandort weiterhin Inhalte aus dem Zwischenspeicher bereit. Andere Partner bieten hervorragende Lösungen für das Synchronisieren von Daten, wenn Standorte nach längerer Zeit wieder miteinander verbunden werden. Beispielsweise kann ein Schiff, das nach längerer Zeit auf See wieder im Hafen einläuft, wieder mit einem zentralen Standort synchronisiert werden.

Einige Partner erweitern die Schnittstelle der SharePoint-Produkte und -Technologien, um die Replikation für Paare von Webanwendungen, Websitesammlungen oder Listen zu konfigurieren.

Partnerlösungen: Syntergy, WinApp-Technologien, Casahl und Infonic.

Verwaltbarkeit und Berichterstattung bei mehreren Farmen

In globalen Bereitstellungen mit mehreren Serverfarmen kann das Verwalten von Einstellungen für alle Farmen und Websites schwierig sein. Mehrere Partner bieten Tools für die optimierte Verwaltung von Konfigurationseinstellungen, die Verwaltung von Berechtigungen, effektive Benutzerrechte und Inhaltselemente wie Masterseiten und Inhaltstypen an. Wenn Sie mehrere Serverfarmen in Ihrer Umgebung bereitstellen möchten, sollten Sie ggf. Partnertools einsetzen, die die Verwaltung mehrerer Serverfarmen und umfangreicher Websites erleichtern.

Einige Partner konzentrieren sich auf die einfachere Konfiguration von Einstellungen in mehreren Farmen und Umgebungen. Das Tool SharePoint Cross Site Configurator (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=108592&clcid=0x407) wurde beispielsweise von Microsoft entwickelt, um die Überwachung, den Ablauf, Masterseiten und Inhaltstypen einheitlich für alle Webanwendungen zu konfigurieren.

Partnerlösungen: Quest Software, echoTechnologies, IDevFactory, AvePoint, CorasWorks, Barracuda Tools, CommVault und Symantec.

Replikation auf Byteebene oder hardwarebasierte Replikation

Partner, die hardwarebasierte Replikation oder Replikation auf Byteebene bereitstellen, erleichtern das Failover und die Synchronisierung von Umgebungen zwischen Rechenzentren. Wenn Sie einen freigegebenen Datenträger wie ein SAN (Storage Area Network) implementieren, kann der freigegebene Datenträger zur Fehlerquelle werden. Hardwarehersteller setzen verschiedene Methoden ein, um redundante Kanäle, Fasern oder Datenträger sowie verschiedene Arraykonfigurationen bereitzustellen. Die Fehlertoleranz ist je nach Lösung unterschiedlich.

Wenn Sie Hardware als potenzielle Fehlerquelle ausschließen möchten, sollten Sie Microsoft Clusterdienste (Microsoft Cluster Services, MSCS) evaluieren. MSCS bietet hardwarebasierte Fehlertoleranz. Softwarebasierte Failoverlösungen wie SQL-Protokollversand und SQL-Spiegelung bieten Hardwarefehlertoleranz, in Verbindung mit SharePoint-Produkten und -Technologien aber kein automatisches Failover.

In einigen Fällen können durch die Implementierung einer Lösung zur Replikation auf einer niedrigeren Ebene im Stapel bestimmte Geschäftsanforderungen umgesetzt werden. Durch Replikation auf Byteebene, bei der ein Klon oder eine Spiegelung der primären Umgebung erstellt wird, kann auch eine sekundäre Umgebung für das Failover geschaffen werden. Fortlaufende Replikation auf Byteebene kann eine Möglichkeit zum automatischen oder manuellen Failover bieten.

Ein wichtiger Hinweis zur Bewertung solcher Replikationslösungen: Die Servernamen, Webanwendungsnamen und Konten sind in der Konfigurationsdatenbank hartcodiert. Das bedeutet, dass Dienste, die auf einem anderen Server mit einem anderen Namen repliziert werden, nicht mehr funktionsfähig sind. Wenn der Servername in der replizierten Umgebung und in der primären Umgebung identisch bleibt, können derartige Lösungen funktionieren. Unabhängig von der Lösung muss jedes Tool, das Replikation unabhängig von der Anwendung bietet, getestet werden, um sicherzustellen, dass es in einer Failoverumgebung funktionsfähig ist.

Partnerlösungen: Neverfail und Double-take.

Beispiele für in die Hardware integrierte Lösungen (z. B. SAN-basierte Replikation): HP, EMC Centera und Hitachi Data Systems.

Entwerfen von Seiten für schnelleres Herunterladen

In einer Umgebung mit begrenzter Netzwerkkapazität sollten Sie Seiten optimieren und sie so klein und reaktionsschnell wie möglich gestalten. Hierfür sind unterschiedliche Techniken verfügbar, von denen die meisten nicht für SharePoint-Produkte und -Technologien spezifisch sind. Die allgemeinen Methoden können für jede beliebige Website verwendet werden und werden in diesem Abschnitt nicht ausführlich behandelt. Stattdessen werden in diesem Abschnitt schwerpunktmäßig die in SharePoint-Produkten und -Technologien enthaltenen Features, die Seitenelemente sowie Möglichkeiten zum Beschleunigen des ersten Besuchs einer SharePoint-Website beschrieben.

Seitenelemente

Eine Seite auf einer SharePoint-Website besteht aus mehreren eindeutigen Elementen, wie in der folgenden Abbildung dargestellt.

Beim Rendern der Seite werden die Masterseite, die Layoutseite und die Inhalte für die Seite zusammengeführt. Der Seiteninhalt enthält die Werte für jedes der Seitenfelder, aber auch eine Reihe von anderen Elementen wie das Design, Stylesheets, Bilder und Navigationselemente. In der folgenden Tabelle sind Beispiele der Dateien und Datenströme aufgeführt, die auf einer einzelnen Seite einer SharePoint-Website vorhanden sind. Bei diesem Beispiel handelt es sich um eine Sammlung aller HTTP-Anforderungen, die beim ersten Besuch der Standardstartseite eine Portalwebsite für die Zusammenarbeit generiert wurden.

URL	Größe (Bytes)
http://MeinServer/_layouts/images/topnavhover.gif	96
http://MeinServer/Pages/Default.aspx	1656
http://MeinServer/Pages/Default.aspx	1539
http://MeinServer/Pages/Default.aspx	66084
http://MeinServer/_layouts/1031/Styles/Controls.css?Rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D	1448
http://MeinServer/_layouts/1031/Styles/HtmlEditorCustomStyles.css?Rev=8SKxtNx33FmoDhbbfB27UA%3D%3D	642
http://MeinServer/_layouts/1031/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D	1317
http://MeinServer/_layouts/1031/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D	13596
http://MeinServer/_layouts/1031/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D	15732
http://MeinServer/_layouts/1031/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D	54367
http://MeinServer/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D	954
http://MeinServer/_layouts/1031/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D	20508
http://MeinServer/_layouts/1031/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D	5092
http://MeinServer/_layouts/1031/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D	2735
http://MeinServer/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034	5383
http://MeinServer/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034	8258
http://MeinServer/_layouts/images/blank.gif	43
http://MeinServer/_layouts/images/helpicon.gif	1025
http://MeinServer/_layouts/images/Menu1.gif	68
http://MeinServer/_layouts/images/titlegraphic.gif	1299
http://MeinServer/_layouts/images/gosearch.gif	19933
http://MeinServer/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034	224
http://MeinServer/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034	218
http://MeinServer/_layouts/images/whitearrow.gif	68
http://MeinServer/_layouts/images/recycbin.gif	1004
http://MeinServer/PublishingImages/newsarticleimage.jpg	10710
http://MeinServer/_layouts/images/icongo01.gif	1.171
http://MeinServer/_layouts/images/menudark.gif	68
http://MeinServer/_layouts/images/topnavhover.gif	96

Beachten Sie Folgendes:

• Zum Herunterladen der Seite waren insgesamt 29 Anforderungen erforderlich.

• Die Seitengröße insgesamt betrug 235 Kilobytes (KB).

• Dies stellt das erste Laden einer Seite dar. Nahezu alle Elemente in der Anforderung besitzen eine Cachedirektive, die den Browser anweist, sie ein Jahr lang nicht erneut zu laden. Beim zweiten und nachfolgenden Laden der Seite werden nur drei Anforderungen erzeugt. Davon sind zwei Bestandteil der NTLM-Aushandlung, es wird also tatsächlich nur ein Element heruntergeladen – der HTML-Code für die Seite.

• Der standardmäßige IIS-Komprimierungsgrad 0 wurde verwendet, also die niedrigste mögliche Komprimierung. Durch zusätzliche Komprimierung würden noch kleinere Downloadgrößen erzielt werden.

• Die folgenden Dateitypen wurden geladen:

  • 4 AXD-Ressourcenanforderungen

  • 4 CSS-Ressourcenanforderungen

  • 12 Bildressourcenanforderungen

  • 6 JS-Ressourcenanforderungen (davon einige Duplikate)

  • 3 Seitenressourcenanforderungen für default.aspx (davon waren zwei Bestandteil der NTLM-Aushandlung)

Die meisten dieser Dateitypen sind bekannt, möglicherweise abgesehen vom AXD-Ressourcentyp. Eine AXD-Ressource ist Teil eines neuen Features in ASP.NET, Version 2.0. Ein Entwickler kann eine Ressource (z. B. eine Skriptdatei oder ein Stylesheet) einem Steuerelement hinzufügen. Im Steuerelement schließt der Entwickler mithilfe der ClientScript-Klasse eine Methode namens GetWebResourceUrl ein. Wenn das Steuerelement zur Laufzeit gerendert wird, wird dynamisch eine URL für die Ressource generiert. Die Ressource selbst wird in die Steuerelementassembly kompiliert. Diese Vorgehensweise bietet also eine Möglichkeit, die betreffende Ressource aus der Assembly herauszustreamen und zum Client zu senden, als wäre sie eine separate Datei auf dem Webserver.

Wenn Sie die von der Seite verwendeten Ressourcenanforderungen kennen, können Sie besser verstehen, wo und wie Optimierungen eingesetzt werden können. Sie können diese Informationen mit einer Reihe verschiedener Tools und Techniken messen. Für diesen Artikel wurde ein Freewaretool namens Fiddler (in englischer Sprache) verwendet. Fiddler kann auf einer Clientarbeitsstation ausgeführt werden und verfolgt alle HTTP-Anforderungen für eine Seite nach. Anschließend werden die Ergebnisse in einem Raster dargestellt (siehe folgende Abbildung).

Testen Sie Ihre Website während der Optimierung immer wieder mit Fiddler. Gehen Sie folgendermaßen vor, um sich einen genauen Überblick darüber zu verschaffen, welche Elemente angefordert und welche Elemente zwischengespeichert werden und welche Größe die einzelnen Elemente aufweisen:

1. Löschen Sie alle temporären Dateien des Browsers.

2. Starten Sie Fiddler.

3. Fordern Sie die Seite an.

   Hinweis

   Stellen Sie sicher, dass Sie die Seite anfordern, indem Sie auf einen Link klicken. Wenn Sie einfach auf die Schaltfläche Aktualisieren klicken, werden Elemente automatisch erneut angefordert, sodass Änderungen im Rahmen der Optimierung nicht präzise widergespiegelt werden.

Optimieren von Seitendownloads

Nachdem Sie sich ein Bild der Zusammensetzung der Seite gemacht haben, können Sie verschiedene Methoden zum Optimieren der Downloaderfahrung für diese Seite verwenden. Im Allgemeinen besteht das Ziel darin, die Anzahl der Roundtrips zwischen Client- und Servercomputern zu minimieren und die Menge der über das Netzwerk übertragenen Daten zu reduzieren. Die Anleitungen in diesem Artikel enthalten Empfehlungen, die umfassend auf eine Vielzahl von anderen Implementierungen von SharePoint-Produkten und -Technologien angewendet werden können.

Beachten Sie einen wichtigen Unterschied zwischen diesen Empfehlungen und anderen benutzerdefinierten Optimierungen, die Sie möglicherweise entwickeln. Seitenoptimierungstechniken werden in zwei Kategorien unterteilt: erste Seitenanforderung und nachfolgende Seitenanforderung. Optimierungen für die erste Seite werden bei der ersten Anforderung der Seite implementiert, wirken sich aber nicht unbedingt auf nachfolgende Seitenanforderungen aus. Optimierungen für nachfolgende Seitenanforderungen können das Benutzererlebnis unabhängig davon verbessern, ob es sich um die erste oder die fünfzigste Anforderung einer Seite handelt. Sie müssen das optimale Verhältnis von Funktionalitätseinbußen und Leistungszuwachs schaffen. Wenn die Leistungsverbesserung nur beim ersten Aufrufen einer Website erzielt wird, ist die Optimierung möglicherweise die Funktionalitätseinbußen nicht wert.

BLOB-Cache

Der BLOB-Cache (Binary Large Object) wird weiter unten in diesem Artikel ausführlicher erläutert. Kurz gesagt, kann er verwendet werden, um Cachedirektiven auf Elemente auf einer Seite anzuwenden, die in SharePoint-Produkten und -Technologien gespeichert werden. Wenn diese Cachedirektiven eingeschlossen werden, werden diese Elemente erst wieder vom Browser heruntergeladen, wenn das zwischengespeicherte Element abgelaufen ist. Wie im vorherigen Beispiel mit der Startseite veranschaulicht wurde, waren fast alle Elemente auf der Standardstartseite der Websitevorlage Zusammenarbeitsportal mit einer Cachedirektive verknüpft, weshalb sie bei nachfolgenden Seitenzugriffen nicht angefordert wurden. Weitere Einzelheiten zum Einrichten und Konfigurieren des BLOB-Caches finden Sie unter Optimieren der Zwischenspeicherung für WAN-Umgebungen weiter unten in diesem Dokument.

IIS-Komprimierung

Die IIS-Komprimierung wird im Abschnitt Optimieren der Zwischenspeicherung für WAN-Umgebungen in diesem Dokument noch ausführlicher erläutert. Wie bereits erwähnt, wird standardmäßig der Komprimierungsgrad 0 verwendet. Sie sollten mit den verschiedenen Einstellungen für den Komprimierungsgrad experimentieren, bis Sie eine Einstellung gefunden haben, die eine optimale Komprimierung und minimale Auswirkungen auf die CPUs der Webserver bietet. In nahezu allen Fällen können Sie einen Komprimierungsgrad größer als 0 auswählen. Beachten Sie jedoch, dass sich der Komprimierungsgrad nur auf dynamische Dateien bezieht, z. B. AXD- und ASPX-Dateien.

64-Bit-Hardware

Die gewählte Hardware in der Farm kann die Wartezeit von Anforderungen ebenfalls beeinflussen. Für 32-Bit-Systeme gilt ein Speicherlimit von 2 GB RAM pro Anwendung. Zwar können Sie die Anwendungsunterstützung auf 3 GB RAM erweitern, SharePoint-Produkte und -Technologien unterstützen jedoch die Verwendung des Schalters /3GB nicht. Unzureichender Arbeitsspeicher kann die Anforderungswartezeit wie folgt beeinträchtigen:

• Wenn die Speichermenge eingeschränkt wird, kann das dazu führen, dass der SharePoint-Anwendungspool wiederverwendet wird. Dadurch wird zwangsweise auch die ASP.NET-Anwendungsdomäne wiederverwendet, was eine lange Verzögerung bei der Reaktion auf Benutzeranforderungen verursachen kann.

• Fehler aufgrund von unzureichendem Arbeitsspeicher können dazu führen, dass der BLOB-Cache keine Inhalte mehr bereitstellt.

Durch 64-Bit-Hardware können Sie sicherstellen, dass Sie genügend RAM reservieren und verwenden, um derartige Fehler zu vermeiden.

Webgarteneinstellungen

Webgarteneinstellungen können ebenfalls unbeabsichtigt eine inkonsistente Arbeitsweise des BLOB-Caches verursachen. Da nur ein Prozess die erforderliche Sperre zum Verwalten des Caches erhalten kann, hängt die erfolgreiche Verwendung des Cache davon ab, von welchem Thread eine Anforderung bedient wird. Wenn ein Webgarten ohne BLOB-Cachesperre eine Anforderung bedient, werden den in der Antwort gesendeten Inhalten keine Cachedirektiven zugeordnet. Dadurch wird sowohl die Anzahl der Anforderungen als auch die Datenmenge erhöht, die über das Netzwerk gesendet wird. Wenn Sie den BLOB-Cache verwenden möchten, sollten Sie keine Webgärten verwenden.

Minimieren gesicherter Elemente auf der Seite

Wenn ein Benutzer sich bei SharePoint-Produkten und -Technologien authentifiziert, geschehen zwei Dinge. Zunächst überprüft das System die Anmeldeinformationen, um zu bestimmen, wer der Benutzer ist. Als Nächstes listet der Rollenanbieter die Liste der SharePoint-Gruppen auf, denen der Benutzer angehört. Jedes Mal, wenn eine Seite angefordert wird, wird der Rollenanbieter erneut aufgerufen, um alle Gruppen aufzulisten, denen der Benutzer angehört.

Dieser Aufruf zur Ermittlung der Gruppenmitgliedschaft kann allerdings mehrmals auf einer Seite erfolgen. Beispielsweise sind für die Standardseite der Vorlage Zusammenarbeitsportal beim Besuch der Startseite zwei Aufrufe an den Rollenanbieter erforderlich – eine für die Seite selbst und eine für das Bild auf der Seite. Jedes Bild, das in einer SharePoint-Bibliothek gespeichert und auf der Seite vorhanden ist, erzwingt einen weiteren Aufruf des Rollenanbieters, um die Berechtigungen zu überprüfen, auch wenn alle Bilder in derselben Bibliothek gespeichert sind. Die Überprüfung tritt unabhängig davon auf, ob die Bilder der Seite als Felder hinzugefügt werden, also als Seiteninhalt, oder ob sie der Masterseite für die Website hinzugefügt werden.

Eine Website für eine Umgebung mit begrenzter Bandbreite oder hoher Wartezeit sollte so entworfen werden, dass die Anzahl der auf der Seite verwendeten Bilder minimiert wird. Auf vielen Websites werden mithilfe von mehreren Bildern auf der Masterseite unterschiedliche visuelle Effekte erzielt. Da die Wartezeit durch die erhöhte Anzahl von Sicherheitsüberprüfungen steigt, müssen Sie Websites für diese Umgebungen mit so wenigen Bildern wie möglich entwerfen.

Minimieren der Anzahl und Größe von Bildern

Wie im vorherigen Abschnitt beschrieben, sollten Sie die Anzahl der Bilder in Ihrer Website minimieren. Zu diesem Zweck können Sie mehrere Bilder in eine einzelne Datei einbetten und dann in der Seite auf einzelne Bilder verweisen. Dadurch sinkt nicht nur die Downloadgröße der Datei, sondern auch der Netzwerkverkehr, da weniger Dateien übertragen werden müssen. Das Erstellen von Seiten ist mit dieser Vorgehensweise komplizierter, aber in Situationen, in denen jeder Roundtrip und jedes Bit zählt, ist diese Technik eine nützliche Methode zur Leistungsverbesserung. In der folgenden Abbildung ist ein Beispiel einer einzelnen Bilddatei mit mehreren Bildern dargestellt.

In der folgenden Abbildung sehen Sie, wie dieses Bild später geändert wird, sodass einzelne Bilder in einer Tabelle angezeigt werden.

Die Bearbeitung der Bilder erfolgte ausschließlich über Stylesheetklassen. In jeder Tabellenzelle wurden zwei primäre Klassen in den div- und img-Elementen verwendet. Diese Klassen lauten wie folgt:

.cluster {

   height:50px;

   position:relative;

   width:50px;

}

.cluster img {

   position:absolute;

}

Jedem Bild ist eine Klasse zugeordnet, basierend auf dem Bezeichner (ID) für das Bild. Durch die Formatvorlage wird das Bild freigestellt und ein Offset vom ersten Bild in der Gruppe definiert. Diese Klassen lauten wie folgt:

#person {

   border:none;

   clip:rect(0, 49, 49, 0);

}

#keys {

   clip:rect(0, 99, 49, 50);

   left:-50px;

}

#people {

   clip: rect(0, 149, 49, 100);

   left:-100px;

}

#lock {

   clip:rect(0, 199, 49, 150);

   left:-150px;

}

#phone {

   clip:rect(0,249, 49, 200);

   left:-200px;

}

#question {

   clip:rect(0, 299, 49, 250);

   left:-250px;

}

Der HTML-Code für die Tabelle enthält die div- und img-Tags mit den entsprechenden ID-Werten und Klassennamen:

<table border="1">

   <tr>

      <td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

   <tr>

      <td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

</table>

Mehrere Microsoft-Webeigenschaften und -produkte verwenden jetzt diese Technik, u. a. das Microsoft Passport-Netzwerk und Microsoft Office Outlook Web Access (OWA). Das MSN-Team hat einige Leistungstests durchgeführt, um die Auswirkungen der Änderungen zu analysieren. Dabei wurde für die erste Seite eine um 50 bis 75 Prozent bessere Ladedauer festgestellt.

Wenn Sie Seiten in Microsoft Office SharePoint Designer 2007 erstellen, ist ein wichtiger Punkt zu berücksichtigen. Wenn Sie eine neue Seite in Office SharePoint Designer 2007 erstellen, wird der Seite automatisch das folgende XHTML-Schemamarkup hinzugefügt:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

It then adds this namespace to the HTML element:

<html xmlns="http://www.w3.org/1999/xhtml">

Wenn Sie dieses Schema verwenden, werden die Bilder nicht korrekt angeordnet. Sie müssen das xmlns-Attribut aus dem HTML-Tag entfernen, damit die Bilder wie vorgesehen dargestellt werden.

Verzögertes Herunterladen von "core.js"

Die wichtigste Clientskriptdatei in Microsoft Office SharePoint Server 2007 ist core.js. Sie ist mit ca. 257 KB dekomprimiert und ca. 54 KB komprimiert die größte Skriptdatei. In bestimmten Situationen können Sie das Herunterladen der Datei core.js möglicherweise verzögern. Dadurch wird die Seite schneller gerendert, da das Herunterladen der Datei core.js erst gestartet wird, nachdem die Seite im Browser geöffnet wurde. Auf diese Weise kann der Benutzer die Seite schneller anzeigen und lesen. Diese Technik eignet sich am besten in einem Internetszenario mit anonymen Benutzern. Im Gegensatz dazu muss für authentifizierte Benutzer die Datei core.js gleichzeitig mit der Seite geladen werden, damit Funktionalitäten oder Benutzeroberflächenelemente wie das Menü Websiteaktionen verfügbar sind.

Sie können diese Technik mithilfe der folgenden Schritte implementieren.

1. Erstellen Sie eine benutzerdefinierte Layoutseite, die core.js nicht verwendet. Diese Layoutseite wird für die Startseite verwendet, damit die ersten Besucher der Website nicht warten müssen, dass die Datei core.js sofort heruntergeladen wird. Die neue Layoutseite muss mit der vorhandenen Startseite kompatibel sein und sollte daher denselben Inhaltstyp aufweisen wie die derzeit verwendete Layoutseite.

   Hinweis

   Standardmäßig wird in einer Website für ein Zusammenarbeitsportal der Inhaltstyp Homepage angegeben.

2. Fügen Sie der Seite das folgende Tag hinzu: <SharePointWebControls:ScriptLink runat="server"/>. Damit weisen Sie das System an, core.js nur zu verwenden, wenn darauf verwiesen wird.

3. Erstellen Sie ein benutzerdefiniertes Steuerelement, um nach authentifizierten Benutzern zu suchen. Das Steuerelement wird sehr einfach sein und im Wesentlichen den folgenden Code enthalten (in C# dargestellt):

   if (HttpContext.Current.Request.IsAuthenticated)   
       Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
   

4. Legen Sie das Steuerelement auf jedem Webserver im globalen Assemblycache (Global Assembly Cache, GAC) ab, und fügen Sie dann in der Datei web.config für die Webanwendung, in der es verwendet wird, einen entsprechenden SafeControl-Eintrag hinzu.

5. Fügen Sie das benutzerdefinierte Steuerelement der benutzerdefinierten Layoutseite hinzu, die Sie in Schritt 1 erstellt haben.

6. Fügen Sie der Layoutseite ein IFRAME-Element hinzu. Es sollte auf eine Seite mit dem folgenden Inhalt verweisen:

   <body>
   <SharePoint:ScriptLink name="core.js" runat="server" />
   <script language="javascript">
    DisableRefreshOnFocus();
   </script>
   </body>
   

7. Checken Sie die benutzerdefinierte Layoutseite ein, und veröffentlichen Sie sie.

8. Erstellen Sie die Startseite für die Website auf Grundlage der neuen Layoutseite.

Nachdem Sie die vorangehenden Schritte durchgeführt haben, testen Sie die Funktion der Startseite für die Website. Ein anonymer Benutzer sollte beim ersten Besuch keinen Verweis auf core.js im Seitenquellcode sehen, die Datei sollte aber im Browsercache zwischengespeichert werden.

Berücksichtigen Sie darüber hinaus Folgendes, bevor Sie diese Technik verwenden:

• Die Masterseite der Website und die Systemmasterseite müssen unterschiedlich sein. Andernfalls wären alle Seiten in _layouts nicht einwandfrei funktionsfähig.

• Stellen Sie sicher, dass die Masterseite keine Steuerelemente enthält, die für ihre Funktion core.js zur Ladezeit erfordern.

• Stellen Sie sicher, dass die Masterseite keine ScriptLink-Steuerelemente enthält, die core.js laden oder darauf verweisen.

Weitere Einzelheiten und Beispielcode finden Sie im Microsoft Enterprise Content Management (ECM) Team Blog (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=106008&clcid=0x407).

Optimieren von Listenansichtsseiten

Das Microsoft Services-Team hat sich bemüht, die Renderingzeiten von Listenansichtsseiten zu bewerten und zu verbessern. Eine Listenansichtsseite ist die Seite AllItems.aspx, die von jeder Liste und Bibliothek zum Aktivieren der Inhaltssuche verwendet wird. Die Renderingzeit der Seite kann äußerst unterschiedlich sein, je nachdem, wie viele Spalten in der Ansicht sichtbar sind und welches Format sie aufweisen. Beispielsweise können Anzeigeoptionen und das Aktivieren von Anwesenheitssymbolen die Renderingzeit erheblich beeinträchtigen. Das Rendern beim Gruppieren von reduzierten Elementen nahm erheblich mehr Zeit in Anspruch als beim Gruppieren von erweiterten Elementen, und beide Funktionen waren langsamer, als wenn überhaupt keine Gruppierung erfolgt.

Aufgrund derartiger Nuancen ist es so wichtig, sorgfältig zu überlegen, wie Ansichten in Listenansichtsseiten erstellt werden, insbesondere bei langsamen Netzwerkverbindungen. Beim Arbeiten mit Listen, die große Datenmengen enthalten, ist es wichtig, alle Ansichten, insbesondere die Standardansicht, sorgfältig anzupassen. Im Allgemeinen können Sie die Renderingzeit von Listenansichtsseiten durch die folgenden Maßnahmen beschleunigen:

• Anzeigen weniger Spalten

• Ausschließen aller Spalten, die Anwesenheitsinformationen enthalten

• Verwenden eines Links (kein Menü Bearbeiten) zum Anzeigen der Elementdetails

In der folgenden Tabelle werden Anpassungen beschrieben, die den Zeitaufwand für das Rendern einer Ansicht reduzieren.

Element	Beschreibung
Ansichtstyp	Erstellen Sie eine Ansicht als Datenblattansicht statt als Standardansicht.
Ansicht: Eintragsgrenze	Jeder Wert über 1.000 wird wahrscheinlich langsam gerendert. Bei einer langsamen Verbindung müssen Sie experimentieren, um das richtige Gleichgewicht zwischen der Menge der auf einmal dargestellten Daten und der Anzahl der erforderlichen Roundtrips zum Anzeigen aller Daten finden. Je mehr Zeilen auf einmal angezeigt werden, umso weniger Roundtrips sind erforderlich, allerdings sind dafür die Seiten größer.
Ansicht: Filter	Verwenden Sie [Heute] und [Ich] zum Filtern der Elemente nach Aktualität oder Zuordnung. Verwenden Sie Statusfelder, um in Standardansichten nur aktive Elemente anzuzeigen.
Ansicht: Spalten	Verwenden Sie so wenige Spalten wie nötig. Erstellen Sie eine Standardansicht mit wenigen Spalten für allgemeine Suchen mit Drilldownmöglichkeiten.

In der folgenden Tabelle werden Anpassungen beschrieben, durch die der Zeitaufwand für das Rendern einer Ansicht erhöht wird. Mit jeder zusätzlichen Spalte steigt die Renderingzeit leicht: bis zu einer halben Sekunde pro Spalte über eine schnelle Netzwerkverbindung für eine Liste von 1.000 Elementen. Einige Spalten verursachen eine stärkere Erhöhung (siehe Tabelle).

Element	Beschreibung
Gruppieren nach	Beim Gruppieren werden HTML und JScript hinzugefügt, sodass das Rendern für große Listen verlangsamt wird. Wenn alle Gruppen standardmäßig reduziert sind, wird die Renderingzeit aufgrund zusätzlicher Operationen im Browserobjektmodell tatsächlich erhöht.
Spalte – Titel (Hyperlink zu Element mit Menü 'Bearbeiten')	Die Option (Hyperlink zu Element mit Menü 'Bearbeiten') dauert am längsten. Die ähnliche Option (Hyperlink zum Eintrag) erhöht die Renderingzeit nicht deutlich.
Spalte – Benutzer mit Anwesenheitsinformationen suchen	Durch das Hinzufügen eines Benutzernachschlagefelds mit Anwesenheitsinformationen wird für jeden Link HTML-Code zum Öffnen des Anwesenheitsmenüs hinzugefügt. Darüber hinaus wird die Bandbreite genutzt, um die Verfügbarkeit von Anwesenheitsinformationen festzustellen.

In der folgenden Tabelle werden Anpassungen beschrieben, die relativ geringe Auswirkungen auf den Zeitaufwand zum Rendern einer Ansicht haben.

Element	Beschreibung
Sortieren, Summen	Durch das Anwenden mehrerer Sortierungen und Summen wird die Renderingzeit zwar spürbar erhöht, jedes einzelne Element verursacht bei einer Liste von 1.000 Elemente jedoch normalerweise weniger als eine Sekunde.

Optimieren der Zwischenspeicherung für WAN-Umgebungen

In Microsoft Office SharePoint Server 2007 gibt es eine Anzahl verschiedener Zwischenspeicherungsoptionen. Einige von ihnen sollen den Durchsatz in der Renderingpipeline verbessern, von dem Zeitpunkt, zu dem eine Anforderung am Server empfangen wird, bis zu dem Zeitpunkt, zu dem die Übertragung einer Antwort zurück an den Clientcomputer beginnt. Dies ist zwar ein wichtiger Aspekt der Gesamtleistung Ihrer Website, in diesem Abschnitt wird das Zwischenspeichern jedoch schwerpunktmäßig im Hinblick auf die folgenden Aspekte betrachtet:

• Die Rolle der Serverkonfiguration auf die Clientzwischenspeicherung

• Steuern der Größe der Elemente, die über das Netzwerk vom Server an den Client übertragen werden

BLOB-Cache

Der BLOB-Cache ist ein Mechanismus, der nur mit den Veröffentlichungsfeatures von Microsoft Office SharePoint Server 2007 verfügbar ist. Dadurch ist er ideal für Unternehmensportalwebsites, die auf der Websitevorlage Zusammenarbeitsportal basieren, sowie für Internetwebsites, die auf der Websitevorlage Veröffentlichungsportal basieren. Mithilfe des BLOB-Caches können Sie Cachedirektiven konfigurieren, die Elementen zugeordnet werden, die von Veröffentlichungssitelisten bedient werden, z. B. der Bibliothek für Seiten oder Bildern der Websitesammlung. Wenn der Browser auf dem Clientcomputer auf eine Cachedirektive trifft, weiß er, dass das abgerufene Element lokal gespeichert werden kann und erst beim Ablauf der Cachedirektive erneut angefordert werden muss. In einer geografisch verteilten Umgebung ist dies von höchster Wichtigkeit, da dadurch die Anzahl der Elemente reduziert wird, die angefordert und über das Netzwerk übertragen werden.

Wenn der BLOB-Cache in Microsoft Office SharePoint Server 2007 aktiviert ist, hat dies verschiedene Maßnahmen zur Folge. Zunächst einmal wird jedes Mal, wenn ein zwischenspeicherbares Element angefordert wird, das Festplattenlaufwerk des Webservers, der die Anforderung angefordert hat, von Microsoft Office SharePoint Server 2007 durchsucht, um festzustellen, ob bereits eine lokale Kopie vorhanden ist. Ist dies der Fall, wird die Datei direkt vom lokalen Datenträger an den Benutzer übertragen. Falls die Datei noch nicht auf dem lokalen Datenträger vorhanden ist, wird eine Kopie des Elements in der SQL Server-Datenbank erstellt, in der es gespeichert ist. Anschließend wird das Element an den Benutzer gesendet, von dem die Anforderung stammt. Von diesem Moment an können alle Anforderungen des Elements direkt vom Webserver bedient werden, bis der Cachefähigkeitswert des Elements angibt, dass es abgelaufen ist. Auf diese Weise wird die Leistung der Serverfarm verbessert, da Konflikte auf dem Datenbankserver reduziert werden.

Außerdem wird ein Cachefähigkeitsheader an das Element angefügt, wenn es an den Client gesendet wird. Dieser Header weist den Browser an, wie lange das Element zwischengespeichert werden soll. Wenn ein Bild beispielsweise einen Cachefähigkeitswert von drei Tagen hat, verwendet der Browser die Kopie des Bildes in seinem lokalen Cache, sofern das Bild innerhalb der nächsten drei Tage erneut angefordert wird. Es wird nicht erneut vom Server angefordert.

Zum Testen Ihrer Website können Sie Fiddler (http://www.fiddler2.com/fiddler2/) (in englischer Sprache) verwenden, um festzustellen, welche Elemente zwischengespeichert werden und wie sie zwischengespeichert werden. Im folgenden Screenshot ist eine Fiddler-Erfassung einer einfachen SharePoint-Website dargestellt, die für die Veröffentlichung verwendet wird. Die Website wurde mithilfe der Standardvorlage Zusammenarbeitsportal erstellt. Einige zusätzliche Textinhalte wurden der Seite hinzugefügt, und mehrere Bilder wurden der Masterseite hinzugefügt.

In der Anwendung Fiddler sind einige wichtige Informationen enthalten.

• Die #-Spalte auf der linken Seite gibt an, dass zum Rendern der Seite insgesamt 44 HTTP-Anforderungen vom Browser an den Server gesendet wurden.

• Die Result-Spalte zeigt den HTTP-Ergebniscode an, der von der Anforderung für das Element zurückgegeben wurde. Ein Ergebniscode von 200 gibt an, dass das Element erfolgreich abgerufen wurde.

• Die URL-Spalte gibt an, welches Element angefordert wurde.

• Die Body-Spalte gibt die Größe der einzelnen Elemente an.

• Die Caching-Spalte zeigt die Cachedirektive an, die jedem Element zugeordnet wurde. Die Daten in der Caching-Spalte geben an, dass mehreren Elementen eine Cachedirektive zugeordnet ist. Ihr max-age-Attribut ist also größer als 0. Cachedirektiven werden in Sekunden ausgedrückt. Für die dargestellte Seite bedeutet dies, dass mehrere Elemente so konfiguriert sind, dass sie 365 Tage zwischengespeichert werden (60 Sekunden pro Minute, 60 Minuten pro Stunde, 24 Stunden pro Tag = 60x60x24 = 86.400x365 = 31.536.000).

Beachten Sie, dass sich alle Elemente mit dieser Cachedirektive im Verzeichnis _layouts befinden. Sie haben diese Cacheeinstellung aufgrund der Art Weise, wie das virtuelle Verzeichnis _layouts/images in IIS konfiguriert ist. Wenn Sie eine neue Webanwendung erstellen, werden in Microsoft Office SharePoint Server 2007 automatisch mehrere virtuelle Verzeichnisse erstellt, die Ordnern auf den physischen Datenträgern des Webservers zugeordnet sind. Beim Erstellen des Verzeichnisses _layouts/images wird dem gesamten Verzeichnis eine Cachedirektive hinzugefügt. Im folgenden Screenshot ist die Konfiguration für das Verzeichnis im IIS-Manager-Snap-In abgebildet.

Da allen Elementen eine Cachedirektive ungleich null zugeordnet ist, verwendet der Browser bei der nächsten Anforderung der Seite die Kopie des Elements im lokalen Browsercache, anstatt es erneut vom Server anzufordern. Im folgenden Screenshot ist ein Snapshot von Fiddler dargestellt, wenn die Seite ein zweites Mal angefordert wird.

Aus den Fiddler-Daten geht hervor, dass die Anzahl von angeforderten Elementen deutlich gesunken ist – von 44 auf 11. Es ist jedoch zu beachten, dass die Anzahl der Anforderungen davon abhängig ist, wie die Seite angefordert wird. Wenn Sie die Schaltfläche Aktualisieren im Browser verwenden, werden wahrscheinlich alle Elemente erneut angefordert, selbst wenn eine lokal zwischengespeicherte Version des Elements vorhanden ist. Wenn die Seite jedoch durch Navigieren mithilfe eines Links oder einer Verknüpfung angefordert wird, werden nur die Elemente angefordert, die nicht im Zwischenspeicher vorhanden sind.

Aus den Fiddler-Daten geht weiterhin hervor, dass der Browser vom Server die anderen Bilder auf der Masterseite anfordert, die bereits im lokalen Cache vorhanden sind. Der Antwortcode 304 gibt dies an. Dieser Code bedeutet, dass der Browser eine bedingte Anforderung für ein Element gesendet hat. Die Antwort 304 bedeutet, dass die Version auf dem Server gegenüber der Version auf dem Client nicht geändert wurde und daher nicht erneut heruntergeladen werden muss. Die Datei wird zwar nicht über das Netzwerk heruntergeladen, es ist jedoch ein Roundtrip zum Server angefallen, um festzustellen, ob die lokale Kopie aktuell ist. In einer geografisch verteilten Umgebung verursachen Serverroundtrips eine hohe Last und sollten daher auf ein Minimum reduziert werden. Wenn jedem der verbleibenden Elemente (mit Ausnahme der Seite, die immer vom Server zurückgegeben wird) eine Cachedirektive ungleich null hinzugefügt wird, kann dieses Ziel erreicht werden. Diese Cachedirektive wird mit dem BLOB-Cachefeature hinzugefügt.

Sie konfigurieren den BLOB-Cache mithilfe der Datei Web.config für die Webanwendung, in der der Cache verwendet wird. Öffnen Sie die Datei Web.config in einem Text-Editor wie Microsoft Editor, und suchen Sie nach dem BlobCache-Eintrag. Standardmäßig ist dies folgender Eintrag:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>

Die Attribute im BlobCache-Element haben die folgende Bedeutung:

• location    Verweist auf den Speicherort auf dem Festplattenlaufwerk des Webservers, an dem zwischengespeicherte Elemente zwischengespeichert werden.

• path   Ein regex-Ausdruck der Dateitypen, die zwischengespeichert werden sollen.

• maxSize **   **Die maximale Größe in GB, die für den Cache zur Verfügung steht.

• enabled    Auf true festgelegt, um den BLOB-Cache zu aktivieren.

Das folgende zusätzliche Attribut, das nicht standardmäßig enthalten ist, ist erforderlich, um einen Wert für das Cacheablaufdatum für einzelne Elemente festzulegen:

• max-age   Die Zeit in Sekunden, die Elemente auf dem Clientcomputer zwischengespeichert werden sollen.

Wenn das max-age-Attribut auf einen Wert ungleich null festgelegt wird, wird zwischenspeicherbaren Elementen ein Wert für das Cacheablaufdatum zugeordnet, sodass ein Browser sie nicht mehr herunterladen oder auch überprüfen muss, ob die aktuellste Version vorhanden ist. Nehmen Sie beispielsweise an, Sie möchten die Zwischenspeicherung aktivieren und bis zu 100 MB auf dem Webserver zum Speichern von Elementen reservieren. Diese sollen einmal am Tag ablaufen. Zusätzlich zu den vordefinierten Typen, die zwischengespeichert werden, sollen auch HTC-Dateien zwischengespeichert werden. Zur Unterstützung dieser Anforderungen geben Sie die folgenden BlobCache-Attribute an:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

Beachten Sie, dass diese Änderung in der Datei Web.config auf jedem Webserver in der Serverfarm vorgenommen werden muss. In den meisten Fällen beginnt der BLOB-Cache sofort zu arbeiten, am sichersten verwenden Sie jedoch den Befehl iisreset, wenn Sie die Änderungen implementieren. Im folgenden Screenshot sind Fiddler-Daten für die gleiche Seitenanforderung dargestellt, allerdings dieses Mal mit aktiviertem BLOB-Cache.

Beachten Sie, dass alle Elemente in der Bibliothek /SiteCollectionImages jetzt einen HTTP-Statuscode von 200 haben, der angibt, dass sie erfolgreich heruntergeladen wurden. Außerdem ist allen eine Cachedirektive zugeordnet, die angibt, dass sie einen Tag (86.400 Sekunden) lang nicht ablaufen. Wenn die Seite erneut angefordert wird, wird in Fiddler angezeigt, dass keines der Bilder erneut angefordert wird. Die Gesamtanzahl der Anforderungen zum Rendern dieser Seite sinkt damit von 44 auf nur noch 3, davon stammen 2 von der NTLM-Authentifizierungsaushandlung zwischen dem Webserver und der Clientanwendung. In der folgenden Abbildung sind die Fiddler-Daten beim erneuten Seitenabruf dargestellt.

Berücksichtigen Sie bei der Arbeit mit dem BLOB-Cache darüber hinaus Folgendes:

• Es ist ein gewisser zusätzlicher Konfigurationsaufwand erforderlich, da Sie die Datei Web.config auf jedem Webserver aktualisieren müssen. Allerdings sind die Vorteile den Aufwand wert.

• Prüfen Sie Ihre Websiteinhalte, und ermitteln Sie, ob noch andere Dateitypen aus dem Cache bedient werden sollten. Ein gutes Beispiel sind HTC-Dateien. Da HTC-Dateien in den meisten Veröffentlichungssites verwendet werden, sollten Sie diesen Dateityp der Liste der zwischengespeicherten Dateitypen hinzufügen.

• Der BLOB-Cache funktioniert nur für Elemente, die in SharePoint-Bibliotheken gespeichert sind. Er kann nicht zum Zwischenspeichern von Inhalten aus anderen Quellen verwendet werden.

• Einige Listen sind standardmäßig nicht für anonyme Benutzer funktionsfähig. Wenn anonyme Benutzer auf die Website zugreifen, müssen Berechtigungen für die folgenden Listen manuell konfiguriert werden, damit die darin enthaltenen Elemente zwischengespeichert werden:

  • Masterseitenkatalog

  • Formatbibliothek

Es gibt zwei andere Konfigurationsoptionen, die beim Arbeiten mit dem BLOB-Cache zu beachten sind. Die erste hängt mit dem Löschen des BLOB-Caches zusammen. Wenn der Cache für eine bestimmte Website gelöscht werden muss, navigieren Sie zur betreffenden Websitesammlung, und klicken Sie auf Aktionen, auf Websiteeinstellungen und dann auf Alle Websiteeinstellungen ändern. Klicken Sie in der Aufgabenliste Websitesammlungsverwaltung auf den Link zum Objektcache der Websitesammlung. Aktivieren Sie im Abschnitt Zurücksetzen des datenträgerbasierten Caches das Kontrollkästchen Zurücksetzen des datenträgerbasierten Caches dieses Servers erzwingen, und klicken Sie dann auf OK.

Wenn Sie Webgärten in einer SharePoint-Serverfarm verwenden möchten, müssen Sie auch bedenken, dass dies zur Folge hat, dass der BLOB-Cache scheinbar inkonsistent arbeitet. Wenn mehrere Webgärten in einer Serverfarm konfiguriert sind, stellt dies ein Problem dar, da nur einer davon die erforderliche Sperre zum Verwalten des BLOB-Caches erhalten kann. Folglich scheint es so, dass der BLOB-Cache nur zeitweise funktioniert. Die erfolgreiche Verwendung des BLOB-Caches ist dann davon abhängig, von welchem Thread eine Anforderung bedient wird.

IIS-Komprimierung

Im Gegensatz zu früheren Versionen von SharePoint-Produkten und -Technologien ist die IIS-Komprimierung nun automatisch aktiviert, wenn Sie SharePoint-Produkte und -Technologien installieren. Nachdem eine Website von einigen Benutzern besucht wurde, können Sie die Funktionsweise der Komprimierung überprüfen, indem Sie das Verzeichnis %WINDIR%\IIS Temporary Compressed Files auf einem Webserver anzeigen. Es sollte mehrere Dateien enthalten, was ein Hinweis darauf ist, dass statische Dateien angefordert wurden und von IIS eine Kopie dieser Dateien komprimiert und auf dem lokalen Laufwerk gespeichert wurde. Wenn diese Datei vom selben oder einem anderen Benutzer erneut angefordert wird, wird die komprimierte Version der Datei direkt aus diesem Ordner bereitgestellt. Dynamische Dateien können ebenfalls komprimiert werden, allerdings stets dynamisch; Kopien werden auf dem lokalen Webserver beibehalten.

Die Komprimierung kann zu erheblichen Bandbreiteneinsparungen führen. Die Datei core.js ist beispielsweise auf jeder SharePoint-Seite enthalten. Unkomprimiert ist sie 257 KB groß; nach der Komprimierung ist die Datei ohne zusätzliche Optimierung der IIS-Komprimierung nur 54 KB groß. Die Datei core.js sollte nach dem ersten Besuch der Website zwischengespeichert werden. Dieses Beispiel zeigt aber deutlich, welche Vorteile die Komprimierung in Szenarien mit niedriger Bandbreite bietet.

Wenn SharePoint-Produkte und -Technologien installiert sind, wird IIS beim Setup so konfiguriert, dass die statischen Dateitypen .htm, .html und .txt komprimiert werden; die dynamischen Dateitypen .asp und .exe werden ebenfalls komprimiert. Die Überprüfung der in Ihrer Implementierung häufig verwendeten Dateitypen kann ergeben, dass möglicherweise zusätzliche Dateitypen komprimiert werden sollten. Beispielsweise kann es sinnvoll sein, auch die statischen Dateitypen .css und .js sowie die dynamischen Dateitypen .axd und .aspx zu komprimieren.

Um der Liste der Typen, die komprimiert werden, einen statischen oder dynamischen Dateityp hinzuzufügen, verwenden Sie die Datei adsutil.vbs, die sich auf jedem Webserver standardmäßig im Ordner %SYSTEMDRIVE%\Inetpub\AdminScripts befindet. Das folgende Beispiel stammt aus Microsoft Windows Server 2003 und zeigt, dass CSS- und JS-Dateien in der Liste der komprimierten statischen Dateitypen enthalten sind:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "htm" "html" "txt" "css" "js"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions "htm" "html" "txt" "css" "js"

Das folgende Beispiel zeigt die Liste der dynamischen Dateitypen, in die zusätzlich ASPX- und AXD-Dateien aufgenommen werden:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

Stellen Sie beim Ändern der Dateitypen, die komprimiert werden, sicher, dass Sie nur Dateien einbinden, die sich für die Komprimierung eignen. Beispielsweise sind JPG-Dateien kein guter Kandidat für die Komprimierung, da das Dateiformat grundsätzlich bereits komprimiert ist. Auch 2007 Microsoft Office System-Dateitypen (z. B. .docx, .xlsx und .pptx) sind keine gute Wahl für die Komprimierung, da die Dateien nicht direkt vom Server bedient werden; stattdessen werden sie über die verschiedenen ISAPI-Filter geleitet, die zum Verwalten der umfangreichen integrierten Endbenutzerfreundlichkeit für Microsoft Office-Inhalte verwendet werden. Darüber hinaus werden diese Dateitypen in 2007 Microsoft Office System grundsätzlich komprimiert.

Neben den Dateitypen, die komprimiert werden, ist es auch möglich, den Komprimierungsgrad für dynamische Dateitypen zu steuern. Der Komprimierungsgrad basiert auf einer Skala von 0 bis 10. Je höher der Komprimierungsgrad, umso kleiner sind die Dateien. Der Nachteil ist jedoch, dass höhere Komprimierungsgrade auch die CPU stärker belasten. Kleinere Dateien gehen also zulasten der CPU-Auslastung. Wenn die IIS-Komprimierung aktiviert wird, wird ein Komprimierungsgrad von 0 eingestellt. In der Vergangenheit hat sich 9 als idealer Komprimierungsgrad für SharePoint-Produkte und -Technologien bewährt. Verwenden Sie die weiter oben in diesem Artikel beschriebene Skriptdatei adsutil.vbs, um den Komprimierungsgrad zu ändern. Im folgenden Beispiel ist dargestellt, wie Sie den Komprimierungsgrad in 9 ändern.

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

  Hinweis

  Diese Einstellung ändert nicht die Komprimierung von statischen Dateien.

Weitere Informationen finden Sie unter Verwenden der HTTP-Komprimierung in IIS 6.0 (in englischer Sprache) (https://go.microsoft.com/fwlink/?linkid=108705&clcid=0x407).

Kombinieren des BLOB-Caches mit der IIS-Komprimierung

Durch Aktivieren des BLOB-Caches können Sie die Anzahl der Serverroundtrips und Dateien erheblich reduzieren, die über das Netzwerk gesendet werden, wenn ein Benutzer eine SharePoint-Website besucht. Wenn Komprimierung in Verbindung mit dem BLOB-Cache verwendet wird, wird zusätzlich die Menge des Datenverkehrs für die Dateien verringert, die an Clients gesendet werden. Die Kombination der beiden Methoden kann den Netzwerkverkehr sowie Konflikte für Netzwerk- und Serverressourcen erheblich verringern.

Herunterladen dieses Buchs

Dieses Thema wurde zum leichteren Lesen und Ausdrucken in das folgende Buch zum Herunterladen aufgenommen:

• Planung und Architektur für Office SharePoint Server 2007, Teil 2 (in englischer Sprache)

Die vollständige Liste der verfügbaren Bücher finden Sie unter Bücher zum Herunterladen für Office SharePoint Server 2007.

Siehe auch

Konzepte

Optimieren benutzerdefinierter Webparts für das WAN
Erweitern von globalen Office SharePoint Server-Lösungen mit Office Outlook 2007 und Office Groove
Unterstützte globale Lösungen für Office SharePoint Server