cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Publishing Time

Cosmo
1-Newbie

Publishing Time


Hi All...I think this is a question for "solutions" but let me know if it should be Viz.
We're trying to troubleshoot why it takes so long for our worker to publish viewables. We added a second worker to our worker machine and we are now publishing at twice the speed but still....each job takes between 1.5 and 2 minutes to publish and we always seem to have a backlog of 2000 items. (with the second worker added, I actually get two jobs published in the same 1.5-2 minute period.)
I took a look at the log files and noticed the following 1+ minute gap that keeps repeating. It's hard to tell but I believe that the gap is occurring during the "Registering Server" step (even though it says COMPLETE). Does anyone know what is actually going on during this step that could be causing me such grief? Has anyone seen this before?
I don't believe the download of the part is taking this long.....for one thing, the amount of time is always the same regardless of the size of the files being published. Secondly, adding a second worker gave us twice the throughput (if this was a network issue, I'd have almost no difference in throughput). And thirdly, the resulting upload after publishing happens in a second or two (I know it's not the same file as the one being downloaded and viewables are smaller in size than Pro/E files but still...they have some meat).
Below is a section of the log file where you can see the time delay between these two steps:
[2010-12-15 07:45:43] Recipe file: C:/ptc/productview_adapters/proe_setup2/proe2pv.rcp[2010-12-15 07:45:43] Source file: mgen3001_insul.prt[2010-12-15 07:45:43] Output file: C:/ptc/shared_worker/w2i1j1/m35039-010_insul_prt.pvs[2010-12-15 07:45:43] Registering Server : COMPLETE[2010-12-15 07:47:28] Downloading mgen3001_insul.prt : COMPLETE[2010-12-15 07:47:33] Loading m35039-010_insul<mgen3001_insul>.prt :
If anyone has any idea what's going on here, I would be very very appreciative.
Mike -

11 REPLIES 11

Mike, I haven't seen this. Many times the smaller parts go very fast ( 20 seconds if that) once the worker is actually up and running.

Can you send info about your hardware environment (where is the worker at? is it on its own system or the production server, 32bit, 64bit)

Send any of your wvs.properies that you have altered (and are present in the site.xconf)

send a screenshot of your worker Config from the worker agent admin.




[cid:image001.gif@01CB9C72.16FCC460]

Steve Vinyard
Application Engineer
avillanueva
22-Sapphire I
(To:Cosmo)

I think you hit on the issue with registering the server. Are you using
multiple instances of a worker on the same machine or two independent
workers on the same machine? I have the latter and I remember you
needed to make sure the workspace cache locations were defined to
different folders in the batch startup script for Pro/E. It should not
take that long to register a server connection. How about the other
settings? Does the worker remain running after each job or shutdown.?


Cosmo
1-Newbie
(To:Cosmo)


Hi Steve,
I know...it's strange....that's why I'm trying to determine what actually occurs during the "Registering Server" step....and I'm curious why it needs to do this to process each and every object.
The worker is a separate machine. It's 32 bit machine with XP Professional 2002 (service pack 2) on a Dell Precision PWS390 with 2 processors: Intel Core2 Extreme CPU q6800 @2.93 GHz with 3.5 GB of RAM.....most of this doesn't even get used (we usually sit at about 1.1 GB of RAM being used while both workers are doing their stuff).
The Pro/E processes never take more than 25% of each of the processors.

Mike -


Cosmo
1-Newbie
(To:Cosmo)


Hi Antonio,
Yes, we took the separate workspaces/caches into consideration and followed PTC TPIs on how to do this properly (it actually works well).
This particular time issue happens regardless of whether there is one worker configured or two.

Mike -


Cosmo
1-Newbie
(To:Cosmo)


I have a couple of people that sent me emails about the cache. The issue is occurring even on the brand new worker as well. The cache was created this morning for the first time.

Mike -


RandyJones
19-Tanzanite
(To:Cosmo)

On 12/15/10 15:02, Michael Kramer wrote:
> Hi All...I think this is a question for "solutions" but let me know if it should be Viz.
>
> We're trying to troubleshoot why it takes so long for our worker to publish viewables. We added a second worker to our worker machine and we are now publishing at twice the speed but still....each
> job takes between 1.5 and 2 minutes to publish and we always seem to have a backlog of 2000 items. (with the second worker added, I actually get two jobs published in the same 1.5-2 minute period.)
>
> I took a look at the log files and noticed the following 1+ minute gap that keeps repeating. It's hard to tell but I believe that the gap is occurring during the "Registering Server" step (even
> though it says COMPLETE). Does anyone know what is actually going on during this step that could be causing me such grief? Has anyone seen this before?

