E10 Performance

Yahoo Archive
1
There is no reason to recycle the app pool on a regular basis, so zero is fine.  The only reason I raised it is in case someone manually creates an app pool and IIS sets a default value of (I think) 1740.


This message has been scanned for malware by Websense. www.websense.com

2
Can anyone say, either in testing or going live with Epicor 10, that they have seen any noticeable performance gain? I've had a test server up and running for about 6-8 weeks now and it doesn't seem any better, if not worse sometimes.

Example: I am in Report Data Maintenance fixing RDD's for custom reports (calculated fields were either added or deleted). Sometimes to pull in a RDD or dulicating a definition I have to wait quite a long time, and other times it is very responsive. No BPMs or customization related to RDD's.

Has anyone had to do some tweaking to their SQL server to achieve better performance or anything else I should look at?
Thanks,

Ted


3

We've noticed significant performance gains across the board. But there are exceptions, some screens like rdd are still slow

On Aug 11, 2014 11:05 AM, "tkoch77@... [vantage]" <vantage@yahoogroups.com> wrote:

 
<div>
  
  
  <p>Can anyone say, either in testing or going live with Epicor 10, that they have seen any noticeable performance gain? I&#39;ve had a test server up and running for about 6-8 weeks now and it doesn&#39;t seem any better, if not worse sometimes.<br>


Example: I am in Report Data Maintenance fixing RDD's for custom reports (calculated fields were either added or deleted). Sometimes to pull in a RDD or dulicating a definition I have to wait quite a long time, and other times it is very responsive. No BPMs or customization related to RDD's.


Has anyone had to do some tweaking to their SQL server to achieve better performance or anything else I should look at?
Thanks,

Ted


</div>
 


<div style="color:#fff;min-height:0;"></div>
4
in E9, there are performance tuning guides for progress and SQL (the result is significant), I guess there is also one for E10 in epicweb
5
Maybe too obvious a question, but is your test server(s) identical in specs to your production Epicor 9 environment?  I know our test servers are virtual machines, whereas our production environment is a beefy server with PCI-Express SSD storage and a physical Windows install (not virtual).  I expect our test environment won't show any huge gains over that production one.
6
Our entire environment is virtualized. Yes, they are basically identical boxes. We followed the hardware sizing guide Epicor provides to setup the E10 server.

It seems like when I first open E10 in the morning and open any screen (job entry) it takes awhile to load and then pull in a job. But after the first time it is noticeably faster. This seems to be the case with most forms every morning and also when I don't use it for a couple hours but it is still open on my desktop. I get there is a timeout setting, but it doesn't just do this for one form when I go back to using the application.

Anyone else see this?

From: "ygroups.adamleer@... [vantage]" <vantage@yahoogroups.com>
To: vantage@yahoogroups.com
Sent: Tuesday, August 12, 2014 8:19 AM
Subject: [Vantage] Re: E10 Performance

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 #ygrps-yiv-1068124342yiv4417625936 --

