Can anyone direct me to a link where it spells it out as to why SolidWorks needs a "stand-alone server". Even though we have fairly descent computers, there is so much crap being added to our main server, it's like trying to run a marathon in mud!
I'm not aware of a statement requiring that for SolidWorks. it may help but it's not required. Are you sure you were not thinking about the requirement for only one PDMWorks vault per server?
As it stands, all of the companies computers are tied into one central server. Licensing, PDM and all files are on this central server. I had heard that if say engineering had it's own server, separate from the central server, not tied into all of the company's ideas for a secure network that it would speed things up considerably.
I don't beleive SW "needs" a stand-alone server. However a server dedicated for SW use would probably be beneficial, if only to remove it from the direct over-controlling clutches of some IT nazis.
I like the part about over controling IT Nazis but it seems that thier hands are tied. The problems we are having are tied to speed ie: solidworks crashes, reboot, login, restart solidworks, reopen file and by the time my file is open 45 minutes have passed since reboot. My computer has Intel Xeon CPU, 5140 @ 2.33GHz, 8 GB ram with XP Pro 64 bit system. I don't think it is our computers causing the problem.
Solidworks is installed directly on our computers.
How big are your assemblies? How many total parts? How many sub-assemblies, etc? Do you use alot of flexible assemblies?
Assembly files can be as big as 50mb +-. Sometimes we have upwards of 2000 parts mostly grouped into maybe 50 subassemblies. We do not use flexable subassemblies.
How many people at your company store all their data on that single server?
We have a 100 person company and we have 10'ish servers that run our Enterprise. Engineering has dedicated modern servers and network backbone to accomadate our needs.
A server dedicated to storing and accessing your SolidWorks server is a good idea. Your engineers and designers use the biggest chunk of bandwidth in the company most likely. You need the hardware to make that run efficiently.
I suppose I made an untrue statement when I said we were on a single server. We also have multiple servers but there are a lot of things running in the background within our network.
With that size assemblies and no flexible sub-assemblies, you should be fine using a common server. Another possiblity is in-context relations between parts. If you allow or use in-context relations, you might see alot more crashes. Where I worked before, we did not allow any incontext relations between parts due to stablity issues. Also, what version and SP are you running?
We don't use in-context relations either. We are currently using 2009 SP5.1. We have 2010 but are waiting a while, had issues with 2009 when first released.
Are you working on files that reside on the server or are the files being downloaded from the server to your computer and then opened? If your working of the server than there are many varialbles that can affect performance.
All files reside on the server. Our document control is very strict. We use PDM Enterprise. Pretty good system set up, just real slow.
It sounds like you have more a network switch and router bottleneck then. Fast servers with slow or poorly configured switches and routers; or virus software that scans everything that moves on your network can cause slowdowns.
I would check into that as well.
I thought that PDM Enterprise worked the same as PDM Workgroup; when you open or check out the file, it puts a copy on your computer. All of your work is done locally. The only time that you have to worry about the connection to the server is when you check the files out and when you check them back in. That is much different from the way some people work, where the files are all kept on a server and every time you pull up or save a file it has to go over the network.
We also have major performance issues. Once the assemblies reach about 100 to 150 parts with multiple sub assemblies we see at least 1 to 2 "crashes" per day. Some crashes are so bad that we can lose hours of design work due to Solidworks crashing on recovery of the previous files.
In my 10 plus years of designing, I have never come across a software package so unstable. We have good computers running 64 bit OS's, solidworks recommended video cards, the works.
I spent three years working on Inventor, and yes it had it's quirks, but nothing like we are experiencing now, and all I ever see on these forums and discussion boards is how we shouldn't be using tools like flexible assemblies, and in context relations. So if these are so destabilizing, then why are they available tools within the software? How long do you think I would keep my job if I told my customers that their machines have the capabilities to do everything that they need, but not to use some of them because it will cause the machine crash?
My opinion, make it right before you sell it.
What version of SW and what service pack are you running? Are you also accessing files on the network?
"How long do you think I would keep my job if I told my customers that their machines have the capabilities to do everything that they need, but not to use some of them because it will cause the machine crash?" I heay you. I am constantly telling our user that if they can avoid flexible assemblies do so because of performance issue. I will not type what their response.
We are using SW Pro 2010 x64 SP2.1, and yes we have 8 users accessing files over a network.
Are your users pulling files from the network and then working on them locally, as you would do if you were running PDMW, or are they actually working on the network files? It's the latter that causes a lot of stability problems. (Not that people working locally don't also have stability problems, but not to the same degree.)
Retrieving data ...