Recent studies have found that when it comes to how long users are willing to wait for their interactions with a software, they’re not. There’s no way to determine what a reasonable refresh time is because you don’t have reasonable users. So all that we can do is look at the components of the DriveWorks implementation and optimize as many of the steps as we can. 

The first performance tip is fairly easy, spend more money. Not a great, or reasonable thing to ask, but it’s a fact. The faster your machine runs, the faster DriveWorks will run. Surprisingly enough, the Internet contains a considerable amount of opinion and information about which hardware is superior for what applications. With the immensely rapid changes in technology and product availability, it would be imprudent for me to even address specific hardware. A chat with a friendly reseller or hardware vendor or a handy search should give you the information that you need, but the information that you want will be based upon the specific requirements of each piece of DriveWorks. Let’s understand what DriveWorks needs so that you can spend your money accordingly.  

Tip #1 Autopilot

From a hardware perspective, DriveWorks Autopilot is one of the most misunderstood components. DriveWorks stopped using the S-word to describe Autopilot because Autopilot really isn’t a Server application. It’s important to note that Autopilot can be used for two purposes, and they perform very different tasks. The DriveWorks Model Generation Server is the old name, and that hints at the primary use for Autopilot, driving SOLIDWORKS. To this end, when Autopilot is being used to generate models, then you want a computer optimized to run SOLIDWORKS. Aside from the SOLIDWORKS-specific hardware, the best things that you can do are to make sure that all your SOLIDWORKS files are close-by, preferably on the same machine. SOLIDWORKS works fastest when it does not have to read or write over a network. That means your DriveWorks master models, your output model and drawing locations, and any models referenced by your assemblies. And if you’re using PLM, this means that you want to try to cache a latest version of your models on the Autopilot machine. The DriveWorks EPDM plugin will fetch the latest models for you each time you go to generate, but that takes time. 

Tip #2 Strip Down SOLIDWORKS

Another SOLIDWORKS tip is to strip down SOLIDWORKS as much as you can. A whole slew of add-ins are typically loaded every time that SOLIDWORKS starts. Shut off, or even uninstall, as many add-ins as you can. Unless you are integrating with CAM or rendering or analysis, there’s no reason to load those add-ins. In some cases, something as simple as switching to wireframe mode and removing screen backgrounds can squeeze out a little performance for you. But since opening SOLIDWORKS and SOLIDWORKS documents is one of the most time-consuming steps, try to make your master models as optimal as possible. Think what you can do to get your models in the simplest form to open the fastest, from suppressing features and components in your master model or using large assembly mode or other SOLIDWORKS techniques. Intelligent design of your master model is very key to how it performs…but that’s another article. 

Autopilot can also be used to run specification tasks. This is significantly different than running SOLIDWORKS, because this could involve generating output documents in Word or Excel, exporting information to SQL, or processing the DriveWorks specification. These requirements are significantly different from SOLIDWORKS, and while your Autopilot is performing these steps, it cannot be generating models. One solution to this is to have one Autopilot server processing specifications, and another Autopilot workstation generating models and drawings. The Autopilot Settings dialog allows you to tell each Autopilot if it will be processing specifications or not, and whether it will be generating SOLIDWORKS documents or not, and even whether it will serve 3D Preview or not. Splitting these tasks is a great way, albeit more expensive way, to get more performance. It is nice to note that the machine for processing specifications does not have nearly the hardware requirements that a SOLIDWORKS Autopilot will. 

The remaining components are fairly straightforward. Your DriveWorks shared group requires an SQL database, and this machine is important. Finding the best server to run SQL Server and optimizing SQL are topics that are extensively documented elsewhere, and I’ve even presented that material at DriveWorks World and there may even be articles on the Razorleaf web site on SQL tuning and SQL for DriveWorksTo go along with the SQL Server, the DriveWorks Server Service (most often run on the SQL Server machine) is the key to all communications throughout your DriveWorks architecture. So having it communicate with the SQL Server quickly by being on the same machine is helpful, but also keep in mind that it will talk to DriveWorks Live and DriveWorks Autopilot. The quality and speed and reliability of your network connectivity between these is very important. 

Tip #3 Set up DriveWorks Live Server Right

The DriveWorks Live server is a web server whose configuration might depend upon the amount of graphics and downloads in your implementation. Your hardware vendor will be happy to help you configure a web server, but it’s important to let them know if this machine is going to be constantly passing 3D Preview models to the user, or if the user is going to have a 3TB library of PDF, JPEG, IGES, STL, and other files to download. These factors can affect your performance in a variety of ways. A lot of performance is based on the design of your forms and only presenting the information and graphics that you need to present. The more that the user’s browser has to download, the slower it will be. And if the form changes with every keystroke, that will more often provide a less favorable experience than requiring the user to click a button after entering in a value or series of values.  

And here is your bonus tip for the day

As we mentioned with the Autopilot, opening and saving and closing files is often a large source of performance degradation. You can get rid of some of the lag through attention to your I/O. Keep your files in smart places, so they don’t need to go over the network. Use solid state drives. Creative partitioning to put different types of data on different physical drives. But here is one situation that I see fairly often. Due to the heightened security required for the sick, sad world in which we live, very often every file that is opened or saved or copied has to be scanned by an anti-virus application before it can be used. Razorleaf has found on several occasions that we can significantly increase performance by kindly asking the anti-virus program to provide exceptions for certain file types. An Autopilot that has exceptions for SOLIDWORKS documents will open and save those documents faster. Every new specification begins with a DriveWorks project file being copied and a drivespec file being created, then opened. Putting anti-virus exceptions on these file types can provide significant performance benefits as well. Likewise, trusted locations, like your images folder, can ensure that anti-virus does not slow down these files, either. PLEASE work with your IT professionals to ensure that you are not endangering your company’s or your clients’ security in the process. 

There are a lot of techniques that we can use to tune the performance of our DriveWorks implementations. But it starts with understanding what tasks you are asking each piece of your implementation to perform. Once you understand, and intelligently segment that, then you can optimize each area to perform that task. Each task deserves its own attention, and I am very confident that you will see more articles on this very subject. In the meantime, let us know what you’ve done to boost your performance and make the experience better for your DriveWorks users in the comments section below.