#ygrps-yiv-1068124342yiv4417625936 .ygrps-yiv-1068124342yiv4417625936ygrp-photo-title{
clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}
#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936ygrp-photo{
background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936photo-title
a,
#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936photo-title a:active,
#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936photo-title a:hover,
#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936photo-title a:visited {
text-decoration:none;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936attach-table div.ygrps-yiv-1068124342yiv4417625936attach-row {
clear:both;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936attach-table div.ygrps-yiv-1068124342yiv4417625936attach-row div {
float:left;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 p {
clear:both;padding:15px 0 3px 0;overflow:hidden;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936ygrp-file {
width:30px;}
#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936attach-table div.ygrps-yiv-1068124342yiv4417625936attach-row div div a {
text-decoration:none;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936attach-table div.ygrps-yiv-1068124342yiv4417625936attach-row div div span {
font-weight:normal;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 div.ygrps-yiv-1068124342yiv4417625936ygrp-file-title {
font-weight:bold;}
#ygrps-yiv-1068124342
#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 #ygrps-yiv-1068124342yiv4417625936 –
#ygrps-yiv-1068124342yiv4417625936ygrp-mkp {
border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 #ygrps-yiv-1068124342yiv4417625936ygrp-mkp hr {
border:1px solid #d8d8d8;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 #ygrps-yiv-1068124342yiv4417625936ygrp-mkp #ygrps-yiv-1068124342yiv4417625936hd {
color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 #ygrps-yiv-1068124342yiv4417625936ygrp-mkp #ygrps-yiv-1068124342yiv4417625936ads {
margin-bottom:10px;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 #ygrps-yiv-1068124342yiv4417625936ygrp-mkp .ygrps-yiv-1068124342yiv4417625936ad {
padding:0 0;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 #ygrps-yiv-1068124342yiv4417625936ygrp-mkp .ygrps-yiv-1068124342yiv4417625936ad p {
margin:0;}

#ygrps-yiv-1068124342 #ygrps-yiv-1068124342yiv4417625936 #ygrps-yiv-1068124342yiv4417625936ygrp-mkp .ygrps-yiv-1068124342yiv4417625936ad a {
color:#0000ff;text-decoration:none;}
#ygrps-yiv-1068124342



Maybe too obvious a question, but is your test server(s) identical in specs to your production Epicor 9 environment?  I know our test servers are virtual machines, whereas our production environment is a beefy server with PCI-Express SSD storage and a physical Windows install (not virtual).  I expect our test environment won't show any huge gains over that production one.





7
Well, the behavior you describe makes sense to me now that the app servers are IIS website.  Do a Google search on how to adjust the Worker Process or Application Pool recycling, and how to extend the Session Timeout.  There might be some other ways you can tweak IIS so that it doesn't have to spin up again when you don't send any requests to the web services for a few hours.
8

Application pool recycle events are logged in the Windows log, so you can see if that’s actually happening.  The ERP 10 deployment tools set the application pool to (1) not recycle on a regular basis and (2) not kill worker processes unless they have been idle for 1740 minutes (the max value).  On that last item, it turns out you can set the idle timeout to 0 to disable it altogether.  The IIS docs were not exactly clear on that.  In any case, it’s good to make sure the app pool settings are correct. We have seen admins set them up manually and overlook recycling settings.

 

If an app pool recycles (or you run IISRESET), it takes a worker process about 12-16 seconds to load the ERP 10 table metadata before it can accept requests.  We are working with Microsoft to improve that (it used to take 25s).  It’s annoying to our developers as well, especially when debugging.

 

One other thing to look into: If you’ve walked away from the client for an hour or so and then come back and start working, you might see an unexpected 20-30 second hang while retrieving data.  Assuming no one reset IIS, this may actually be because your networking infrastructure is killing idle TCP sockets.  The client app is retrying each call a number of times (thinking you may have walked into an elevator with your laptop and at some point, you’ll come back out).

 

We never saw this issue on normal LANs, and IIS won’t kill idle sockets.  But our SaaS customers had this issue because the hosting center firewall had a one hour timeout set for idle connections.  There is a one off for 600.2 and 700.1 to alleviate the problem.  But you should verify you actually have sockets being terminated by an intermediary firewall, router, or VPN connection first.

 

BTW, having the report monitor running (which sends a request to the server every 15 seconds) won’t mitigate the idle socket problem.  The client app opens a socket for *each* ERP service (business object) required by whatever forms are currently open.  No even though one service is getting called regularly, the others might idle out.  We’ve fixed the issue for the next release and we do have a one off, if you are seeing the issue.

 

-Erik



This message has been scanned for malware by Websense. www.websense.com

9
Thanks for the excellent explanations Erik!
10
Thank Erik, some very useful information there.

Have you experienced any slow performance after you have left your computer for some time (30-60min) with the application running and return to it taking over a minute to load a form like Job Entry, and then a long time to execute a search?

I'm wondering if this is related to the IIS app pool or maybe I should be looking elsewhere. It happens every time I leave my computer and return.
11
Just to clarify, do you set your app pool to recycle at a certain interval? By default Epicor sets the interval to zero when the app pool is created.