Tune Project Online performance

< More Project help

With the launch of Project Online a few years ago, organizations of all sizes have been able to use Microsoft's rich set of Project Portfolio Management (PPM) capabilities within the convenience of our Office 365 cloud infrastructure.

Although one of the obvious benefits of using a cloud-based service is avoiding having to deal with deployment, setup, and hardware and software tuning, there are still some steps you can take to ensure your organization gets the best performance out of Project Online.

Project Online offers many configuration and customization settings, but customizations can have a performance impact. This article highlights the performance impact and tradeoffs of some of the most common Project Online settings, so you can make informed decisions when it comes to customizing and configuring Project Online.

This article is part of the Network planning and performance tuning for Office 365 project.

Office 365 and SharePoint Online best practices

There is a wealth of information around network planning and performance tuning for SharePoint Online and Office 365. All this information is relevant to Project Online customers and should be consulted in addition to the following best practices specific to Project Online.

Project Online configuration and customization

Many elements of a Project Web App site can be configured and customized, from administrative settings to permissions, and from collaboration settings to look-and-feel. Let's look at the settings that can potentially have an impact on the overall performance of your Project Web App site.

We will cover:

• Security permissions modes

• Synchronization mechanisms between Project Online and SharePoint Online

• Project sites provisioning (collaboration workspaces)

• UI customization and look-and-feel

• Project Detail Pages (PDP) and workflows

• OData and reporting

(Much of this information applies to Project Server 2013as well.)

Permission modes: SharePoint or Project

With Project Online and Project Server 2013, we introduced a new and simplified permission model called SharePoint permission mode, as opposed to the legacy Project permission mode. The comparison between both modes can be found on Technet.

New Project Online instances are provisioned in SharePoint permission mode by default, and we are confident this mode will address the needs of the vast majority of customers. By using this mode, you can manage user authorization via regular SharePoint groups and permissions.

Project permission mode offers a high degree of customizability, but it can come at a price in terms of performance. If you create hundreds of categories and rely heavily on dynamic permissions via your Resource Breakdown Structure (RBS), it might slow down the end-user experience for users who have access to a lot of content, such as admins and portfolio managers.

Note: Switching between SharePoint permission mode and Project Server permission mode deletes all security-related settings. If you switch from SharePoint permission mode to classic Project Server permission mode, you have to manually configure your security permissions structure in Project Server 2013. Switching from Project Server permission mode back to SharePoint permission mode deletes your security permissions information from Project Server 2013.

Recommendation:    

When possible, keep the default SharePoint permission mode for better overall performance. If you need to use Project permission mode, limit your customizations as much as possible.

What do you sync?

Project Online runs on top of SharePoint Online the same way Project Server runs on top of SharePoint Server. As a result, we have to keep in sync a certain number of components between to two systems. These synchronizations can be time consuming and, depending on your business needs, can sometimes be unnecessary. This article explores all these various synchronization systems to help you decide which ones you need and which ones you can safely turn off. Some of these settings are already off be default.

In the following sections, we discuss:

• Project Site permission sync

• Active Directory Resource Pool sync

• SharePoint Task List sync for Enterprise projects

Project site permission sync

Project Sites are workspaces where project teams can collaborate, upload documents, and raise issues. When Project site permission sync is enabled, whenever a person is granted permission to a project, the corresponding Project site permissions are updated.

This synchronization happens every time the project is published. The tradeoff for the sync convenience is performance, e.g. the more users and sites that need to be synced, the slower the operation, especially if you're bulk publishing, importing or creating multiple projects (with Projects sites), or updating group memberships that will require a resync of project site permissions.

Recommendation:   

We strongly recommend that you disable the Project site permission sync option if the following is true of your deployment:

• You have a large number of resources (>1000)

• You have a large number of projects which require a Project site (>1000)

• You have a large number of resources that need to be granted access to the majority of Project sites

Here are some options to consider for managing your Project site permissions:

• If your project teams have low turnover, consider disabling Project site permission sync to improve Project Publish and Project Detail Pages performance. You would then have to manually grant or remove permission to your Project sites whenever someone joins or leaves a project team.

