robrpeters - Wednesday, September 16, 2009 2:16 PM:
We are currently experiencing delays with IE rendering pages from Aras 9.10. Each requested page takes as long as half a minute to load. This occurs each time an new link is clicked in the page.
Monitoring the task manager on several of our local computers, we have witnessed that iexplorer.exe is using 50% - 75% of all processor time. This appears to happen even on new computers with fast processor and plenty of memory. During the time when that page is loading, the browser window becomes unresponsive until completely finished rendering the page. The processor time percentage then returns to a normal level.
We have noticed this in both IE6 and IE7 but only for Aras pages. Other web performanc is normal.
Also, we have independent installations of Aras running on 2 separate IIS servers yet experience the same slow performance from both.
Is this a commom issue? I don't mean to be impatient, but the current speed is nearly unmanageable.
Sorry If this is a repost. I attempted to post this two days ago but still do not see the post.
Anonymous - Wednesday, September 16, 2009 4:19 PM:
It actually sounds like a network related issue, without knowing any more. Are you using a proxy server?
Does the same performance issue happen if you try connecting to Aras Innovator through http://localhost on the server?
robrpeters - Tuesday, October 13, 2009 9:40 AM:
The performance is slow even when connecting to Aras through http://localhost. Because of this, I do not suspect our network is causing the problem. We are running a Squid proxy on the network, but only for external internet traffic. The IIS server hosting Aras should not be affected.
Anonymous - Tuesday, October 13, 2009 6:25 PM:
What are your settings for the LAN?
1) Open IE
2) Select Tools-->Internet Options
3) Select the Connections tab
4) Select the "LAN Settings" button
For instance, if you are using a PAC file that tests the header content for URL, it could be rerouting all the calls from the .NET controls(instead of your direct IE session) if the full URL is not listed in the header.
robrpeters - Wednesday, October 14, 2009 6:10 PM:
1. IE requests data from Aras.
2. Aras responds successfully.
3. IE begins to load page.
4. IE requests additional data.
5. Aras responds successfully.
6. IE now freezes and utilizes 50-75% of the CPU. During this time IE is completely unresponsive and there is no network activity.
7. CPU returns to normal and IE requests additional data from Aras.
8. Aras responds successfully.
9. IE continues to load the page.
10. Data is exchanged a little more and IE finishes loading the page without incident.
Brent - Wednesday, October 21, 2009 11:15 AM:
Bump. Anyone else experiencing these issues? This is seriously affecting our deployment.
Brent
robrpeters - Monday, October 26, 2009 2:04 PM:
I have noticed an interesting occurance when trying to troubleshoot this issue. We have some workstations running Windows XP -x64 with 10 GB of RAM. These machines are able to render the pages in around 7 -10 seconds. Similarly configured workstations with 4GB RAM are taking 2x or 3x as long (similar performance to machines running XP Pro with 2 GB). The minimum specs for client computers seem ro require only 512MB of RAM. Surely we shouldn't need 10GB of RAM to get the Aras pages to load in a reasonable amount to time. Any ideas...
PeterSchroer - Monday, October 26, 2009 2:38 PM:
hey Rob,
My 2 cents... something is really wrong with your current installation. Within the intranet, same site etc. you should be executing queries in < 1 second, and opening a window to view a part in well under <2 seconds. That's the performance I am seeing on our internal production system MyInnovator.com My laptop has only 2GB of RAM, running XP PRO. We've lots of users internally with only 1GB of RAM. Aras Innovator runs well for all of them.
The times you are reporting for opening windows sounds like what we hear for a remote client is accessing Aras Innovator, on a network with awful latency. You would never normally see these times on an Intranet.
Your expectations should be well < 2 seconds for any window for internal users, and well under 5 seconds for any remote user connecting to your server through the open internet. If that's not what you are seeing, the server was configured wrong, or your network has a proxy server that is mis-behaving. The only other thing we've seen cause really terrible performance is either server-side or client-side virus scanning... scanning the same files over and over, each time they are loaded.
Peter
hiro - Monday, October 26, 2009 2:48 PM:
Hello robrpeters
Does this problem occure only when you view Part?
Is this delay related to Mult-level BOM relationship tab?
when you stop the relationship between "Part" and "Multi-Level BOM"
and IE don't load Mulfi-Level BOM data, does IE render faster than ever?
If so, it seems very possibly that the problem is owed to "Multi-Level BOM" Tab View.
If that's right, if you please, let me know relation between render time and the number of the part in multi-level- BOM(the number of the all parts, and the number of level of BOM)
Regargs,
hiro
RonCK - Friday, November 13, 2009 10:21 AM:
Hiro and everyone,
The problem occurs on part load only (whether for view or edit). We definitely see worse times on the first part load, greater than 90 seconds, (per form) then secondary loads (~50 seconds). We get a pop-up error during that first load that says 'Stop running this script? A script on this page is causing Internet Explorer to run slowly. If it continues to run, your computer may become unresponsive. (with Yes/No) options. Regardless of what you hit, the page then loads almost immediately after that error is cleared. This seems to coincide with what Rob said before. Our IE program actually goes 'Non-Responsive' with any part view for some amount of time. We tried an experiment per Peter's post and ran this on a computer without McCaffey (our corporate mandatory antivirus app). This did improve load times, but we're still not close to what others are seeing (30s on first load, 10s on later loads) and we still get that same script error and IE freeze. This issue generates a lot of complaints from our users. Any suggestions would help.
thanks,
RonCK
RonCK - Monday, November 16, 2009 10:11 AM:
We used a javascript debugger and discovered that the vast majority of our slowdown and lock up occur as the tabber loads. If we suppress the tabs on part loads our load times are almost what Peter has suggested we should get. If we turn tabs back on in an open part, IE locks up as we see during the normal use and once the error clears, the page refreshes with the tabs open. We're narrowing this down. Any help would be appreciated.
thanks,
RonCK
RonCK - Friday, November 20, 2009 9:58 AM:
Bump. We're still fighting this problem. We still get the 'A script on this page is causing your computer to run slowly error' on part load. Does anyone have any other suggestions?
thanks,
RonCK
