Bob, Have you tried DS 7.6.xx? Many of the DS operations were move from the Admin thread to a List thread starting with DS 7.6.03. DS now only takes an Admin thread if it needs it (typically saving). DS 7.6.03 has a number of improvements. I talked to the DS lead quite a while at WWRUG10 (and WWRUG09 for that matter) and verified that it is safe to use a 7.6.03 DS with an AR 7.5 system. If DS sees it is connected to a AR 7.5 server it will not give you the options that are not valid for AR 7.5. There are some features that are DS specific such as the way threads are used as well as a cool new "Open In Browser" function that are not dependent on the AR Server version.
Regarding caching I have noticed there seems to be some caching done. If I try to open a object that is reserved by somebody else I need to refresh the list of objects (after asking them to release it) before DS shows it is available and I can reserve it. While I have noticed some occasional delays and crashes (not nearly as often with 7.6.03) our system is by no means painful do dev work on. The Admin Tool also had it issues with delays when loading objects too. Admittedly I am about 300 feet from our the servers. One thing I have noticed, and I am not sure if this is related to chattiness with the server or DS is just better aware of the changes you are making and objects you already have open, is that I can modify one object (say add a field to a form) and a workflow object (AL/Filter) that I already have open is aware of the new field without having to close the workflow object. I find this to be a nice improvement over the Admin Tool. I understand completely a dev tool that is constantly making you wait is extremely frustrating and makes it just about impossible to work with. I am just wondering if the problem is really DS or something else about the environment? Have you run a sniffer between your machine and the server? Do you know that the issue is a chattiness issue? If you cannot run a sniffer a server side API log should also show chatty behavior. Are you on the same network as your Remedy server, within fairly close physical proximity? Or are you working over global network and/or over a VPN? Jason On Mon, Feb 14, 2011 at 2:44 PM, Robert Halstead <badbee...@gmail.com>wrote: > ** Forgive me as this is more of a rant. > > My patience for Remedy Developer Studio 7.5 is growing thin. I find that > performing the most insignificant tasks become a test in patience as the > tool communicates to server for every single action. > > Selecting a field on a form, talk to the server to get properties. > Selecting multiple fields, talk to the server to get all properties. > Select a field in a web service definition... > > The latter will take quite a bit of time if you have a lot of fields on a > form. > > I'm getting very frustrated with the performance of the Developer Studio.. > I wish that the tool cached the objects from the database like the Migrator > does and only updates when needed or when the developer forces the refresh. > Even have a periodic refresh would be nice.. > > I wish that the tool wasn't so chatty back to the server. It doesn't make > sense that when object reservation is enabled, that the tool would need to > go to the server for each field (like it would have changed since I have the > form reserved?). > > Right now I'm pulling my hair out trying to modify a web service operation > we have on one of our forms that has 100+ fields. Every time I remove / add > a output mapping field, the developer studio does some mass server > communication that takes about 30 seconds. To do what exactly, I'm not > sure... If I have the web service object reserved, why would it need to go > to the server for changes or whatever? I haven't even saved the object > yet... why is it talking to the server?? > > Why can't it just load the entire web service object and the form it > references into a cache so that the "user experience" is fast and snappy > after the initial load? Then when I save the web service, perform the due > diligence to ensure the mappings are correct. > > I have used the knowledge base to look for "enhancements" and tricks when > using the developer studio, but alas it seems no one else suffers from this > issue or no one has encountered it / reported it. > > It would be nice if BMC provided configuration settings that we could pass > to the developer studio to configure how we want the tool to act and when we > want the tool to communicate to the database or put more options in the > preferences to configure the performance of the developer studio. > > Perhaps something greater than just adjusting the memory that java uses... > Perhaps there could be a white paper on database optimizations that would > help the developer studio perform better. > > It would also be nice if while we are waiting for a form or other object to > load, that a progress bar is displayed or something that tells us what the > tool is doing. Most of my time spent in the developer studio is the "white > screen" as the tool becomes unresponsive during save's or object retrievals > from the server.. As a developer, I want to know what the tool is doing so > that when I complain to BMC that the performance is slow, I have a point of > reference. If I know generally what is going on, maybe I can optimize the > database so that the operation is quicker? Who knows! > > Whats frustrating is that after 1 revision and 7 patches later, I would > expect the developer studio to have all the bugs and performance issues > ironed out and be fast and snappy... Nope. > > How do BMC's Remedy developers program in this? Don't they get frustrated > with the NullPointerErrors and slow responsiveness? I'm guessing that they > just install a remedy server on their local box to avoid the performance > issue of the network. > > I think the development studio is a giant step up from the old Remedy > Administrator that we have all used in the past. But now that the tool is > main stream, there needs to be some serious work done to make the tool more > responsive and optimized when connecting over the network. > > Again, sorry for the rant, I just needed to vent. > > -- > "A fool acts, regardless; knowing well that he is wrong. The ignoramus acts > on only what he knows, but all that he knows. > The ignoramus may be saved, but the fool knows that he is doomed." > > Bob Halstead > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
