Archive for the ‘Performance’ Category

Caching Server Hardware

Posted: August 26, 2013 in Configuration, Installation, Performance
Tags:
2

Several people have asked about the hardware needed for a Caching Server, or more specifically what specs need are required for the virtual machine.  I would typically break a remote office down into a few categories before making a recommendation.

You can classify remote offices in one of three categories (Small, Medium, & Large) based on number of ProjectWise users in that office. The amount of storage however may change from office to office based on the amount of files stored plus the amount of files cached from other offices.  In addition, if you are adding the Point Cloud Streaming to the server you will not want to cut corners as this adds more processing.

Remote Office

Description

Local Users

Processors

RAM

C:\Drive

D:\Drive

Small

 PW Caching Server

<30

2

4 GB RAM

60 GB

File Storage

Medium

 PW Caching Server

30 – 60

4

6 GB RAM

60 GB

File Storage

Large

 PW Caching Server

>60

6

8 GB RAM

60 GB

File Storage

EJA

To Cache or not to Cache

Posted: May 29, 2013 in Configuration, Installation, Performance
Tags: ,
2

On just about ever new deployment of ProjectWise I get the same question about Caching Servers.  “How do I know if I need a Caching Server in an office or not?”  Well, first we need to understand what a caching server does and a little more about how it will be used.

The ProjectWise Caching Server has a dual purpose.  The first is to store files that are managed by the ProjectWise system and the second is to cache files that are stored in remote offices.  A Caching Server generally would need the same processing power as a local file server and is not processor intensive. However, the addition of a Point Cloud Service can increase the need for processing power.  The Point Cloud Service is only needed on a ProjectWise Caching Server that is also the storage area for the point clouds.

For medium to larger installs, it is highly recommended that a ProjectWise Caching Server be at the same location as the ProjectWise Integration Server for performance reasons.  Having ProjectWise Caching Servers in a remote office is one of the largest decisions when determining the system architecture.  General rules for determining if an office needs a ProjectWise Caching Server include the following:

  • 10 or more users in an office that will utilize ProjectWise
  • Five or more users in an office that work on the same projects and files
  • Offices that have higher latency
  • Offices with limited bandwidth
  • Use of large files
  • When distributed storage is desired
  • When better performance is needed

In many offices that are right on the fence one way or another you may start with no Caching Server with the understanding if performance is an issue a Caching Server should be added.

EJA

Point Cloud Streaming Performance

Posted: May 1, 2013 in General, Performance
Tags: , ,
0

I wanted to follow up on a previous blog about the Point Cloud Streaming that is now available with ProjectWise.  To start off with, the streaming is available for ProjectWise Clients running MicroStation, MicroStation based applications, Navigator, Descartes.  A future release will also include a connector for AutoCAD.

To give you a good feel for expected performance we ran some test on two Point Clouds. One, a relatively small 50 MB and the other was a 1.5 GB Point Cloud.  Not that our testing should represent the performance that you would experience, but it should give you a feel for what to expect.  Here are the results that we experienced:

Standard MicroStation Download and Launch:

  • 50 MB – 3 minutes 30 seconds
  • 1.5 GB – Greater than one hour

Streaming MicroStation Launch:

  • 50 MB – 1 minute and 26 seconds
  • 1.5 GB – 1 minute and 38 seconds

EJA

Full Text Search Has Changed

Posted: April 12, 2013 in Configuration, Installation, Performance
Tags: , ,
0

With the new ProjectWise SS4 Update we have some changes that need to be considered when planning on Full Text Indexing.  First off is the fact that the Microsoft Index Server is not supported on Windows 2012 Server.  This has been our indexing engine since full text searching was introduced in ProjectWise 2004.  The update now supports both the older Microsoft Index Server on Windows Server 2008 and the new Microsoft Windows Search Server which if you are going to Windows Server 2012 is the only way to go.  The new Windows Search Server does require a SQL server and for medium to large users this may need to be a separate SQL server to meet the expected load. Performance and scalability are much better with the Windows Search Server.

EJA

Scaling of a ProjectWise System

Posted: March 12, 2013 in Performance
Tags: , , , ,
0

Since ProjectWise consists of several servers that need to work together, it is sometimes difficult to diagnose performance issues.   ProjectWise performance diagnosis usually fits into five different categories.  It is best to ensure that you have the “right size” system.  Consider the following:

  • CPU
  • File I/O
  • Network
  • Memory
  • Database

In general, most hardware has a three year life cycle around which you can plan a system.  This means that the hardware will be sufficient enough to perform with future versions of the software applications, such as the ProjectWise Integration Server, but also work with new operating systems that may be deployed over time.  In addition to the software requirements, the expected user load must be taken into consideration. Most companies that use ProjectWise will grow their usage over time.

The following chart shows how one Integration Server can be scaled to handle the load for up to 2000 connected users. It would be a best practice to include a second (or more) Integration Server, in either a cluster or network load balanced set up, to allow for failover and for spreading the load when you have more than a few hundred users or need more of a guaranteed uptime.  Keep in mind that these numbers are representative of a SELECTseries 4 Integration Server which is true 64bit.

ProjectWiseBlogIS

EJA

Latency Best Practices

Posted: March 7, 2013 in Performance
Tags: , , ,
0

Since latency has so much to do with performance I wanted to blog about the best practices that users can do to minimize the effect of latency on the user experience.  Following these simple steps in your daily routine can substantially decrease the total number of transactions with the server and therefore increase perceived performance.

  • Turn off the Preview Pane in the ProjectWise Explorer Client within high latency offices. This will limit the amount of data and transactions needed by the Client during folder and file navigation.
  • Limit the use of custom Views, only displaying the minimal amount of data about each file.
  • Limit the use of titleblock integration with AutoCAD and MicroStation.
  • Limit the amount of attributes in any Environment being used in the high latency offices.
  • Utilize Caching Server(s) where possible in the high latency offices as file storage.
  • Utilize Caching Server(s) where possible in the high latency offices as file caching.
  • Utilize Fetchfile.exe to pre-populate local file caching.
  • Refrain from exiting MicroStation or AutoCAD when opening additional files.
  • Limit the number of files in any one folder to a manageable amount.
  • Navigate by using the folder tree in ProjectWise and not selecting sub folders in the contents list.

EJA

ProjectWise Performance

Posted: March 4, 2013 in Performance
Tags: , , ,
3

This is the first of what will be many blogs about ProjectWise and Performance.  I’ll cover subjects that will help you understand what makes ProjectWise perform like a finely tuned sports car or a bus during rush hour.  The first topic to cover is latency and its effect on performance.

Much of the anticipated performance can be determined by the latency between clients and servers.  In today’s digital age, bandwidth and latency determine the speed at which you receive your data. The nice thing is that money will usually buy you more bandwidth, but when it comes to latency, that is not always the case. Latency is the measurement of the time it takes a packet of data to move back and forth. The data must go from the user interface into the kernel, out the network card, to switches, firewalls, routers, back to a network card, into the kernel, and then back through the same route. The time it takes this whole process to happen is referred to as latency. This operation may be repeated thousands of times per minute.  Therefore, a high latency returns poor performance regardless of bandwidth, which determines the amount of simultaneous packets that can be sent.

The chart below can help set expectation of performance. 

latency

In future blogs I’ll discuss ways that you can minimize the effects that latency will have on the user experience.

EJA