Package build is going slow

Hi All,

I am trying to do a Full package build for all the environments we have. The
Package build for both Client and Server in DV, PY went well within 12
hours. but one of our other environment called CP7333 Is taking for ever. It
is taking 3-4 days just for client package. I am using the Deployment
server(WINDOWS2000, SP2, 2GB RAM) to build a package and I am logging in to
DEP7333 Environment.


But If I use the Fat client to build a package build for this environment it
is going normally and completing within 12 hours.

Any body has any Ideas why it is taking so much time?

AS/400 Coexistent OneWorldXE Update4, SP18.1 F1 WIN2000

Thanks
Prabhaka

What does your disk space look like on the Deployment Server?

Both the drive where OW is installed and the drive where the OS is installed.

I always disable the virus protection before starting the package =
build.
=20
Virtual Memory is set to 2064 MB.
=20
We have enough space(30gb) on the deployment server where oneworld was
installed. but we have very limited space(390mb) on the drive where we
installed the operating system.
=20
Yes the Busbuild is going since last two days.=20
=20
No other Processes are running on the server.
=20
I can't think of any problems like this because it is running fine for =
other
environments like DV7333, PY7333, PD7333. It is going slow only for =
this
environment(CP7333).
=20
Let me know if there is any other ideas or clues.
=20
thanks
Prabhakar
=20

Also check to make sure that you don't have logging turned on. ANother way to enhance package builds is to set the performance tab in ODBC for Central objects for each path code to 512. That reduced my builds by about 1.5 hours. Also on you enterprise multi thread your package build queue.

Cleola, Are you setting both the large object threshold and record blocking
to 512?



Xe, SP 17.1_E1, Update 2, ES=AS/400 V5R1, CO=AS/400, Thick & Citrix Clients

I think this poster may be on to something. If the ODBC's for the environments are different, such as compression setting for Central Objects, your build times could vary between environments.

Is the difference in build times in the Spec Build or BusBuild?

Does this happen every time with this environment?

It is happening every time for this environment. I was suspecting that some
how my odbc connections are corrupted. it is going slow for the spec build
like FDASPEC, FDATEXT, RDASPEC while bus build.

Thanks
Prabhaka

Re: RE: Package build is going slow

Make sure that ODBC settings for your Central Objects ODBCs are per IBM recommendations.

RE: RE: Package build is going slow

Hi

I did set up my ODBC connections same as other environments. Of course all
the ODBC Connections are there as per IBM Recommendations. because we had a
lot of problems with performance initially. At that time we went through all
the odbc connections.

I have one more question?

Which is the best way to build a package. Is this by using the Fat client or
using the Deployment server?

Thanks
Prabhaka

Re: RE: RE: Package build is going slow

Hi Prabhaka
I would be interested to know the best way to do package build(Performance wise).
We did a lot of experimentation on package build last month. We copied all the path codes to the NAS( Network Attached Storage) and figured out that package build time has gone from 6 to 7.5 hours and then NAS vendor recommended some registry changes. After registry changes, the package build time on NAS went up to 13 hours. We reverted back the registry changes and copied all the path codes on local drive, but the package build time was still 13 hours on deployment server( Spec build time increased drastically). On fat client( Single CPU), it took us only 5 hours to build the package.
We decided to rebuild the deployment server( because of registry changes) and after rebuild of deployment server, the package build time on the deployment is back to 6 hours.Still the package build on fat client is fast as compared to the deployment server(Dual CPU).
I called JDEdwards support for package build performance to understand the cause of problem.. they could not help me either.

Re: RE: RE: Package build is going slow

Here is the text from an old document. I cannot even find it on the KG anymore or I would refer you to the doc number. I am hoping that if you understand the process in detail, you will be able to understand the performance issues.

Full Client Build
======================


Depending where the package build is run from, R9621 is run on the Workstation or the Deployment Server.

The following takes place on the Deployment Server and is graphically represented in Section II.

The packagename directory is created.
(\\deploymentserver\b7331\pathcode\packages\packagename)

The packagename.inf file is created.

(\\deploymentserver\b7331\package_inf\packagename.inf)

The bin32 and res directories are copied from the check-in directory to the packagename directory.
From: (\\deploymentserver\b7331\pathcode\bin32)

To: (\\deploymentserver\b7331\pathcode\packages\packagename\bin32)

From: (\\deploymentserver\b7331\pathcode\res)

To: (\\deploymentserver\b7331\pathcode\packages\packagename\res)

The source, include, make, and work directories are copied from the check-in directory to the packagename directory. Lib32 and obj directories are just created, but no files copied in.
From: (\\deploymentserver\b7331\pathcode\source)

To: (\\deploymentserver\b7331\pathcode\packages\packagename\source)

