Skip to main content
D
17-Peridot
Dobi17-Peridot
17-Peridot
October 6, 2022
Question

Dedicated publishing queues for large files/assemblies

  • October 6, 2022
  • 5 replies
  • 8189 views

Is there a way distribute publish jobs to queues based on size so that they could go to dedicated (and more capable) workers? 

5 replies

A
Ajit_Kulkarni16-Pearl
16-Pearl
October 6, 2022

Hi Dobi,

 

Very simple question , how you can decide the size before publishing the job ?

Do you have more capable and less capable workers ? 

 

You can have separate CAD Workers for High , medium and low priority job. You will need customization to change the priorities of the job. 

 

Below article will help you in understanding job priorities. 

 

https://www.ptc.com/en/support/article/CS28472

https://www.ptc.com/en/support/article/cs149619?source=ArticleViewerRelated

 

 

Regards

Ajit 

 

D
17-Peridot
Dobi17-PeridotAuthor
17-Peridot
October 6, 2022

Hi Ajit, 

 

For example let's say that I have 3 jobs going to workers: one is a single part (say a cylinder), one is a drawing of said cylinder and a third is an assembly of 300 parts. Is there a way to send the part and drawing to one queue while the assembly goes to a different queue? At point of publish rules being triggered, Windchill knows what is going into the queues (and to which queue based on source and type). Can size (either file size or assembly size by virtue of BOM size) be used to separate the files? 

 

As far as more or less capable workers: if we have a VM with limited resources and a workstation with high resources there is a way to dedicate workers to queues. The sizing question comes into play because I'd want to be able to send my large jobs to the more capable worker while the smaller jobs go to the limited resource workers. 

 

Dobi

    J
    jlecoz15-Moonstone
    15-Moonstone
    October 7, 2022

    Size is not an obvious criteria for CAD.

     

    If you have a drawing of a part or if you have a drawing of a top-level assembly it is still a drawing the drawing file size may be similar, but the conversion CPU and workload will greatly differ.

     

    This is because opening and converting the assembly drawing will take much more time as all dependencies will have to be downloaded and loaded in a CAD session managed by the CAD worker..

     

    If you are experiencing performance issues when converting large assemblies you can explore other approaches to improve this. For example, using positioning assemblies.

    HelesicPetr
    22-Sapphire II
    HelesicPetr22-Sapphire II
    22-Sapphire II
    October 7, 2022

    Hi @jlecoz 

     

    The point of size is about BOM size not file size 😄

    also drawing can be checked against ASM and if the asm is huge send it to the dedicated queue.. 

    (sure I'm talking about customization...)

     

    PetrH

    joe_morton
    18-Opal
    joe_morton18-Opal
    18-Opal
    October 10, 2022

    This exact topic came up in the PTC/User conference last week (maybe you were in the room and this is a follow-up?). One admin in the room said that his company had achieved this, but I'm not sure how. It does seem to be possible though.

     

    We have a dedicated workers for drawings and models, but we haven't gone down the route of trying to divide by complexity. 

      D
      17-Peridot
      Dobi17-PeridotAuthor
      17-Peridot
      October 10, 2022

      Alas, I wasn't there last week. I'd love to know the how. 

       

      Even separating 2D from 3D is beneficial I think. Did you go down the route of custom filters and queues through these methods: CS80629 and CS132318 ?

      J
      jlecoz15-Moonstone
      15-Moonstone
      October 11, 2022

      Dobi,

       

      Use the  filter method publish.publishqueue.priorities.filtermethod described in CS132318

       

      This is a good approach using filtering methods it is generally some of the easiest, The inputs and outputs are well defined.


      Using filter is upgrade safe as the filters are never modifying or altering any of the OOTB code, and code to be written should reasonably simple.

        D
        18-Opal
        d_graham18-Opal
        18-Opal
        October 11, 2022

        @Dobi 

        You should be able to direct a publishing job to the desired publishing queue with a listener.

         

        If you have a threshold for the assembly size (number of components) code could be written that is automatically fired which gets the number of components in the assembly. If the number is greater than or equal to your threshold the job would be moved to the appropriate publishing queue when it is moved from the H, M or L publishing queue.

          T
          23-Emerald IV
          TomU23-Emerald IV
          23-Emerald IV
          November 2, 2022

          There were presentations at past PTC/USER events where other customers did something similar.  Usually it required something to be done in the CAD software (Creo) to indicate which assemblies were considered 'Large' and then use that information during publishing to route to the appropriate worker.

           

          The better solution (in my opinion) is to switch all assembly publishing to extended positioning assemblies and completely eliminate the delay that  traditional publishing causes.

           

          I switched all of our assembly publishing to extended positioning assemblies many years ago and I would never want to go back.  Attached are a couple of presentations from 2013 where John Deere and Paccar both made the switch.  JLG had a similar presentation in 2014.

            D
            17-Peridot
            Dobi17-PeridotAuthor
            17-Peridot
            November 2, 2022

            This is helpful, @TomU ! I think we're doing positioning assemblies across the board but will go back through the settings to confirm. 

             

            What I'm getting out of the Paccar PDF (and some more digging into our data) is perhaps some settings that may have gone amiss in setting up the workers in the cloud. The conversion of a file (large or small) takes a smaller percentage of time than the overall publish duration (in my case defined as the time spent in the worker). The download of data from the server to the worker is non-trivial, taking as much as 90%+ of the total job duration. For a whole truck model at Paccar it seems to be instant. I've had a dowel pin take 3 minutes...

             

            So perhaps my question is morphing more into how do I get the VM settings right so that my download times are reasonable irrespective of job side. 

            J
            jlecoz15-Moonstone
            15-Moonstone
            November 8, 2022

            Hi Dobi,

            Taking 3 mins for a dowel pin publication shows a performance issue.

             

            I don't know your number of users and the architecture of your system, so my advice may not fit. But to investigate such an issue you always need to have a performance baseline.

             

            To get a performance baseline I would test to relocate the worker on a Windchill test server and allocate processor or memory to it to cope with this. And then try your dowel pin conversion. From there you can look at the job summary and compare it with your prod environment and detect the bottlenecks.

            I attached a log summary on a VM for a single part, you can notice that it takes only a few seconds.

            Terms & ConditionsAccessibility statement