As you can see from my sample log below the time to complete this step is 9 seconds in my case. After perusing my log files I have found this to take anywhere from 6 seconds to around 10 seconds.
Notice the entire time to process was 13 seconds.

>
> I don't believe the download of the part is taking this long.....for one thing, the amount of time is always the same regardless of the size of the files being published. Secondly, adding a second
> worker gave us twice the throughput (if this was a network issue, I'd have almost no difference in throughput). And thirdly, the resulting upload after publishing happens in a second or two (I know
> it's not the same file as the one being downloaded and viewables are smaller in size than Pro/E files but still...they have some meat).
>
> Below is a section of the log file where you can see the time delay between these two steps:
>
> [2010-12-15 07:45:43] Recipe file: C:/ptc/productview_adapters/proe_setup2/proe2pv.rcp
> [2010-12-15 07:45:43] Source file: mgen3001_insul.prt
> [2010-12-15 07:45:43] Output file: C:/ptc/shared_worker/w2i1j1/m35039-010_insul_prt.pvs
> [2010-12-15 07:45:43] Registering Server : COMPLETE
> [2010-12-15 07:47:28] Downloading mgen3001_insul.prt : COMPLETE
> [2010-12-15 07:47:33] Loading m35039-010_insul<mgen3001_insul>.prt :

A sample section of one of my publishing logs:

[2010-12-15 14:10:28] Recipe file: /export/home/cadwrkr/proe_setup.uhura-cw1/proe2pv.rcp
[2010-12-15 14:10:28] Source file: 204-378d.prt
[2010-12-15 14:10:28] Output file: /opt/ptc/Windchill/cadworkers/uhura/w1i1j129/204-378d_prt.pvs
[2010-12-15 14:10:28] Registering Server : COMPLETE
[2010-12-15 14:10:39] Downloading 204-378d.prt : COMPLETE
[2010-12-15 14:10:41] Loading 204-378d.prt :
[2010-12-15 14:10:41] proe2pv Error:56318: ProE file uses generic single-byte language locale, output may be incorrect
COMPLETE
[2010-12-15 14:10:41] Processing 204-378d.prt : COMPLETE
[2010-12-15 14:10:41] Getting Mass Properties : COMPLETE
[2010-12-15 14:10:41] Converting Author States : COMPLETE
[2010-12-15 14:10:41] Generating Output : COMPLETE
[2010-12-15 14:10:41] Generating thumbnail : COMPLETE

>
> If anyone has any idea what's going on here, I would be very very appreciative.

I don't have any good ideas for you. As you can see from my above output the time between registering and downloading is
>
> Mike Kramer
> - <">mailto:->
>
>
>
> -----End Original Message-----


--
------------------------------------------------------------------------
Randy Jones
Systems Administrator
Great Plains Mfg., Inc.
1525 E North St
PO Box 5060
Salina, KS USA 67401
email: -
Phone: 785-823-3276
Fax: 785-667-2695
------------------------------------------------------------------------

Okay, this might be a long shot, I haven't dealt with the worker setup directly.

I assume that the Pro/E worker needs a config.pro file to work the way you want. There is a config setting for remembering the server: DM_REMEMBER_SERVER, the default value is YES, but it might be worth checking out...

-marc

Cosmo
1-Newbie
(To:Cosmo)


Hello again,
I've had a lot of recommendations (VERY MUCH APPRECIATED) and while they all seem to be great recommendations and logical, none of them seem to solve my issue so I'm down to my last resort.....reading the instruction manual for the object adapters 🙂
Interestingly, here is what it says about the Host and Port for the server:
"i. Server HostThe Server Host is the name of the machine on which the server isrunning. The worker may run on a different machine than the server.ii. Server PortThe Server Port defines the port to be used when connecting to theWorker Agent on the server host. The port number should match thePort setting defined in the configuration of the Worker Agent."
I read this to mean that settings should match in the agent's configuration on the windchill server and the object adapter settings. See attached images. NOTE: the default value in the object adapter configuration is 5600. Our worker agents are configured to use port 601 on the windchill server.
The problem is....the workers stop working when I set these values to match. So it would appear that these two settings should NOT be set to match each other. Or is it possible that after changing these settings I need to reboot the windchill server? I'm not sure this is necessary.
Does anyone else know what this means in the guide?
I'm really getting frustrated with this and YES, I have been working with Tech Support too.
It's something to do with the Registering of the Server but I can't figure out what it is.
Mike -


On 12/16/2010 1:22 PM, Michael Kramer wrote:

Mike,
This might make it a little clearer.

Port 601 is the port that the remote cad agent is running on and needs
to be specified on the Windhill side. 5600 is the port windchill
listens on and needs to be specified on the agent side.

You should at least be talking again then.


How much memory do you have on your agent machine? Is it possible it is
hard swapping? Look at your task manager on the agent when this happens
and see if you have exceeded physical memory. If you do not know how to
do that I can give you more detail.

--Bob


> Hello again,
>
> I've had a lot of recommendations (VERY MUCH APPRECIATED) and while
> they all seem to be great recommendations and logical, none of them
> seem to solve my issue so I'm down to my last resort.....reading the
> instruction manual for the object adapters 🙂
>
> Interestingly, here is what it says about the Host and Port for the
> server:
>
> "i. Server Host
> The Server Host is the name of the machine on which the server is
> running. The worker may run on a different machine than the server.
> ii. Server Port
> The Server Port defines the port to be used when connecting to the
> Worker Agent on the server host. The port number should match the
> Port setting defined in the configuration of the Worker Agent."
>
> I read this to mean that settings should match in the agent's
> configuration on the windchill server and the object adapter settings.
> See attached images. NOTE: the default value in the object adapter
> configuration is 5600. Our worker agents are configured to use port
> 601 on the windchill server.
>
> The problem is....the workers stop working when I set these values to
> match. So it would appear that these two settings should NOT be set
> to match each other. Or is it possible that after changing these
> settings I need to reboot the windchill server? I'm not sure this is
> necessary.
>
> Does anyone else know what this means in the guide?
>
> I'm really getting frustrated with this and YES, I have been working
> with Tech Support too.
>
> It's something to do with the Registering of the Server but I can't
> figure out what it is.
>
> Mike Kramer
> - <">mailto:->
>
>
>
>
> ------------------------------------------------------------------------
> From: -
> To: -
> Subject: [solutions] - Publishing Time
> Date: Wed, 15 Dec 2010 16:02:40 -0500
>
> Hi All...I think this is a question for "solutions" but let me know if
> it should be Viz.
>
> We're trying to troubleshoot why it takes so long for our worker to
> publish viewables. We added a second worker to our worker machine and
> we are now publishing at twice the speed but still....each job takes
> between 1.5 and 2 minutes to publish and we always seem to have a
> backlog of 2000 items. (with the second worker added, I actually get
> two jobs published in the same 1.5-2 minute period.)
>
> I took a look at the log files and noticed the following 1+ minute gap
> that keeps repeating. It's hard to tell but I believe that the gap is
> occurring during the "Registering Server" step (even though it says
> COMPLETE). Does anyone know what is actually going on during this
> step that could be causing me such grief? Has anyone seen this before?
>
> I don't believe the download of the part is taking this long.....for
> one thing, the amount of time is always the same regardless of the
> size of the files being published. Secondly, adding a second worker
> gave us twice the throughput (if this was a network issue, I'd have
> almost no difference in throughput). And thirdly, the resulting
> upload after publishing happens in a second or two (I know it's not
> the same file as the one being downloaded and viewables are smaller in
> size than Pro/E files but still...they have some meat).
>
> Below is a section of the log file where you can see the time delay
> between these two steps:
>
> [2010-12-15 07:45:43] Recipe file:
> C:/ptc/productview_adapters/proe_setup2/proe2pv.rcp
> [2010-12-15 07:45:43] Source file: mgen3001_insul.prt
> [2010-12-15 07:45:43] Output file:
> C:/ptc/shared_worker/w2i1j1/m35039-010_insul_prt.pvs
> [2010-12-15 07:45:43] Registering Server : COMPLETE
> [2010-12-15 07:47:28] Downloading mgen3001_insul.prt : COMPLETE
> [2010-12-15 07:47:33] Loading m35039-010_insul<mgen3001_insul>.prt :
>
> If anyone has any idea what's going on here, I would be very very
> appreciative.
>
> Mike Kramer
> - <">mailto:->
>
>
>
> -----End Original Message-----

RandyJones
19-Tanzanite
(To:Cosmo)

On 12/16/10 15:22, Michael Kramer wrote:
> Hello again,
>
> I've had a lot of recommendations (VERY MUCH APPRECIATED) and while they all seem to be great recommendations and logical, none of them seem to solve my issue so I'm down to my last
> resort.....reading the instruction manual for the object adapters 🙂
>
> Interestingly, here is what it says about the Host and Port for the server:
>
> "i. Server Host
> The Server Host is the name of the machine on which the server is
> running. The worker may run on a different machine than the server.
> ii. Server Port
> The Server Port defines the port to be used when connecting to the
> Worker Agent on the server host. The port number should match the
> Port setting defined in the configuration of the Worker Agent."
>
> I read this to mean that settings should match in the agent's configuration on the windchill server and the object adapter settings. See attached images. NOTE: the default value in the object
> adapter configuration is 5600. Our worker agents are configured to use port 601 on the windchill server.
>
> The problem is....the workers stop working when I set these values to match. So it would appear that these two settings should NOT be set to match each other. Or is it possible that after changing
> these settings I need to reboot the windchill server? I'm not sure this is necessary.
>
> Does anyone else know what this means in the guide?

The way I see it is this:

The "Worker Daemon Port" (Worker Configuration Wizard) is the port the WorkerDaemon is listening on the cadworker host. This is the port that Windchill will use to start talking to the cadworker
host. Since I am using a Solaris cadworker my worker configurations do not have this.

The "Server Port" (ProductView Pro/ENGINEER Adapter Configuration) is the port the Windchill server is listening on. This is 5600 unless you have changed it. This is the port the cadworker will use to
talk to the Windchill server. You can test the connection to the Windchill server by selecting the "Test Server" button next to the "Server Host" box. This "Test Server" will only work AFTER you have
configured the worker agent in Windchill. I have also entered a fully qualified hostname in the "Server Host" field ie abgtwc.yourCompanyDomain.com instead of abgtwc

These two ports are not the same.
>
> I'm really getting frustrated with this and YES, I have been working with Tech Support too.
>
> It's something to do with the Registering of the Server but I can't figure out what it is.
>
> Mike Kramer
> - <">mailto:->
>
>
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> From: -
> To: -
> Subject: [solutions] - Publishing Time
> Date: Wed, 15 Dec 2010 16:02:40 -0500
>
> Hi All...I think this is a question for "solutions" but let me know if it should be Viz.
>
> We're trying to troubleshoot why it takes so long for our worker to publish viewables. We added a second worker to our worker machine and we are now publishing at twice the speed but still....each
> job takes between 1.5 and 2 minutes to publish and we always seem to have a backlog of 2000 items. (with the second worker added, I actually get two jobs published in the same 1.5-2 minute period.)
>
> I took a look at the log files and noticed the following 1+ minute gap that keeps repeating. It's hard to tell but I believe that the gap is occurring during the "Registering Server" step (even
> though it says COMPLETE). Does anyone know what is actually going on during this step that could be causing me such grief? Has anyone seen this before?
>
> I don't believe the download of the part is taking this long.....for one thing, the amount of time is always the same regardless of the size of the files being published. Secondly, adding a second
> worker gave us twice the throughput (if this was a network issue, I'd have almost no difference in throughput). And thirdly, the resulting upload after publishing happens in a second or two (I know
> it's not the same file as the one being downloaded and viewables are smaller in size than Pro/E files but still...they have some meat).
>
> Below is a section of the log file where you can see the time delay between these two steps:
>
> [2010-12-15 07:45:43] Recipe file: C:/ptc/productview_adapters/proe_setup2/proe2pv.rcp
> [2010-12-15 07:45:43] Source file: mgen3001_insul.prt
> [2010-12-15 07:45:43] Output file: C:/ptc/shared_worker/w2i1j1/m35039-010_insul_prt.pvs
> [2010-12-15 07:45:43] Registering Server : COMPLETE
> [2010-12-15 07:47:28] Downloading mgen3001_insul.prt : COMPLETE
> [2010-12-15 07:47:33] Loading m35039-010_insul<mgen3001_insul>.prt :
>
> If anyone has any idea what's going on here, I would be very very appreciative.
>
> Mike Kramer
> - <">mailto:->
>
>
>
> -----End Original Message-----


--
------------------------------------------------------------------------
Randy Jones
Systems Administrator
Great Plains Mfg., Inc.
1525 E North St
PO Box 5060
Salina, KS USA 67401
email: -
Phone: 785-823-3276
Fax: 785-667-2695
------------------------------------------------------------------------

Cosmo
1-Newbie
(To:Cosmo)


Hi All,
OK....I have two workers churning through publishing jobs on the same machine and it's working well. But we still see that it takes over a minute to connect Pro/E to the Windchill server during each job. I tested this manually from that machine and saw that Pro/E seems to take that amount of time independent of the worker configuration. This leads me to believe that the issue is not related to the workers but just a general issue between Pro/E and Windchill. Does anyone have any ideas on what could cause this much of a time delay in the connection to Windchill? Are their any config options in Pro/E that would make this connection quicker? Assume that we have not config options set right now.
We've deleted all the workspaces for the visualization user, but the time gap remains.
We're using 9.1 M020 for Windchill and WF3 M210 for Pro/E (this is the same set up we have on all of our other machines but we generally don't see the time delay).
Mike -


Top Tags