Drawings so slow they are unusable.

LKRENZLER

This is not the first time I've brought this up but since I'm forced to sit here and do nothing while waiting for Onshape servers I'll bring it up again.  Drawing performance is beyond pathetic.  We've checked into all possible causes including our ISP but this is clearly a server issue.  While waiting for drawings to update there is no network traffic (all other traffic is very fast) so NOT a network issue.

It's clear you're using slow servers because they're cheap but if you keep doing that you're going to lose clients.  I know one little shop like ours is no concern but I bet there are a lot more of us who feel the same.

By the way, STILL waiting for a drawing to update...and it's not complex.

LKRENZLER

Since I have MORE time to sit here, I'll comment further.  I bet most run of the mill server CPU's are around 2.5Ghz with very low single thread performance.  Onshape drawing code is probably single threaded.  So we're waiting for one lonely, rather slow CPU to do it's job.  I'm guessing two things need to happen.  One, properly multi-thread your drawing code.  Two, run on high performance servers with good CPU speeds that are not competing with Christmas shopping orders on Amazon or the likes.  Am I wrong?

lougallo

@LKRENZLER Sorry you are seeing this performance but the issue is not the service and we have ways to look at the data, your connection and other variables and try to pinpoint what is happening. I see you have a ticket with our team and we will start investigating.

dirk_van_der_vaart

@LKRENZLER
What is your location and which server are you using?, eu-west ?

LKRENZLER

We're in Calgary and using west servers.

LKRENZLER

Sorry Lou, I just don't buy that.  This really does seem like an Onshape software/server issue that needs attention.  Just blaming our connection is not going to solve it.  Our connection is fine to everything else in the world.  Onshape is clearly waiting for server processing (ei. no network traffic) when trying to work on drawings.  Am I right guessing that drawing code is single thread?

AaronS

@LKRENZLER @lougallo
Have you found a fix regarding this issue? I'm currently experiencing the same thing. Load times for drawings are extremely slow. It's borderline unacceptable. Load times are fine for smaller assemblies, but even on medium-sized assemblies the load times shoot through the roof. I am using a high end Boxx machine, along with a 100+ Mbps connection, so I know for sure nothing is wrong on my end.

ilya_baran

@Design1, sorry you're having performance troubles.  If you haven't already, please file a support ticket.  Slowness could be caused by a hundred different things (some with the connection, some with the service) and there is no way to determine what's going on from a forum post.  Chances are it's not the same issue as the original poster, even if the symptoms are similar.

Engineering_Team

Did this ever get resolved in any way? We have been suffering from similar issues as of late and it is hindering project mocement.

NeilCooke

Engineering_Team said:

Did this ever get resolved in any way? We have been suffering from similar issues as of late and it is hindering project mocement.

Please open a support ticket with more details and share the doc so we can investigate, thanks.

Frank_Bertucci

I feel like I'm starting to dread having a big drawing set to do. If it's just a couple drawings no issue, but as soon as I start working on about 5 or so and jumping back and forth it's a pretty sure bet I'm going to have issues. Crashes, page unresponsive, broken references, long load times etc. Larger assemblies really bog things down too, then add the release process....

It is surprising given how fluid and robust the part and assembly studios are. I'm not going to pretend to understand the technical reasons behind this but as a user I do want this to at least be more stable if faster is not an option.

nick_papageorge_dayjob

Recommend moving drawings to their own document (separate from the part/asm), or if within the same document, have them reference a version. If you are not already doing that, you should see good improvements in speed once you do.

KyberNexus42

I'm having this exact same problem: doing literally anything in a sketch, whether that be placing down an unconstrained point or performing an offset, it takes up to a minute, goodness forbid I mess up and have to press ctrl-z. I end up dreading and putting off working on projects because I hate just sitting there staring at a spinning circle because I mis-clicked something. Every other action (extrudes, revolves, making new planes, usually transforms, etc.) runs as quickly as it should for a 200 feature part studio, and as mentioned before there is no measured send/receive activity on my network. I've done basically everything I could think of to try to force onshape to use my local resources, which would be more than sufficient to place a dot on a plane, but it seems as though that only made my pc just render the in-app frames (which it should already be doing, and I say this because I only see GPU or CPU usage spike when I quickly spin around the model, in any project file, not when I make it model a complex loft. Though please correct me if I'm wrong about the frames or whatever that is) and do none of the calculations. As a personal/educational user this is beyond infuriating, so I can't imagine what it must be like for an entire shop to be sitting in silence for minutes on end while they wait for their complex sketches to load. The only solution I've found is to put on a good audiobook and stare at my screen for 3 hours to get the same amount of work done that should have taken 30 minutes.

I don't even know if I should waste the effort to make a support ticket only to be told that onshape is just "operating as intended". Please oh PLEASE just add a toggle switch that lets us use solely local resources to complete calculations and rendering. Make it a one time fee if you have to but just please do something.

KyberNexus42

So update about my own issue, which I might actually make my own post about, but I thought I'd first post here for anyone looking for answers: it seems that only sketches based on planes of imported (from my PC) STL mesh models that have been modified to contain planes upon which sketches can be based (so if the STL has been cut apart in some way with a Split operation using a plane created in the part studio) suffer from the extremely long load times that I previously described. I tried making a couple new sketches using other parts' faces that were solely created in that same part studio, and I'm having no more lag than I'd expect while editing those sketches while in a part studio that has a bit over 200 features.

NeilCooke

@KyberNexus42 none of your docs are public because you are using an EDU account (with over 600 hours of usage). Please make it public or share with support if you have concerns.