Has anyone encountered performance issues with large doc.'s with multiple sub doctypes within developer 6.0.1 ?
Mary if this issue only a development issue than its not a performance porblem! Performance normally an attribute of system in runtime or test/production environment. Can you please elaborate on what you mean by performance porblem in developer 6.0.1? And also give some idea how large is your nested documents in byte size?
Hi Igor,
Perhaps I lead you astray with the question. I was having a problem with performance issue of a package which contained a document type created from a schema with many sub schemas. The schema was created from XML. Every time I access this package which contain all these document types, the developer’s performance is deadly slow.
The performance will probably affect production since we have the same setup, memory, etc. on the production box. Not sure if this would help, but if I zipped up the package, the size is 380KB.
TIA
In production IS would not be sending the Document definitions across the wire, but they will be in memory, so you are correct that the amount of RAM the IS JVM will need may be an issue. Keep an eye on the IS Administrator Statistics screen to make sure RAM isn’t a server-side problem.
For your current problem, you may need to increase the amount of RAM the Developer JVM has available (I think in developer.bat). Also you can set the number of elements to cache in the namespace browser on the Developer Tools | Options | General panel. If there are lots of sub-documents (like over 100) then you may want to increase the RAM and increase the cache amount to avoid repeated requests to IS.
HTH,
Fred
you may have IS general hap memeory issue. But I would also check that all those sub documents are actually exist and all refernces inside WM Document are valid! Normally Developer does not have problem with large nested documents as long as all elements find their refernced dcuments or schema elements! When some are missing Developer keep looking in namespaces an that can take long time. Depending on how schema is built nad what tags are used to refernce other schemas and elements webMethods will apply some rules and some of the documents will not have a schema created but document is embeded inside. that also means that instead of ref tags your document repeating same elemts and therefore make it too large when its not need to be.
Thank you both Fred & Igor. I’ll certainly have to play around with both your suggestions.
Mary
Mary,
Igor was correct when he spoke about the way the document/schemas are structured. I worked on an XML Schema definition project that ended up as one of the downloadable industry solution xml modules. When I started, the package was 117MB. When I finished the project by correctly referencing all of the document/schema elements, the package was about 6.5MB. Performance was never an issue. For me, the problem was the size of the package. It was way too big to distribute.
By the same token, if you have references to items that are not there, then you may be giving the developer/server extra and unneeded work. You can check the error log to see what is going on. If you cannot see anything, you can raise the logging level to 6 or 7. Normally, it is at 4 for development.
HTH
Ray
Thanks Ray. I’ll up the logging level and watch the log closely.
Mary
Mary if you familiar with XML schemas and your own package you can easily check from developer and Schema if all elements are there or not just by looking at what developer has loaded and what should have been based on schema. Also if something missing normally ref elements in developer show up as (Element Not Found). But if these options do not work for you. Setting log level up to 6-7 will also be helpfull as Ray has decribed.