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 DriveWorks. To 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 ma