Planifier les limites logicielles (Project Server)
Mis à jour: mai 2009
Dernière rubrique modifiée : 2015-02-27
Dans cet article :
Environnement de test
Résultats des tests
Instructions pour des performances acceptables
Cet article contient des informations pour vous aider à comprendre les performances testées et les limites de capacité de Microsoft Office Project Server 2007, ainsi que des détails sur l'environnement de test et le résultat des tests. Il présente également des instructions pour obtenir des performances acceptables. Utilisez les informations de cet article pour déterminer si votre déploiement prévu se situe dans les limites acceptables en matière de performances et de capacité.
Les résultats des tests et les instructions présentées dans cet article s'appliquent à une installation unique de Office Project Server 2007. L'ajout d'ordinateurs serveurs à l'installation n'augmente pas les limites de capacité des objets de site répertoriés dans le tableau de la section Instructions pour des performances acceptables. En revanche, l'ajout d'ordinateurs serveurs augmente le débit d'une batterie de serveurs, ce qui peut s'avérer nécessaire pour atteindre des performances acceptables avec de grandes quantités d'objets. Dans certains cas, la configuration requise pour de grandes quantités d'objets dans une solution peut imposer le recours à plusieurs batteries de serveurs.
Dans cet article, les instructions sont déterminées par les performances. En d'autres termes, vous pouvez dépasser les instructions fournies, mais une augmentation de l'étendue du déploiement peut entraîner une réduction des performances.
Notez que de nombreux facteurs peuvent avoir une incidence sur les performances d'un environnement donné et que chacun de ces facteurs peut toucher les performances de différents domaines. Certains des résultats de tests et recommandations de cet article peuvent être liés à des fonctionnalités ou des opérations utilisateur qui n'existent pas dans votre environnement et qui ne s'appliquent donc pas à votre solution. Seuls des tests rigoureux peuvent vous fournir des données exactes en rapport avec votre propre environnement.
Étant donné que Office Project Server 2007 repose sur Windows SharePoint Services 3,0, la plupart des facteurs ayant un impact sur les performances et la capacité de Windows SharePoint Services 3,0 affecteront également Office Project Server 2007. Pour plus d'informations sur la planification de la capacité et des performances pour Windows SharePoint Services 3,0, voir Planifier les performances et la capacité (Windows SharePoint Services).
Environnement de test
Pour obtenir un niveau élevé de détail dans les résultats des tests, plusieurs configurations de batterie de serveurs ont été utilisées pour le test, notamment un ordinateur serveur jouant les rôles de serveur Web et de serveur d'applications, un ou deux ordinateurs clients et un seul ordinateur serveur de base de données exécutant le logiciel de base de données Microsoft SQL Server 2000. Certains tests ont été effectués avec un autre ordinateur serveur d'applications. Un ordinateur contrôleur de domaine dédié a également été utilisé dans l'atelier de test. Tous les ordinateurs serveurs étaient des ordinateurs 32 bits.
Le tableau suivant répertorie les spécifications des ordinateurs qui assurent chaque rôle dans l'environnement de test.
Rôle de l'ordinateur | Spécifications | ||
---|---|---|---|
Serveur Web et serveur d'applications |
4 processeurs AMD Opteron 2,2 gigahertz (GHz), 2 gigaoctets (Go) de mémoire vive (RAM) |
||
Serveur d'applications |
4 processeurs AMD Opteron 2,2 GHz, 2 Go de RAM |
||
Serveur de base de données |
4 processeurs Intel Xeon 1,5 GHz, 4 Go de RAM |
||
Client |
1 processeur Pentium D 3 GHz, 2 Go de RAM |
||
Contrôleur de domaine |
2 processeurs Pentium III 1 GHz, 512 mégaoctets (Mo) de mémoire vive (RAM)
|
Un réseau Ethernet 100 mégabits/s a été utilisé entre les ordinateurs de la batterie de serveurs.
Résultats des tests
Les graphiques, courbes et tableaux suivants illustrent comment l'environnement de test a créé des conditions données de configuration de serveurs, d'opérations utilisateur et de charge. Les résultats obtenus s'appliquent à tous les environnements Office Project Server 2007 similaires.
Remarque : |
---|
D'autres configurations seront testées ultérieurement. Les résultats des tests seront publiés lorsqu'ils seront disponibles. |
Les mesures de performances pour différentes opérations varient en fonction de facteurs tels que la taille des fichiers de projet, le nombre de planifications existantes dans un projet donné et le débit de la batterie de serveurs. Par exemple, un petit fichier de projet, d'une taille inférieure à 1 mégaoctet (Mo), peut être enregistré en moins d'une seconde, alors qu'un fichier de projet de 50 Mo demandera probablement plus d'une minute, selon la configuration de votre batterie et la latence du réseau.
Normes de test pour la taille des projets
Le tableau suivant décrit les trois tailles de fichier de projet utilisées dans le test.
Taille | Taille de fichier (Mo) | Nombre de tâches | Nombre de ressources | Nombre d'affectations |
---|---|---|---|---|
Petite |
0,896 |
10 |
10 |
10 |
Moyenne |
2,03 |
1 420 |
94 |
1 486 affectations sur des ressources réelles, 380 non affectées |
Grande |
8,139 |
10 422 |
2 |
5 affectations sur des ressources réelles, 7 693 non affectées |
Synchronisation Active Directory
Ce test a été effectué pour mesurer la dégradation des performances de synchronisation du service d'annuaire Active Directory en fonction de la hausse du nombre de ressources.
Windows SharePoint Services 3,0 fournit l'architecture sous-jacente de sécurité et de gestion des utilisateurs pour Office Project Server 2007. Pour gérer les utilisateurs de domaine en tant que ressources dans Office Project Server 2007, vous devez synchroniser Active Directory pour le domaine avec Windows SharePoint Services 3,0 sur l'un des serveurs de votre batterie.
La synchronisation Active Directory ne montre pas la complexité linéaire liée au nombre de ressources importées. La complexité est grossièrement quadratique et la synchronisation entre Windows SharePoint Services 3,0 et Active Directory l'illustre bien. En fonction des résultats des tests, on peut estimer que la synchronisation de Windows SharePoint Services 3,0 pour une organisation de 20 000 postes nécessiterait environ 28 heures sur le matériel de test. La synchronisation de Windows SharePoint Services 3,0 pour une organisation de 40 000 postes devrait être terminée en 109 heures environ (4,6 jours). Notez que ces estimations reposent sur les spécifications matérielles et réseau utilisées pour ce test.
En général, le doublement de la taille de la liste de ressources nécessite presque quatre fois plus de temps pour la synchronisation Active Directory, avec une batterie de serveurs et une bande passante réseau données. Quel que soit le matériel, pour une organisation très étendue, la première tâche de synchronisation Active Directory est probablement exécutée pendant plusieurs jours.
Le graphique suivant illustre le temps nécessaire à une synchronisation Active Directory complète en fonction de l'augmentation du nombre de ressources.
Pour plus d'informations sur la synchronisation entre Active Directory et Office Project Server 2007, voir « Gérer la synchronisation Active Directory dans Project Server 2007 ».(Ce lien n’est pas encore disponible. Il le sera dans les versions ultérieures de ce document.)
Effet des planifications sur les performances
Office Project Server 2007 permet l'enregistrement de 11 planifications au maximum dans un projet donné. À mesure que le nombre de planifications d'un projet augmente, les performances sont touchées sous plusieurs angles. Le test a été effectué pour déterminer les conséquences de l'enregistrement d'un nombre croissant de planifications pour les projets de petite taille, de taille moyenne et de grande taille.
Dans notre test, les tailles de fichier et les hausses de mémoire virtuelle semblent grossièrement linéaires par rapport au nombre de planifications enregistrées d'un projet. Le temps nécessaire à l'enregistrement d'une planification augmente avec la taille du projet. Le temps nécessaire aux opérations d'E/S de fichier n'a pas augmenté pour les projets de petite à moyenne taille jusqu'au nombre maximal de planifications. Pour les grands projets, le temps nécessaire aux opérations d'E/S de fichier augmente nettement après l'ajout d'une huitième planification.
Limites de profondeur et de largeur de projet
Des tests ont été effectués pour déterminer en quoi les performances sont touchées lorsque des sous-projets sont insérés dans les projets principaux. Deux types de test ont été effectués :
Test de profondeur (récursif)
Test de largeur (non récursif)
Test de profondeur
Le test de profondeur impliquait l'insertion récursive de sous-projets. Par exemple, Proj01 a été inséré dans Proj02. Cette chaîne a été ensuite insérée dans Proj03, laquelle a été insérée dans Proj04 et ainsi de suite. Chaque projet de la chaîne était identique et l'objectif du test était d'évaluer combien de fois chaque projet (petit, moyen, grand) pouvait être inséré de manière récursive et comment diverses mesures de performances ont réagi.
Dans les tests d'insertion récursive, presque tous les paramètres importants ont évolué de manière linéaire. Le facteur limitant sur la profondeur est l'utilisation de la mémoire ; par exemple, à 16 niveaux, le grand projet, qui contenait environ 10 000 tâches, approche les limites de mémoire virtuelle 32 bits. Même dans cet exemple, cependant, les opérations d'enregistrement étaient exécutées très rapidement. D'autres opérations, telles que la fermeture et la réouverture du projet principal, l'insertion de nouvelles couches et le recalcul forcé, ont été nettement plus longues. Une plateforme serveur 64 bits peut augmenter considérablement le nombre de projets que vous pouvez insérer, mais les projets qui nécessiteraient une telle profondeur ne sont pas courants.
Le graphique suivant illustre l'augmentation du temps nécessaire pour effectuer des opérations d'E/S de fichier lorsque le nombre de projets insérés augmente de manière récursive. Notez que les grands projets ne sont pas représentés, car les performances des projets de taille moyenne ont connu une dégradation importante après un nombre relativement faible de récursions.
Test de largeur
Le test de largeur impliquait l'insertion de sous-projets au même niveau hiérarchique (autrement dit de manière non récursive) dans un projet principal unique.
Chaque paramètre important a évolué de manière linéaire avec la largeur du projet. L'utilisation de la mémoire devient un goulet d'étranglement après avoir inséré de manière non récursive environ 35 fichiers de taille moyenne, et le temps nécessaire à l'exécution des opérations d'enregistrement et d'ouverture est d'environ 400 secondes sur une largeur de 20 projets. Comme avec l'insertion récursive, l'utilisation d'une plateforme 64 bits augmenterait considérablement le nombre de projets insérables, mais les projets nécessitant une telle largeur ne sont pas courants.
Le graphique suivant illustre l'augmentation du temps nécessaire pour effectuer des opérations d'E/S de fichier lorsque le nombre de projets de taille moyenne insérés augmente de manière non récursive.
Performances de Project Server et latence du réseau
Office Project Server 2007 fonctionne bien dans les environnements dont la latence réseau est élevée. Les modifications de conception apportées à Office Project Server 2007 offrent de nets avantages dans les scénarios courants d'E/S de fichier mono-utilisateur, en particulier dans les environnements de réseau étendu (WAN) à latence élevée. L'ouverture d'un fichier volumineux sur un réseau étendu à latence élevée (50 ms) dans Project Server 2003 pouvait durer jusqu'à 45 minutes, mais la même opération testée sur Office Project Server 2007 a duré moins d'une minute. Le Créateur d'équipe de Office Project Professional 2007 présente des gains de performances similaires dans les environnements de réseau étendu. Bien qu'il existe de clairs avantages à utiliser une connexion réseau à faible latence, les performances de Office Project Server 2007 sur les réseaux étendus (WAN) se sont améliorées de façon spectaculaire par rapport aux versions précédentes.
Bien que les performances initiales au démarrage de Office Project Server 2007 soient inférieures à celles de Project Server 2003, l'application fonctionne nettement mieux aux démarrages suivants et surpasse son prédécesseur.
Instructions pour des performances acceptables
La capacité dépend directement de l'évolutivité. Cette section décrit les objets qui peuvent composer une solution Solution Microsoft Office Enterprise Project Management (EPM) et fournit les instructions pour des performances acceptables pour chaque type d'objet.
Si les plans de votre solution dépassent les consignes recommandées pour un ou plusieurs objets, effectuez une ou plusieurs des actions suivantes :
Évaluez la solution pour vous assurer que des compensations sont apportées dans d'autres domaines.
Repérez les zones à tester et à surveiller à mesure que vous créez et déployez votre solution.
Reprenez la conception de la solution pour vous assurer que les consignes de capacité ne sont pas dépassées.
Le tableau suivant répertorie les objets Office Project Server 2007 auxquels des limites s'appliquent et contient les instructions recommandées pour des performances acceptables. Performances acceptables signifie que le système tel que testé peut prendre en charge ce nombre d'objets, mais que le nombre ne peut pas être dépassé sans une dégradation des performances. Un astérisque (*) indique une limite physique ; l'absence d'astérisque indique une limite testée ou prise en charge.
Objet | Instructions pour des performances acceptables | Remarques |
---|---|---|
Ressources par batterie de serveurs |
40 000 |
Il s'agit de la limite testée. |
Planifications par projet |
7 recommandées 11 maximum* |
Les tests ont révélé une dégradation des performances pour certaines opérations sur de gros fichiers de projets lorsque plus de sept planifications étaient générées. Pour plus d'informations, voir « Effet des planifications sur les performances » plus haut dans cet article. |
Profondeur de projets insérés (récursif) |
16 |
La dégradation des performances à ce niveau est importante. |
Largeur des projets insérés (non récursif) |
20 |
La dégradation des performances à ce niveau est importante. |
Tâches par projet |
5 000 |
Il s'agit de la limite testée. |
Durée de la tâche en mois |
300 |
L'intervalle de temps pour qu'un projet soit publié dépend de la durée de la tâche lorsque des profils y sont appliqués. Cet impact peut être significatif, en particulier si Solution EPM est utilisé pour créer des projets qui s'étendent sur plusieurs années. Il s'agit de la limite testée. |
Affectations par tâche |
16 000 |
Il s'agit de la limite testée. Bien que vous puissiez ajouter plus de 16 000 affectations par tâche, il a fallu plus de sept secondes pour ajouter une affectation à une tâche qui en contenait déjà 16 000. |
Champs de formule personnalisés locaux |
10-30 |
Le nombre de champs de formule personnalisés locaux autorisé par tâche dépend du type du champ personnalisé. La liste suivante affiche les types de champ personnalisé et leurs limites :
|
Champs de formule personnalisés d'entreprise par serveur |
32 000 |
Il s'agit d'une limite théorique, qui s'applique à chaque type d'entité auquel vous pouvez appliquer un champ. Toutefois, le test de performances n'a pas été effectué avec plus de 1 000 champs personnalisés d'entreprise environ. |
Limites de ressources du Créateur d'équipe |
10 000 ressources |
La boîte de dialogue Créateur d'équipe s'affiche en moins de cinq secondes même lorsque 10 000 ressources sont présentes sur le serveur. Bien que 10 000 ressources soit la limite testée, le Créateur d'équipe est utilisable avec davantage de ressources tant que l'augmentation correspondante de la durée nécessaire à l'affichage de la boîte de dialogue reste acceptable. |