From: (\\deploymentserver\b7331\pathcode\include)

To: (\\deploymentserver\b7331\pathcode\packages\packagename\include)

.

.

.

(The directories described in 3 are only copied if you do not check mark - Build Business Functions)



(4 a and b happen simultaneously)
a. Spec files and indexes are generated – RDB records are used to generate .ddb Spec files and

.xdb index files are generated off the DDB files.

The files generated are placed in (\\deploymentserver \b7331\pathcode\packages\packagename\spec)

Examples: fdaspec.ddb, fdaspec.xdb

gbrspec.ddb, gbrspec.xdb

rdatext.ddb, rdatext.xdb

b. Busbuild is run from workstation or deployment server, depending on where R9621 was run

from.

NER is generated (n*.c, n*.h and f*.c, f*.hxx)

The n*.c and f*.c files are placed in

(\\deploymentserver b7331\pathcode\packages\packagename\source)

The n*.h and f*.hxx files are placed in

(\\deploymentserver \b7331\pathcode\packages\packagename\include)

Make files are generated.
The location where the make files are placed, depends on where the R9621 was run from.

If R9621 is run from the deployment server:

(\\deploymentserver\b7331\pathcode\obj)

If R9621 is run from the a client workstation:

(rootdrive:\b7\pathcode\obj)

C code is compiled into *.obj files.
(\\deploymentserver\b7331\pathcode\packages\packagename\obj)

Linking of obj files into libraries
(\\deploymentserver\b7331\pathcode\packages\packagename\lib32)

Creation of .dlls from libraries
(\\deploymentserver\b7331\pathcode\packages\packagename\bin32)

9. NER is copied to check-in location

(n*.c and f*.c files)

From: (\\deploymentserver\b7331\pathcode\ packages\packagename\source)

To: (\\deploymentserver\b7331\pathcode\source)

(n*.h and f*.hxx files)

From: (\\deploymentserver\b7331\pathcode\ packages\packagename\include)

To: (\\deploymentserver\b7331\pathcode\include)

10. Package is compressed (**if options are checked – helps, foundation and data are also compressed)

(\\deploymentserver\b7331\pathcode\ packages\packagename\*.cab)

11. The bin32, lib32 and obj directories are copied to check-in location.

From: (\\deploymentserver\b7331\pathcode\ packages\packagename\bin32)

To: (\\deploymentserver\b7331\pathcode\bin32)

From: (\\deploymentserver\b7331\pathcode\ packages\packagename\lib32)

To: (\\deploymentserver\b7331\pathcode\lib32)

From: (\\deploymentserver\b7331\pathcode\ packages\packagename\obj)

To: (\\deploymentserver\b7331\pathcode\obj)

Re: RE: RE: Package build is going slow

Thanks Brother of Kara for the information. In my case, I have observed that it is Spec build time(Even while building package from fat client/Deployment server) that varies and causes the problem.

Re: RE: RE: Package build is going slow

Is it Spec Build time or Spec retrieval time? If it is taking a long time to retrieve the records from the RDB then you can narrow the bottleneck down to RDB or network.

Re: RE: RE: Package build is going slow

Hi Brother of Kara
I have seen 2 different cases
Case no 1
Ist Instance
09:59:08 1 RDB record count in ASVRHDR : 2178
09:59:26 0 Number of TAM records fetched: 2178.

2nd instance
11:35:42 1 RDB record count in ASVRHDR : 2178
11:35:46 0 Number of TAM records fetched: 2178.
Does it indicate time increased for RDB count or TAM record fetched? I think time increase for TAM records fetch??
Case no 2
Time taken to create spec indexes increased?

Thanks

Re: RE: RE: Package build is going slow

Here is the way I see it:

Action -OW fetches records from RDB and change to TAM

Areas affected - Disk read on RDB server, network software interface (ODBC), network traversal, disk write on build machine

Action - Index Build

Areas affected - CPU on build machine, Disk Write on build machine


If you are *consistently* seeing differences between environments' build times and can narrow down to Spec Retrieval then you can look at what is different between environments in the affected areas.

If you are *consistently* seeing differences between environments' build times and can narrow it down to Spec Index build, you're on your own because that makes no sense to me whatsoever and is most likely being influenced by random factors that bear no relation to what we can account for.

To me the trick is to narrow it down to a repeatable issue and choose the most likely factor based on the knowledge of the process and areas affected. From there you eliminate the factors until you are either satisfied or more confused than when you started. If the case is the latter - try to blame it on someone else and let them troubleshoot it for a while.

Hello,
We already had this problem and we resolved it in stopping all services relative to nortons antivirus on deployment serveur ( the built full package which was 3 days fall down to 18 hours)