There could be many things at play here. no, you're not only working with local cache. (you always rely on SQL connection, take #2 below for example)
Is this purely anecdotal evidence? Is so, try to collect data from users i.e. how slow is slow? how fast should it be? what exactly is being "slow"? when is it slow? is it ever not slow? what are the steps to recreate the issue and recreate when it's not slow? etc..
Then run the list below. ordered from least involved to most. test by asking those same questions again and compare the data. you want to find a case that this is reproducible on demand, then make modifications looking for improvement from original data. otherwise, with anecdotes, you will be chasing this one for a long time.
1) turn off PDM add-in in SolidWorks. any difference?
2) with PDM add-in back on, try unchecking settings in image 1. any difference? how about image 2? (these keep a recurring connection to SQL)
3) Any system resources at the server side that may need additional allocation i.e. more RAM for SQL buffer pull? any difference after increasing system resources?
4) do they use library-based file sets for their designs (like toolbox) and are those in a network drive? what if you move those external references to PDM?
5) ask your reseller to run the PDM status report tool for analysis. make adjustments and compare against collected data from users.
6) perform an SQL trace during the suspected event (mass check-in) seeing tens of millions of reads? if not sure what I'm talking about, call your reseller.
7) if 6 is true, can your folks stop doing that? (some companies can) Try small batches at a time when checking in. AND why are they checking out such large assemblies and their components? is it truly necessary for your company? any difference against collected user data after stopping the mass check-ins for a bit? **don't get me wrong, mass check-ins are OK... as long as you have "beefy" system resources, network throughput, optimized settings, and patience - understand what it all entails when checking in a lot of files.** If the SQL buffer pool is taken up by all the information dealing with the mass check-in, think of what that does for the information that was in the buffer pool for the other folks - food for thought.
8) also you don't happen to have virtual components, aka internal components, in these large assemblies, do you? there are common issues with these, try saving them out as external files into PDM. Remember that PDM is for managing files and an assembly is not intended as a data management solution.
Like I said it can be many things at play and maybe even compounding the issue. if the list above does not solve it, you would at least gotten to learn more about the particular problem your company is experiencing to make your own list of things to check.
Francisco | CSWS-DMA
Image 1 (solidworks > tools > PDM)
thanks for this. the first thing i tried when this was happining was to disable the pdm add-in and that did help.
i will move on to trying step 2 hopefully today
How do they know that the server is experiencing heavy loads? Did they check the large amounts of files in on their machine?
Do they see the issue the same when they check the files in from the SolidWorks Add-in as they do when they check them in with Windows Explorer?
Joel Seerey wrote:
some of my users are reporting that when the pdm server is experiencing heavy loads (large quantities of files being checked in) they are experiencing slow response from solidworks on their local computers. it was my understanding that when a file was opened from pdm you were accessing a local copy and that you only interacted with pdm when checking in/out or state changes.
why would server load effect models that are already open?
Because the PDM task pane is frequently talking to the PDM database server. Checking in/out files involves a lot of database activity as well.
To test this, simply have your users disable the PDM add-in in SOLIDWORKS and see if SOLIDWORKS performance improves.