|
Q
|
Are there any performance trade-offs with reading BrowserHawk properties? When are all the non-extended properties automatically retrieved and set when the BrowserHawk object is initialized on the ASP page? Do subsequent property reads cause some functions / routines to run inside BrowserHawk to retrieve the requested property value?
We are using BrowserHawk in a very perfromance critical application, but we want to be able to vary which data we collect on users. Is it safe to retrieve all the non-extended properties, or should we only grab the ones we need, to speed up the page?
|
|
A
|
First a quick overview of COM and some performance related pointers (not specific to BrowserHawk but useful for performance purposes) is helpful. The first consideration is that regardless of whether it is BrowserHawk or some other COM component, there is a minimal amount of time required to access the value of a COM property. For example, even if you had a COM object called Foo, with property named Prop that had a hard coded value, it still will take a certain amount of time to retrieve the value and store it into a variable (a = foo.prop).
Generally speaking the time required to access a property value is negligible. However if your operation has critical performance needs in a very intensive environment, you can get the best performance by only accessing properties of COM objects that you definitely need to use. Also if you need to access the value multiple times from your script, be sure to store it in a local variable and then reference the local variable each time, instead of accessing it through COM each time (i.e. a = bh.browser; if a = "IE", as opposed to using bh.browser in several places).
Now more specifically, on to BrowserHawk. When the BrowserHawk object is created, BH first checks its DashCache to see if it has performed a look up for this particular browser based on its user agent. If so, it retrieves all the values from the DashCache and this is extremely fast and efficient. If the object is not in the DashCache, then BH looks up the user agent in its database and applies all the properties as defined by the database, then applies the user agent based filters (for more info on Filters see the BH docs), then returns this object and stores a copy into the DashCache. DashCache is available only in the Professional and Enterprise Editions. When performance is critical we recommend that you spend some time monitoring the DashCache settings in real-time using Performance Monitor (real-time monitoring with Perfmon requires the Enterprise Edition) and spend some time tuning the cache for your specific environment. For more information see DashCache in the documentation.
The next consideration regarding non-extended properties is whether the property has any non-user agent based filters defined for it. Many properties do not, but some such as Language, do. Since BrowserHawk is optimized for extreme speed and scalability, it does not apply any non-user agent filters unless you access a property which requires non-ua based filters. Once you access a property that has one or more non-ua based filters on it, BH dynamically then processes all the non-ua based filters for the object. This incurs a bit of extra processing time. Again, this time is extremely negligible but since the purposes of this article is to provide details on how performance can vary by accessing different properties, it is worthy to note that the first time you access a property that contains a non-ua filter there is some extra processing that occurs. If you then access other properties that have non-ua based filters, this has no additional processing as the work has been done by the first request for a non-ua filter based property.
Lastly is the topic of "extended properties". Extended properties are defined as properties which require a silent round-trip with the browser to fully interrogate advanced settings and controls, such as detecting disabled settings, plugins, and connection speed. For a full list of extended properties see the GetExtPropertiesEx method in the documentation.
To achieve the best performance when using the extended properties, it is recommended that you use the SetExtProperties method to ask BH to check only for those properties that you are interested in. For example, do not pass in "all" for convenience if you are only interested in detecting Flash. Also note that some properties, in particular JavaVersion, JavaVendor, Plugin_RealPlayerBuild, and ConnectionSpeed can add a few seconds to the time it takes to execute the check. Therefore you should only check these properties if the information they provide is important to your application. Lastly, while it is perfectly acceptable to check non-extended properties from every page (due to the optimizations with DashCache) we recommend that the extended property check is executed only once per user session, and you persist this data through session variables or a database, etc, rather than performing the GetExtPropertiesEx method from each page.
|
