Memory and Performance Enhancements to eonetservice
In an effort to further reduce working memory consumption, and improve performance, an enhanced data caching mechanism is now in place for eonetservice (mainline using mainline mobile devices).
The web service, when servicing a request for a mobile device, would obtain a local eoStar cache to the database to improve performance when talking to sql. This is still in place, however the cache object was local with respect to the thread of the request that was running. A diagram of this may help explain our current production environment:
With larger database, each cache could consume 150-500Megabytes when in use. Once the web process request has been satisfied for the device, then the cache would be released. This would only pose a problem for larger customers that happen to have, something like 200 handhelds simultaneously synchronizing. The memory strains on the web service could outstrip the machine’s capacity under this extreme condition. Typically, even when ‘all the salespeople’ are synchronizing at the same time, a larger operation’s eonetservice would see about 1/3rd of the actual devices at any one moment. So it has not been a production problem really seen in current deployments.
But even under those conditions, improvements can be made! Specifically, the newer webservice now manages a shared cache among all of the devices for the same database. I like diagrams, so maybe this one for the revised model will show you
So what happens now is that when a request comes into eonetservice, it fetches a cache for the database to which the mobile device has requested. That cache is now saved in an Application Domain context so that it is accessible to other mobile requests for the same database. There is only one copy of the cache for a particular database active at anytime (recall that eonetservice is already mutli-client, multi-database enabled). This results in several hundred MB of ram being saved during peak simultaneous operation of mobile devices.
The cache is refreshed automatically. While bringing up has always been quite speedy even for large databases, not having to do so has yielded a marginal performance gain per web transaction. That is, there has been no trade-off of speed versus space in this scenario. Both performance and memory management have been improved without compromising robustness.
As far as validating the operation, a simple maintenance op is needed (sync a handheld, change something in the master records like a customer license number, then sync again within w3wp cycle time of 20 minutes by default)
In the lab, combined with the garbage collector modification notice, the enhanced eonetservice shows a working memory peak of around 300Mbytes for a very large customer database… and it does not creep upward.