• If access needs to be granted for all users in PWA and it maps to your existing group permissions, consider configuring your Project sites to inherit from the parent PWA site.

• If site access aligns with specific roles, create one or more groups that map to those roles (possibly if you have Group sync enabled, you can use the same groups) and grant those groups access to the Project site.

Active Directory Resource Pool sync

Active Directory Resource Pool sync by itself does not have particular performance issues and can import thousands of resources into your Project Web App instance in minutes. However, its downstream effect on other parts of the system can impact performance. The primary process to keep an eye on is the resource permission sync previously mentioned. If there is large turnover in your Active Directory groups membership, and that requires you to sync your Resource Pool often, monitor any potential downstream effects on related permission sync jobs.

Recommendation:   

Limit Active Directory sync to groups of resources that actually need to use the system, and monitor any potential permission issues after the synchronization of large groups. (To configure Active Directory Enterprise Resource Pool Synchronization, in Project Web App Settings, click Active Directory Resource Pool Synchronization.)

SharePoint Task List sync for Enterprise projects

SharePoint Task List sync for enterprise projects is turned off by default to improve the speed of project publishing. This also helps speed the transition between Project Detail Pages. If your users rely on the task list and its timeline visualization in the Project site, you can turn this feature on and check if its impact on the performance of project publishing is reasonable.

Recommendation:   

This option is turned off by default. Only turn Task List ync on if your users need the feature. To configure this option, in Project Web App Settings, click Connected SharePoint Sites, and then click Settings.

Project sites

Project sites are built on core SharePoint functionality. Creating project sites is not a lightweight process, and deciding if and when your organization might need project sites can go a long way in improving the overall end-user experience.

A lot of organizations use Project Online to collect and rate project proposals before deciding which projects to fund. If project sites are set to be automatically created the first time a project is published, then all project proposals, even the ones that don't make the cut, get a project site. These unnecessary sites would have to be manually cleaned up afterwards.

A better approach, if you decide to use project sites, is selecting the second option and either letting the user choose when to create their collaboration site, or, even better, having it created by a workflow as soon as the project proposal reaches a certain stage gate.

Recommendation:   

If your organization uses project sites, select the option to create them on demand rather than automatically. This speeds up the first publishing experience and avoids creating unnecessary sites and content. To configure this option, in Project Web App Settings, click Connected SharePoint Sites, and then click Settings.

PWA pages and views customizations

Page customizations

The SharePoint platform offers great customization capabilities with its modular webpart infrastructure and support for custom pages. When you add logos, custom webparts, and new themes, it might not have a significant impact on performance on an on-premises infrastructure due to the benefits of server proximity, low latency, and high bandwidth networks. However, on an online service, the story is different.

When you upload a logo or graphic with a large file size, it might slow down pages a bit on an on-premises deployment, but online, the performance hit on page loads is substantial.

The same principle applies when you add multiple webparts to a page. It might be tempting to have a custom page with multiple webparts, but unless users actually need to see the data side by side, it is better to have separate specialized pages than having it all in one place. If users only need the content of one webpart on the page, they still have to wait longer for the page to load and display the data for all the other webparts.

Recommendation:   

When you customize pages, treat your Project Online site as any regular Internet website, and create lightweight pages as much as possible.

Views customizations

Here again, simplicity goes a long way to improving page load performance. Organizations can create custom views by using multiple Project Web App pages, including Project Center, Resource Center, Tasks, and Timesheets.

The more content is displayed, the slower page rendering will be. You can reduce each page load time by a few seconds if you provide users with a greater number of simple and targeted views rather than a few "all-in-one" views.

In the examples below, the second view takes an average of 2 to 3 seconds less to load than the first one.

Example 1: An advanced Project Center view with project timeline, custom fields, and graphical indicators.

Example 2: A simple Project Center view with only a list of project names for faster navigation to individual projects.

Recommendation:   

When you configure views, offer users simple specialized views for faster navigation rather than a complex all-in-one view that would load unnecessary data most of the time.

Custom Project Detail Pages and Workflows

In addition to the recommendation provided above for page design, Project Detail Pages (PDPs) are particular in that they can trigger a recalculation of the entire project and kick off workflow actions, both of which can be expensive operations in terms of performance, depending on your customizations.

