I hope BMC is reading this! Sent from my iPad
On Mar 4, 2012, at 1:18 AM, John Baker <jba...@javasystemsolutions.com> wrote: > Andrew, > > I don't understand why this problem hasn't been solved either, given it's not > difficult to solve. At JSS, we have to restart AR System and Mid Tier when > performing webex installations of SSO Plugin, and we often spend more time > waiting for AR System to restart than we do installing the product. Whilst we > can't fix AR System, I did ponder how best to resolve Mid Tier's caching > issues and stumbled upon a solution when I recently wrote to ARSlist > suggesting workflow should be cached as flat files. > > Every form has a set of dependencies and a last modified time, and therefore > each form should be held locally as a javascript file. Consider the home > page; the Javascript on my Mid Tier is served by the following URL: > > http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js/3d2a292f.js?format=html > > (The URL is bizarre; format=html yet the content is Javascript?) > > You can login to Mid Tier, go to the home page, open another tab and paste in > this URL to see the JS: > > http://host:8080/arsys/forms/192.168.0.54/Home+Page/Default+Admin+View/form.js > > I've looked at the contents of my Mid Tier and I can not find this JS file, > so I can only assume it's being generated on the fly and hence the workflow > is being held in memory. And that seems to describe your problem: Mid Tier is > loading all of ITSM into memory, which is extremely inefficient and results > in huge VM sizes. > > The solution is remarkably simple: Build a local cache of Javascript files > for each form/view as a user navigates ITSM. Once the Javascript file has > been written to disc, it only needs to check the last update time on a form > and associated workflow before serving the Javascript (in development mode), > or simply serve it without checking for workflow changes in production. > > With such a small change in design, you would see the following benefits: > > * Instant Mid Tier start up times, no "pre-caching", low memory footprint > (like 256Mb VMs), much better performance, etc. > > * Cached Javascript could be moved from Mid Tier to Mid Tier, so your problem > with 2+ Mid Tiers would go away. > > * Transparency. You can delete a form's Javascript confident that it has been > removed from the cache (because Mid Tier would notice it wasn't there and > rebuild it). > > * Provision for a decent debugger. If the workflow to Javascript engine is > improved, so well formed and readable Javascript is written, you could attach > Firebug or one of many Javascript debuggers and start debugging workflow with > the same level of precision as developers using other platforms. Sure, this > is possible right now, but you can't go and modify the Javascript. > > * Writing workflow without writing workflow: If you've got local Javascript, > dab hands would be able to quickly try out changes without having to get out > developer studio. When they're happy with the changes, they can enter them as > normal. > > The irony is that BMC are 90% of the way there because they've got all the > pieces of the puzzle: they just need to re-write the caching routine again to > store files locally, and none of this is a terribly difficult task. > > > John > > -- > SSO Plugin for BMC ITSM, ITBM, Dashboards and Analytics > http://www.javasystemsolutions.com > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
