Correct. How fast is Net.tcp in the browser? 
In Kinetic, are we still using XML or is it JSON now?
I’ll try lighting the bat signal and see if we can get @Bart_Elia to stop by the thread…
Clearly there’s a lot of debate on this, but is it unreasonable to at least try testing https? At least we can rule it out if there’s no improvement…
At this point, I think we’re talking past each other:
- Net.tcp is faster and is not routable (no issue if network is extended with VPN)
- Net.tcp is sensitive to line noise and will drop connections so Epicor recommends https over a WAN, especially if routable
- Net.tcp can only speak to another Net.tcp client and support will end with the .Net Client
- https has serialization overhead
- https is routable and is more resilient to network noise
- https works with multiple clients, including Kinetic
But we’re not sure why there’s a speed issue from this. The raw network seems fine according to @esapco_mh. Maybe there is other hardware in play, like a Riverbed device or a security appliance?
3 Likes
In browser JSON of course, in smart client (not embedded browser) - binary regardless of protocol type.
But if for example, service method makes hunderds of database calls, the amout of time spent on serialization is insignificant.
1 Like
I agree if you stay within the new paradigm, for new developments, and the future of things, but considering that’s not at all how the vast majority of the business objects in Epicor work, instead relying on a metric tonne of calls carrying datasets around, serialization costs are far from insignificant, currently…
Just a Sonicwall firewall. However, we did testing and bypassed the firewall completely with our secondary connection that is the same speed and there was no difference is speed or performance.
We do have a terminal server setup for our handhelds, so I have a few users that are currently testing that. The terminal server resides in Connecticut and we are seeing better performance using that. However, we have seen a few crashes but have been minor.
Hey all - I saw a bat signal.?.? (And @josecgomez quit using an actual bat on me)
First, @Olga is correct (as always).
Next, Epicor ERP did a few different things mostly because you darn customers had differing needs so we had to 
Back in 2007 when we started E10 design, we did a separation of the biz objects from how we exposed the logic - WCF, REST, etc as how it gets across the network is your choice. Internet, local LAN, WAN, Cell Network. Everyone has differing needs so that architectural design was intentional. You could decide what you needed
Lastly… it’s 2021. Who cares about micro optimizing for net.tcp versus json over https.
Unless you are in back woods with 3G cell network trying to run things, network performance is rarely the issue with performance. The server code as Olga mentions hitting the db a gazillion times for too much data is 99% the issue.
There are a ton of features built on top of functionality on top of other … you get the idea. It’s rare that ERP has taken the time to optimize for a new feature in a silo. . I am enjoying building out a microservices architecture at new shop with background service bus processing to keep cross domains in sync, roll up database for backwards compatibility, etc. All the things on my wish list at Epicor that never came to market and the approach modern systems are evolving towards for survival and long term maintainability.
What’s it all mean? Pick the network transport you need for other reasons. It’s not the performance issue you think it is 99.9% of the time
5 Likes