Quoting you: "I have tailed the arsql log during my sessions using the 7.5 developer and can say that many sql commands are sent to the database per operation in the dev studio, which I expect for saves and refreshes, but again with only displaying field properties or adding an operation to an active link, why is it talking to the server? I would think it would have more cached about the server on initial connect."
I wanted to make sure that you knew that all definitions are stored in the database, not just ticket data. That means all field properties, workflow properties, forms, everything. That is why it makes so many calls to the DB. Everytime you want to look at a field, it needs to get the data from the DB. Now imagin anything with a qualification such as a table field, it needs to pull data for multiple objects, forms and their fields, and then decode an internal string into a readable string. Always lots of DB activity. Les Ganton > Thank you for the replies guys. A RDP is not possible as our server is on > a > unix machine. I admit that I am going through a VPN connection over cable > most of the time, but even when I am in the office the dev studio is > unchanged in performance. > > Thanks for the feedback Jason. I will download and try DS 7.6.03 and see > if > my experiences improve with that version *fingers crossed*. > > Our remedy servers are on a different subnet than our work stations (as I > would assume most companies are) and don't expect that to be so much the > problem as it's all inside our network. I do realize i'm on a VPN > connection however and do expect some delay, but what I have been > experiencing seems to be excessive. > > I have tailed the arsql log during my sessions using the 7.5 developer and > can say that many sql commands are sent to the database per operation in > the > dev studio, which I expect for saves and refreshes, but again with only > displaying field properties or adding an operation to an active link, why > is > it talking to the server? I would think it would have more cached about > the > server on initial connect. > > I have thought about going through the arsql logs, and one at a time, make > sure the proper indexes are being used or if we can add additional indexes > to the SQL commands as a last resort. > > Thanks again for the feedback guys, you have relieved a very frustrating > developer. > > > On Mon, Feb 14, 2011 at 3:28 PM, Jason Miller > <jason.mil...@gmail.com>wrote: > >> ** 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"_ >>> >> >> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > > > > -- > "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 > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > 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"
