Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:

  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Performance test results

13»

Comments

  • Jake_RosenfeldJake_Rosenfeld Moderator, Onshape Employees, Developers Posts: 1,253
    edited August 2018
    @gkuhns @john_mcclary

    The GPU is definitely the most important piece of hardware for interactive performance in Onshape.  The largest piece of work that your CPU does is taking the graphical information from the server, unpacking it, and shuttling it over to the GPU.  One example of a case where a better GPU may make a difference is if you open a very complicated assembly after not opening it for a while.  Your CPU will receive all the graphical data for this model and then have to process it for viewing.  So, a better CPU will improve time-to-first-frame (a.k.a. the time it takes between opening the model and when it is displayed on screen).  Once it is displayed on screen, though, the CPU usually has negligible affect on the interactive performance (framerate when panning-rotating-zooming, or creating section views) compared to the GPU. In cases of very complicated assemblies, the CPU can start to have a noticable affect on interactive performance.

    Your CPU will have incremental performance gains/losses at any time when new graphical data is introduced.  Another example is when editing a feature in a part studio.  The CPU may have some very marginal effect on how long it takes to see the change when a parameter is changed (a vast majority of this time comes from calculating the actual geometric change on our side, though.  The affect of the CPU here is marginal at worst, and negligible in practice).

    @gkuhns It seems that you have nice hardware.  Are you experiencing performance problems?  We are happy to help diagnose them.
    Jake Rosenfeld - Modeling Team
  • john_mcclaryjohn_mcclary Member, Developers Posts: 1,536 PRO
    @Jake_Rosenfeld thanks for that bare metal insight. That helps paint a good picture of the system and will help when building our next computer upgrades
  • michael3424michael3424 Member Posts: 472 ✭✭✭
    @gkuhns @john_mcclary

    The GPU is definitely the most important piece of hardware for interactive performance in Onshape.  
    So what is a good GPU to get?  Is the NVidia Quadro lineup of cards any better than their game-oriented cards for apps like Onshape?
  • EvanEvan Onshape Employees Posts: 48
    edited August 2018
    "Professional" grade cards, like Quadros, will not give you a significant performance increase with Onshape.  So you tend to get the most value with a "game-oriented" card.  The specific card that you choose could depend on your model complexity, screen resolution, and how much your willing to spend. 

    Simple part studios and assemblies can typically be rendered around 60 fps (the browser limit) with a relatively modest GPU.  As the amount of data in the tab increases, as does the GPU workload.  So, for example, if you are loading assemblies with thousands of components consisting of millions of triangles, you may want to invest in a GPU with a higher number of shader cores and more memory.

    Screen resolution will also impact performance.  As display density increase, so does the demand on the GPU.  For instance, running a 4K display at native resolution will require storing and shading more pixels than a 1080p display.  So if you have a higher resolution display, you may want to consider a beefier GPU.

    Here are some top-reviewed options in different categories:
    https://www.tomshardware.com/reviews/best-gpus,4380.html
  • Don_Van_ZileDon_Van_Zile Member Posts: 195 PRO

    @even This is good information to know and should save users money thinking they require a Quadros for better performance. Many users held this belief that a Quadros card would improve performance (Pan, Zoom, Rotate etc..) using SW for many years which is false.
  • brett_heliesbrett_helies Member Posts: 1
    Browser seems to make quite a difference. On the same PC (i7 2600K @ 3.4GHz, GTX 670 2GB, 24GB RAM, Samsung EVO 840 SSD) at 2560x1200 resolution I get very different results with different browsers.

    Edge:  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299
    Measured triangles per second  144.9 million
    Measured lines per second        86.4 million

    Firefox:  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
    Measured triangles per second  159.0 million
    Measured lines per second        137.8 million

    Chrome: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
    Measured triangles per second  663.9 million
    Measured lines per second       177.1 million

    Guess I should be using Chrome then.
  • EvanEvan Onshape Employees Posts: 48
    @brett_helies - we do find that Chrome tends to be more efficient for real-time rendering than Firefox.  However, I would not expect to see such a large difference in results between the two.  You may want to run the test again in Chrome.  (One issue that is known to cause spurious results in Chrome is: if the rendering test goes off screen somehow.  In that case Chrome will "helpfully" skip all the work to do the rendering, which makes things appear much more efficient than they are in real world situations!)

    One caveat to Chrome being the faster renderer: Chrome's per-tab memory limit is significantly lower than 64-bit Firefox.  So if you are loading very large assemblies, we will hold back display data to keep Chrome under the limit.  This should help maintain interactive performance in Chrome, but it comes at the cost of having to occasionally swap data in and out, which does have an interactive penalty.  That said, for a typical model, everything will fit into Chrome's memory allotment.
  • daniel_cookdaniel_cook Member Posts: 40 PRO
    Evan said:
    @brett_helies - we do find that Chrome tends to be more efficient for real-time rendering than Firefox.  However, I would not expect to see such a large difference in results between the two.  You may want to run the test again in Chrome.  (One issue that is known to cause spurious results in Chrome is: if the rendering test goes off screen somehow.  In that case Chrome will "helpfully" skip all the work to do the rendering, which makes things appear much more efficient than they are in real world situations!)

    One caveat to Chrome being the faster renderer: Chrome's per-tab memory limit is significantly lower than 64-bit Firefox.  So if you are loading very large assemblies, we will hold back display data to keep Chrome under the limit.  This should help maintain interactive performance in Chrome, but it comes at the cost of having to occasionally swap data in and out, which does have an interactive penalty.  That said, for a typical model, everything will fit into Chrome's memory allotment.
    Hi Evan,

    I have a question specifically about your comment re: per tab memory usage in Chrome. I am 100% using 64-bit Chrome and previously when using some of my larger models I could easily reach 3-4GB+ memory in a Chrome tab and the model would load perfectly fine. This exact model used to drive system ram to about 10GB utilisation. Now Onshape is really struggling to load these models and I see that Chrome is bouncing between 1.5 - 2.0 GB for the tab. Generally the model never finishes loading at all. Attached is a screenshot of my memory monitor.



    You can also see the CPU bouncing up and down (Core i7-6700HQ). I am just wondering if holding back data to keep Chrome under the tab memory limit is a new thing or it's always been there and I need to look for another issue?

    Thanks!
  • EvanEvan Onshape Employees Posts: 48
    @daniel_cook - memory metering on Chrome has been in for several months. Though we will unload graphics for some parts, the model should finish loading. (That spinner should go away.)  Currently we only do metering for assemblies.  Part studios should load all parts (which can cause issues in Chrome).

    I would suggest that you try loading your model in Firefox to see if it performs better.  If you continue to experience issues, please reach out to support through the "Feedback" option under the help dropdown.


  • brian_bradybrian_brady Member, Developers Posts: 367 EDU
    I tested my lowly 2014 MacBook Air (8GB RAM and Intel HD 5000 graphics) today using both Chrome and Safari. I was surprised to learn that Safari performed better; about a 20% increase in triangles per second and about a 60% increase in lines per second. Neither case was what anyone would mistake as speedy. I usually use Safari because I like it better and thought it felt speedier, now I have proof.

    GL renderer   Intel HD Graphics 5000 OpenGL Engine

    Measured triangles per second   115.9 million
    Measured lines per second   46.7 million

  • bill_danielsbill_daniels Member Posts: 246 ✭✭✭
    Interesting thread.  It prompted me to do a non-scientific test by launching Ubuntu System Monitor and Nvidia X-Server utility.  I have an 8 processor (Xeon) system with 32G, 4G GTX 1050 Ti GPU and cable internet. 

    A very large assembly (1,221 Instances with may parts using best tessellation) loaded at the usual 5 minutes with Firefox with all CPU processors bouncing around between 10% and 100% utilization.  Once loaded, spinning this huge assembly around with the mouse showed 20-60 FPS with no more than 37% GPU utilization and 18% graphics memory utilization.  CPU utilization was the usual erratic shifting of work between CPU's with only one at a time running at 100%.  To my untrained eye, it looks like getting all CPU cores sharing the load more equally would help a lot.
  • 3dcad3dcad Member, OS Professional, Mentor Posts: 2,376 PRO
    I have seen noticeable difference on load times depending on time of the day. I suppose it depends on server loads and shared resources.
    Please correct me if I'm wrong and it's just my biological clock that makes load times feel different =)  
    //rami
  • daniel_cookdaniel_cook Member Posts: 40 PRO
    Evan said:
    @daniel_cook - memory metering on Chrome has been in for several months. Though we will unload graphics for some parts, the model should finish loading. (That spinner should go away.)  Currently we only do metering for assemblies.  Part studios should load all parts (which can cause issues in Chrome).

    I would suggest that you try loading your model in Firefox to see if it performs better.  If you continue to experience issues, please reach out to support through the "Feedback" option under the help dropdown.


    @Evan - I got back to my normal workstation and tried it again in Chrome - and you are right it did eventually load after maybe 5-7 minutes and several "timeout warnings" from Chrome.

    Tried the same model in Firefox and it loaded faster and used more "per tab" memory (checked the process memory usage) - all which I suspected would happen. My only gripe is that on large assemblies Firefox is just nowhere near as fast as Chrome but this isn't an Onshape issue.

    FYI - the model has 1,340 unique parts and 3,934 part occurrences.
  • john_mcclaryjohn_mcclary Member, Developers Posts: 1,536 PRO
    I also have a large model I have imported. I haven't managed to open the document without chrome crashing, on the other hand Firefox opened it within a minute. I'm starting to consider switch back over to Firefox after seeing other odd behaviors that are present in chrome but not in Firefox. 
  • john_rousseaujohn_rousseau Member, Onshape Employees, Developers Posts: 243
    Hi @3dcad. Can you give me the model ID and an example time when it was slow? We hear this complaint from time to time, but it's not generalized enough to diagnose. Our servers are automatically auto-scaled and should not be the problem. It's possible that it's the network near you.

    We've been working with some new performance monitoring tools and I'd like to see if I can pin this down.
    John Rousseau / Director, Technical Operations / Onshape Inc.
  • Don_Van_ZileDon_Van_Zile Member Posts: 195 PRO


    We've been working with some new performance monitoring tools and I'd like to see if I can pin this down.
    Will any of these in-house tools be considered to the public or packaged within Onshape in the future (potentially)?
  • john_rousseaujohn_rousseau Member, Onshape Employees, Developers Posts: 243
    These tools allow reporting from multiple places in the processing pipeline. This includes the client code in the browser and all server-side code. We are also looking into providing more, customer-visible performance tools to help diagnose hardware or network problems. Unfortunately, it's easy to mis-diagnose problems and we don't want to tell customers to get a new GPU or internet provider and find that doesn't provide any benefit. Stay tuned.
    John Rousseau / Director, Technical Operations / Onshape Inc.
  • Don_Van_ZileDon_Van_Zile Member Posts: 195 PRO

    Thanks for the feedback @john_rousseau
  • 3dcad3dcad Member, OS Professional, Mentor Posts: 2,376 PRO
    @john_rousseau
    I will put in ticket next time. 

    There's another factor too, when you try to show off something to a colleague/friend/customer it always makes things slow or even crash. Just like when your on phone and need to look some data it makes your whole computer freeze until you put off your phone. I'm not sure if it's about God or position of the Moon, need to run some more tests..  ;)
    //rami
  • john_mcclaryjohn_mcclary Member, Developers Posts: 1,536 PRO
    That's what you get for mooning God
13»
Sign In or Register to comment.