Processing Efficiency of multiple HTTP Class Profiles

What are you using the HTTP class filters to do? Are you sending some requests to one policy and others to a second policy or direct to a pool? Or are you dropping all undefined URIs?

 

 

I'd guess the difference between adding a separate HTTP class and adding another URI to an existing HTTP class would be negligible. I think the best option is whichever you think is easier to manage.

 

 

Aaron

There are certain characteristics which are common to all of our applications, and I am considering writing a separate HTTP class to handle each of those individual characteristics. So for example each of our applications has a status page, so I would create an HTTP class to handle it. The profile would look for the status URI specifically, and define the various characteristics of this resource that ASM will allow.

 

 

Another characteristic of our apps is the cookie handling of our authentication and authorization package. I would create an HTTP class policy specifically targeted at handling these cookies, such as specifying their maximum length.

 

 

Then I would apply these two policies to all of the Virtual Servers that use them in addition to a third, custom HTTP class policy developed specifically for each application. Processing order would be:

 

1. Status profile

 

2. Authentication profile

 

3. custom app profile

 

 

None of these ASM policies would send traffic to a pool. The Resources properties of the VS would continue handling that function.

 

 

Obviously another approach would be to combine all of these characteristics into a single HTTP Class Profile and apply that profile to a specific Virtual Server. The downside is that I would have to re-create 1 and 2 for each app. I am wondering which is more efficient in terms of ASM processing - an architecture with modular HTTP Class Profiles that I can reuse across multiple Virtual Servers, or one with a single HTTP Class Profile for each app with some duplicate properties.

 

I don't think there is any significant difference between having multiple HTTP classes. However, if each of the HTTP classes has app security enabled then there might be some overhead in having a lot of web applications and their corresponding policies. I don't think it would be a big difference though. Does anyone else have thoughts on this?

 

 

If you think the status and auth portions would require changes, and those changes would need to be replicated across all of the apps, it might be easier to administer if you break out the status and auth portions of the app. On the other hand, if you think it would be harder to administer more policies, then you could combine them. Again, I think it's a matter of which methodology is easier to maintain. I don't think the difference in performance would be significant.

 

 

Aaron