XaaS Request Page Performance

[LenK]

About 2 years ago when we really started to expand our private cloud offering, we found the standard request page lacking so we moved to XaaS/ASD wrappers for all IaaS blueprints.  We have been able to deliver a much more dynamic UI but the overall user experience is suffering due to performance (delays during the request entry).

The largest delays occur when one request field is associated with an input variable on another request field that in turn leverages External Values (vRO Action Items).  It seems that anytime a request field that’s mapped to another as an input value is modified, the action executes resulting in delays. We have attempted to use conditional values to limit when external actions are executed but regardless of how we set these up our user experience is not great given the number of fields we have that depend on other fields.

Has anyone else that’s using XaaS wrappers encountered similar performance issues as the complexity of your request page grows?

[SeanKohler]

Well LenK...

1. Our environment will not be as large as yours.

2. Our forms will not be as complex.

That said... yes we have had performance issues. What performance problems we did have, we tried to reduce by...

1. Reducing the complexity of our underlying architecture.  (move to monolithic vsphere clusters, supernets, etc)

2. Reducing the complexity of the form.

3. Using other object types that got string value returns at a faster clip.

4. Moving some up front request values to Day2.

5. Running conditional ognl statements instead of actions to make logic determinations before action runs... where possible.

(Are these latter ognl conditional statements what you also mean by conditional values? --- #variable=="condition"?true:false)

Now that the combination of external action calls in IaaS forms AND event driven architecture (subscriptions) are possible in 7.x... we are switching our XaaS Build Any Machine Anywhere types of forms to IaaS forms, collecting request properties, and then managing the build of the machine based on the custom property selections.

[SeanKohler]

For example... we created naming uniformity for our blueprints so that I could take text based values in this section to build the blueprint name.  Then in execution I lookup the blueprint for request based on a joined string in a known format. 

This way I don't need to bring the blueprints up into the form. (which was slow)  Strings up to the form are fast.

[admin]

I noticed that if you use attributes that have values pointing to IAAS entities on the workflow that is being called by ASD, i.e the top level workflow, the attributes load at runtime. In this case, the loading time then becomes slow as it needs to look up the attibute values at runtime.

[cgaya]

Hi, we have been having the same problem and are looking for solutions to increase Request Page performance.  We currently have a form that takes about 10 seconds to "reload" when selecting specific elements that other elements use as inputs to external actions.  It's pretty unusable.  We have found that there does not appear to be any rhyme or reason to the order in which the actions are being called, the actions are being run twice for some reason (used to be 3 times in vRA 7.0.1 - since the 7.2 upgrade it is now just twice), and that the actions are run serially with a 200-300 delay between actions.  This really adds up when 9 different external actions are being called (twice!) to determine field visibility and/or drop down values. 

Basically, we have two fields up front that a user must select:  BuildSpec and Environment.  The first basically defines the type of machine we are building, and the second defines which environment it will be placed in.  From this info we can query and intersect our Chef roles/environments and the BuildSpec itself to determine network/cluster placement, platform type (which controls the IaaS Blueprint to use), # of CPU's, RAM, and some other custom attributes used during deployment.

I have tried putting our basic elements on one page and all other elements which rely on these values on another page on the XaaS form, but the actions on the second page still run in the background when changing elements on page 1.  I also tried setting the Presentation layer in vRO to separate the elements into different pages as well.  This also had no effect on when external actions dependent on the BuildSpec/Environment were run.

What we really need is one or more of the following...

• A way to run actions in parallel rather than serially (time savings would be huge here)
• A way to control the order in which the external actions are being run
• A way to better control what changes trigger external actions linked to other elements
• A way to minimize the delay between actions being run
• A way to control the visibility and/or values of multiple elements from a single external action that returned a composite object type that had all the necessary fields.  We could then use these values directly instead of calling external actions again and again.
• Alternatively a way to embed an iframe or something into the XaaS request screen which would be a page we have complete control over so that we can create a truly customized and optimized request form for our needs.  We could of course build this page and direct users to use it, but it's not ideal to tell our users to request machines here, but manage them somewhere else entirely.

If anyone has any ideas on any of the above, we would appreciate it!