We’re running 10.2.300.7 on 3 app servers to balance the load. It seems Epicor takes care of assigning which app server a user gets connected to at the login, but it’s not always the same one.
How can we see what app server the user is on? Any fields I can use to create a dashboard for this?
The Epicor Client network plumbing only knows about the AppServer specified in the Client Sysconfig so if you are seeing that your three different AppServers are in fact active, then you have some sort of load balancing in play.
In general terms, there are two types of load balancing schemes - one that applies Server Affinity (Sticky) and one that does not. If your load balancing scheme uses Sticky sessions, the Client connection “traffic” will always end up on the same AppServer selected by the load balancing when the connection to the AppServer was first created. For non-sticky load balancing, each individual call to the AppServer is routed separately and there is no practical way to predict which AppServer will handle the call.
Jose - Thanks. I’ll have to explore an updatable BAQ… It’d be awesome if I could include it as a column in the System Monitor.
Pierre - I don’t think the management console listed the connected app server, but it’s been a while since I’ve poked there.
Aaron - I do have that checked, and it always shows APP1 on the footer. This morning I submitted the RecalcCustomerCredit process, and saw increased usage on APP3. Then submitted one of the zScheduled executive dashboard processes, and saw the usage on APP2.
Rich - Thank you for the explanation. Does Epicor use logic for the non-sticky load balancing, and tries to send it to the least loaded server? Or it’s not able to see what the load is, and is random?
Seems like we have non-sticky load balancing going on. I’ll explore setting it in my Sysconfig when I need to run larger load processes, and see what I can do with Jose’s suggestion of getting the session.AppServerURL.
Session AppServer URL will always match the value specified in the Client Sysconfig - the Epicor Client will always try and communicate with that AppServer and if it ends up somewhere else, that is due to your load balancing scheme. The Epicor connection logic is very simple - connect to AppServer specified in Client Sysconfig.
@askulte - did you find a way to determine what app server a user is on? We have multiple app servers and in preparation for going live with 10.2.400 we need to update .NET on a few of them and would like to know if any users are logged into a specific app server at any point in time.
@kfierce - We instruct our users to turn on the server on the status bar with Actions > Options > Global Options > and check the server status bar panel. Maybe Jose’s method can populate a dashboard for admin’s to see which server folks are logged on.
Enhancement request for Epicor - Add that to the EAC.
I think I know the answer but what aspect are you looking for in this area. I usually see three flavors of this need…
Production vs Test awareness. Something obvious like you don’t want to destroy live data accidentally so make it obvious which db you are looking at.
While triaging - which actual app process you were in when something went poof. Used to track down the log file, find the incorrect config on that app server, etc
What’s the public URL to get to this whole of the system. NOT the local box if you are trying to get load balancing to occur, you need to public endpoint of the load balancer.