2 Replies Latest reply on Jan 11, 2013 2:53 PM by Jay Weigand

    Installation and performance issues PDMWE - what do you think?

    Arve Jordal

      We have been using PDMWE since 2007, in Dec 2012 we upgraded from SW2011/PDMWE2011 to 2012 SP5, Due to extreme stability issues back in 2009 and 2010, we NEVER upgrade SW or PDMWE before they reach SP5. Our vault now contains about 820.000 files consuming 400GB+ of disk space. The SQL database is close to 5 GB.

      The hardware we use is HP Blade servers, HP F/C SAN, VMWare 4.0 that runs Windows 2003/2008 virtual servers, and high performance Cisco switches. All workstations have gigabit LAN, Xeon processors, 8-16 GB RAM, SAS RAID 0 disk arrays OR SSD disks on the newest generation. We have roughly 100 employees, 32 SW/PDMWE licenses just about in constant use.


      So, Friday Dec 14th 2012 we started the PDMWE upgrade process. If we were to follow SolidWorks' plan/recommendation, we would firstly need to run a complete backup of the entire vault. A completet backup of the Archive server takes 7 hours, so that would mean losing the entire Friday as a working day, just to get a complete backup. The backup to tape copies 996 MB/min from the archive server. In comparison the backup of a normal data volume is copied at 3.981 MB/min.


      Generally we feel that performance is rather poor. We have some huge directories, and the ineffiency of the NTFS file system with thousands of tiny files really slows things down. In our opinion the PDMWE design is unsuitable for large vaults.


      Now, losing a full day of productions costs roughly 200USD per hour per employee (what we would expect to bill our customers), about 60 employees would be directly impacted, so 200x8x60 means that would cost us USD 96.000,-. We could not let the users work during the day, as the backup then would be useless.....

      Our organization is a 360 days a year operation, which means that even during weekends 10-15 people will expect to be able to work at any time. Shutting down CAD for the weekdend means that we lose at least 80 hours, ie 80 x 200 = 16.000 USD.

      We have complained to SolidWorks about this extermely demanding and costly upgrade process for 3 years, with no result.


      On Friday afternoon we closed down the systems, and started the actual upgrade. This is pretty straightforward until you need to run the "Upgrade.exe" that basically runs a lot of scripts to update the SQL database. That job runs for hours, with no indication of actually doing anything, so we believed that the process was hanging so after a long time we killed it. Restarted and found that we could tell that the SQL server was actually doing something. Finally, after more than two hours with nothing, the Upgrade.exe finished successfully. The next step was then to upgrade the PDMWE software on a workstation, and then run the File Version Upgrade Tool (FVUT) to upgrade the actual files to 2012 format.


      Now, we have been through all of this several times before. We even have a separate test enviroment that we use specifically to preprare for version upgrades like this. So, we had tested and experimented with FVUT to ensure that we would get the optimal result.  The test vault is however only 10% of the production vault.
      Job # 1 - generate work instructions for the 14 workstations we planned to use. We had decided to run FVUT a number of times, splitting the work into 4 separate parts so that we would have some control over what was updated, and in the correct priority. The task of generating the work instructions was actually started on Saturday Dec 15th at 10.43. At 16:22 the same day (yes, almost 6 hours later), the FVUT had generated the work instructions, and we were ready to proceed. As you probably can guess, we were rather pessimistic about the progress.....


      We initiated the workstations with the work instructions and waited.....

      On Sunday morning the one workstation was ready to proceed, displaying the cheerful dialog "Hit Enter to start upgrading files...."

      Is it possible to conceive what that guy who wrote this software, or the people who approved it, were thinking when they require interactive input - namely hitting ENTER!!! - when running a batch job that has been processing for a number of hours??? HOW THICK CAN YO GET???


      So, we aborted the FVUT and swore that this would be our last attempt to upgrade PDMWE - ever. The rest of Sunday was spent on the replicated vaults, preparing images for remote users in other departments and other useful work. Now, every time a user updates any kind of CAD file, the check-in takes even longer than usual, because of the way SolidWorks updates files on major revisions.


      We are now going to evaluate other PDM solutions.

      Are there anyone else with large vaults who wants to share their thoughts and experiences?

        • Re: Installation and performance issues PDMWE - what do you think?
          Kip Speck



          Sorry to hear about your woes with EPDM, we have used it in environments that are equally as large or larger without real issues.  Sure there are some things we would like to have run better, but as compared to other systems EPDM has been the best choice.


          If you are putting thousands of files in a directory, this is a bad design and should have been setup differntly.  Windows itself does not like to have more than 2k files in a folder without a performance hit.  Sice EPDM is folder based you would have the same limitations.  I would suggest rethinking your folder structure strategy.


          As for the EPDM upgrade process of the Databse I know there is a dialoge telling you what is happening,.


          As for the SolidWorks file upgrade tool, I too believe this is a poorly designed interface.  But..  When you think of everything that has to happen to correctly open and save every Version of a file, this is a massive undertaking.  Each version has it's on variable values, references, history etc... it is not just opening and saving the file.  It has to get every version of every refernced part that it was built with.  I would expect it to take a very long time to do properly.


          We have choosen to onloy do the File Upgrade an versions that have Core functionality changes, i.e. 2013.  This way we do not go thruogh this too often and it is an acceptable pain.


          **If there are performance issues with the DB I know that SolidWorks has been very responsive to supporting customers.  Contacct your VAR and have them push the issue.



          Again, Sorry that you are having so much pain.

          • Re: Installation and performance issues PDMWE - what do you think?
            Jay Weigand

            ePDM from the user experience is built in windows explorer.  If you have thousands of files in a single directory your performance will suffer.


            When considering upgrades, you can get a copy of the database on a test system (without physical files) and test the upgrade database piece separate to see how long it takes ahead of time AND to find out if it will process successfully.  I recently did an upgrade all the way from 2006 to 2012 and if I had not run the test of the database upgrade I would have not found the problem until it was too late.


            On that upgrade what I found to be a problem was they had alot of files that were in the recycle bin for ePDM and never deleted.  After destroying the files from the recycle bin the database upgrade was successful.


            When upgrading the database, it WILL appear to be not responding.  Please do not stop it.  It is still doing some processing if you look at the actual processes itself.   Stopping this process as you know will cause great pain in having to restore and redo things.


            I agree with Kip that the tool(s) provided for upgrading files are not great and there are many variations on how you can run them.  I would suggest doing searches on SPR's before you use any upgrade tools to the latest versions.


            If you are having performance issues, share with your var what it is that is slower and you can track things down.   The SQL backbone should be very efficient to do searches etc.   If you do have thousands of files in a single folder, you are running into limitations of plain windows itself.   On the SQL side do you have the various things loaded on different PHYSICAL drives (e.g. database on a different physical drive than the LOG file).  Having things on different virtual drives doesn't help performance if there is only one head to write everything anyway.  


            Hopefully this helps you.   Jay