Project Online and Project Server have two main update processes for project information:

• Updates requiring a scheduling recalculation (see list below)

• Nonschedule-related fields, such as project name, description, and owner.

We recommend that you avoid updating both types of data on the same PDP to avoid triggering both update processes at the same time.

Here is a list of the most common actions that require a schedule recalculation.

• Project calendar changes

• Changes to the following date fields:

  • Start date

  • Finish date

  • Status date

  • Current date

• Changes in project custom fields

• If the project has any dependencies on deliverables

A second way to improve PDP performance is to reduce the number of webparts and custom fields displayed on each PDP. If your business processes require frequent updates to the same set of fields, create a dedicated PDP with only these fields to improve load and save time. Displaying all custom fields at all times results in a lot of unnecessary overhead.

Recommendation:   

Create lightweight specialized PDPs, and avoid mixing schedule-related and nonschedule-related updates.

Bulk custom fields updates in workflows with new REST API

Updating project custom fields values in a workflow one at a time requires a separate server request using the Set Project Field action. This results in reduced performance when updating a lot of custom fields at the same time on a high-latency, low-bandwidth network.

To solve this issue, there is a CSOM method to update custom fields in bulk. This method requires you to pass in a dictionary containing the name and values of all the custom fields you want to update.

API for provisioning project sites on-demand

Each project can have its own dedicated SharePoint site where team members can collaborate, share documents, and raise issues. These sites can be automatically created on first publish or manually created by the project manager via Project Pro or the administrator via Project Web App settings, or they can simply be disabled.

You can use the CreateProjectSite('') method to decide when to create their project sites. This is particularly useful for organizations who want to create their sites only after a project proposal reaches a specific stage in a predefined workflow, rather than on first publish. This significantly improves the performance of project creation by postponing the creation of Project sites.

OData and Reporting

By using the Project OData service, you can extract information from your Project Online instance for reporting. There are limits to the number of entities that can be returned in one query of the ProjectData service. As a result, querying a large amount of data requires multiple web requests to be sent to the service, adding network overhead and latency for each request.

For a Project Web App instance that contains a large number of entities, such as projects, assignments, or tasks, you should limit the data returned in at least one of the following ways. If you don't limit the data returned, the query can exceed the default limits and affect server performance.

• Use a $filter URL option, or use $select to limit the data.    For example, the following query filters by project start date and returns only four fields, in order of the project name:

  http://ServerName/ProjectServerName/_api/ProjectData/Projects?$filter=ProjectStartDate gt datetime'2012-01-01T00:00:00'&$orderby=ProjectName&$select=ProjectName,ProjectStartDate,ProjectFinishDate,ProjectCost

• Get an entity collection by using an association.    For example, the following query internally uses the Project_Assignments_Assignment_Project association to get all of the assignments in a specific project:

  http://ServerName/ProjectServerName/_api/ProjectData/Projects(guid'263fc8d7-427c-e111-92fc-00155d3ba208')/Assignments

• Do multiple queries to return data one page at a time, by using the $top operator and the $skip operator in a loop.    For example, the following query gets issues 11 through 20 for all projects, in order of the resource who is assigned to the issue:

  http://ServerName/ProjectServerName/_api/ProjectData/Issues?$skip=10&$top=10&$orderby=AssignedToResource

If your reporting needs still require you to extract a large amount of data, consider using the SQL Server Integration Services (SSIS) package to copy your reporting data into a SQL server database locally or in Microsoft Azure.

Recommendation:   

Trying limiting the amount of data you query at runtime by using server-side filtering, or use the SSIS package to import Project Web App reporting data into SQL Server or Microsoft Azure.

Conclusion

Project Online, like any cloud service running oon the Internet, requires specific tuning to deliver the best performance compared with an on-premises deployment.

Although we are constantly improving the system to speed up performance, there are some steps you can take in the meantime to provide a good experience to your end users.

Summary recommendation:

• Use SharePoint permission mode when possible.

• Only turn on the features you will actually use.

• Keep pages and customization as simple and lightweight as possible for faster page load times.

• Use server-side filtering or export Odata feeds data to a SQL Server database for more reporting flexibility.