Extremely slow builds in 8.12.

msouterblight1

VIP Member
Hello,

We are experiencing EXTREMELY slow build times in 8.12. We are on tools 8.97.1.2, and using Oracle 10G as the DB. What I am seeing is that the writing the specs to the DB is taking a VERY long time. I wouldn't think this should take over 5 hours, it's just copying from the SPEC Db on the Deployment Server to the Package Tables on the DB. Has anyone seen this issue and come up with a solution?

Thanks,
Matthew
 
Hi Mathew

What are you comparing this to ? another Oracle installation ? SQL Server ? a previous version of EnterpriseOne ?

Improving the performance of a package build can be through a number of different paths. Remember, performance of something like this could be held up by either the client, the network or the server (ie, everything) - but it is the lowest speed device that reduces everything.

So, while a package build is occurring, you need to look at several things.

1. How is the client performance (the deployment server) ? How is the CPU ? Disk speed ?

2. Have you tried running a package build using a fat client (development workstation) - did it dramatically change the performance (fast/slower ?)

3. While the package build is occurring - how is the performance of the database server - CPU ? Disk utilization ?

4. What is the throughput on the network ? This is an easy one to test, even before you run a package build - try pinging the enterprise server from the deployment server (and vice versa) - and note the latency. Try increasing the PING size to 32k to see if there is any substantial difference. You should see <1ms of latency for small packets. THEN, try FTP'ing a file between your enterprise server and deployment server. Try FTP'ing a large file - about 2Gb or so - and calculate how long it is taking to transfer.

Because you're using Oracle as a database, my guess is that you're on Unix - and there might be an issue with your network performance - something might not be set correctly - and with large transfers, you're probably seeing that issue magnified (but believe me, it would also be occurring on your day to day operations).

I recently worked with a customer who had just purchased a new Unix platform. Evidently, there were some changes on this new platform that prevented large transfers of a single thread across the network. The manufacturer pointed out that the box was designed as a "web server" - hence it couldn't necessarily handle the types of transactions that JDE requires without substantially changing the architecture. I'm not mentioning platform names - but often the hardware manufacturers make changes to keep their costs down - and these become detrimental to large ERP system configurations...
 
You probably believed marketing about this being so much quicker that it used to be? ;-)

It copies the data twice in E812, so don't be surprised.

And although you didn't mention, is your Dep/Server virtualised?
 
Thanks for the response,

I would expect to see some increase in the package build times, but not DOUBLE!

You do bring up a good point about the virtualized Dep. Server, as of right now, it is virtualized, but we should be getting a standalone...

I have monitored the performance during the build, and nothing seems too "out of whack". The only thing that really stuck out were the times to insert the records into the package tables on the DB.

Thanks.
 
Thanks for the reply.

These are all good suggestions, and I will be sure to verify all of them.

I have monitored performance on the Deployment Server, and nothing seemed too "out of whack". As, I stated in my reply to Alex, our Dep. Server is Virtualized, but I don't notice any resources getting pegged.

I will be launching another full build soon. Hopefully the DBA will be able to monitor it then and let me know if he sees anything...

My purpose for this post was to see if anyone else had any "quick fix", but it doesn't seem like there is one for the package builds...Well, we'll get it resolved, and I'll share my findings on the list.

Matthew
 
Well, this would be consistent with the virtualisation impact, that's why I assumed it was what you had. Once you get a dedicated box it will go down...
 
aha - yes, virtualized is substantially slower. You're only really operating on a single thread you see, so everything is timesliced on the host. Of course, it all depends on what virtualization you're using - but realistically the "hard disk" of the deployment server is a horrible "virtual" disk - and there are terrible performance issues with that. Be glad its only 1/2 the expected speed !

Once you go to a physical machine, you'll see a dramatic improvement in performance. Hence the reason why Virtual machines are awesome for testing and development - but crud for production !
 
Actually I have had a virtualised deployment server for more than a year now, and full package build times increased very little post virtualisation to one of our ESX boxes. I don't know about 8.12 but on 8.10 it works very nicely indeed
wink.gif
 
Your new ESX box was probably 4 times faster than the old Dep Server? ;-)
 
ESX is completely different from Virtual PC or VMWare server on a host OS.

Secondly, an ESX box is able to work directly with disk - its disk technology is completely different.

VMWare ESX is STILL not supported as a production deployment server - there is a thread that discusses this elsewhere.

Believe me, if you were to compare apples with apples - ie, a native physical hard box with the SAME technology as the virtual server (ESX or VMWare Server/GSX) - you will absolutely see the physical box be dramatically faster. It isn't difficult to test directly.

HOWEVER, I AM a big fan of VMWare use - don't get me wrong, I have a huge number of VMWare boxes myself - BUT it is IMPORTANT to fully understand the physical differences of VMWare against a native box. Many companies just don't want to understand that difference and then are surprised to find a dramatic slowdown - such as the one that Mathew is talking about. You WILL see a dramatic reduction in speed with package build conversions - unless, of course, you are dramatically improving the size of the deployment server as WELL.

The absolutely WORST deployment server is the old ICS Card on an AS/400. Holy moly - those things took freakin' DAYS to build a package - that was with B732 when the F98741 was still less than a million rows !!!! Believe me, a vmware box would absolutely be faster than one of those things !
 
We had a very similar problem and fought with this for months. Running oracle 10g and linux for enterprise servers. Our full build times with 2 ent servres was taking about 10 hours to complete. The issue was with the broadcomm network card. There is a bug with JDE and boradcomm as discussed in Case 4790601 - Package build spec copy slow, but we couldn't get any of jde's fixes to work. Simple solution was to buy a $40 intel nic and our build times instantly went from 10 hours to 4 hours. I know broadcomm ship with a lot of major brand servers, maybe this might apply to you.
 
FYI Our 8.12 8.97.1.1 Deployment Server is virtualized too (ESX), but the full client build takes almost 2 hours. The server only half an hour.
 
Back
Top