Multiple wildcards forcing 100% CPU usage

[pvcomm]

Hello,
I just recently noticed that some people are trying searches with upwards of 15-20+ wildcards in the search field. Something like *********gr*********. This is causing the Application Pool that the website runs in to consume 100% of the server processor.

I don't want to turn wildcards off on the website. Is there a way to limit this, or remove them completely from the posted form. I've already modified the search.asp to force every search to be a wildcard search so having a user enter them is pretty much pointless.

Any help with this would be much appreciated.

Thanks!

[David]

Wild card searches are more computationally intensive than single word or multi-word searches. However 15 wild cards in a search string should not be significantly worse than just two, **. Doing a search for ** will match ALL words in the dictionary, and thus all pages on the web site.

However the real problem is the poor performance of ASP. I would suggest switching to using the CGI option. The CGI option will perform 10 to 50 times faster than ASP for wild cards.

The CGI option not only runs quicker, it will use less RAM and CPU time.

I've already modified the search.asp to force every search to be a wildcard search

This is bad for 3 reasons (in our opinion). 1) We provide an option to do this in the Zoom configuration window that would have avoided writing custom code, on the languages tab. 2) Performance will take a hit on every search, even for searches that didn't need a wild card. 3) Automatic invisible wild cards can confuse users who expect more Google like behaviour.

[Ray]

We did some testing, and it proved that you are correct that using multiple (unnecessary) asterisks wildcards did slow the script down, the more consecutive asterisks you use. This was unexpected, as we are using the defacto Regular Expressions features of PHP and ASP to do this.

This does NOT occur on the CGI version, where we use our own implementation to achieve this.

We will fix the problem in V6, by stripping out consecutive asterisks in search queries ("***test" really means exactly the same as "*test", from a functional point of view, so theres no need for it). We will also post up the code change to apply this to V5 when we do this.