You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2003/12/20 16:06:27 UTC

[1.3] any reasons not to switch to hsregex on Solaris?

We use hsregex on older Solaris (2.0-2.5 or something like that). 
Theoretically maybe something stops working or starts working when the switch 
is made, but beyond that theoretical possibility does anyone have real 
knowledge that there is a non-trivial likelihood of that occurring or that 
actual problems have been seen when this was done?

I've dealt with a couple of severe performance problems with regular 
expressions recently with a 1.3-based server on Solaris 8.  There has been 
ample opportunity to hear such reports on other platforms that use hsregex, yet 
I haven't heard anything.

In one of the cases, I was able to compare the expensive expression match on 
Solaris vs. AIX.  The AIX build, using hsregex, had slight degradation (~10%), 
whereas the Solaris build, using native regex support, consumed multiple times 
the normal CPU.

In the current case, where it seems to loop forever in the regex code, I know 
the AliasMatch expressions which are being evaluated but not what request 
triggered it.  (I should have had the customer enable ExtendedStatus and then 
check the server-status entry for the high-cpu child before they had to kill it 
:(  )  The only AliasMatch directives look like this, one per vhost:

AliasMatch ^(/.+)+(/.+\.css)$   /foo1/foo2/foo3/css/$1/$2

Probably I will end up building them a server using hsregex and get them to see 
if the problem reoccurs.


Re: [1.3] any reasons not to switch to hsregex on Solaris?

Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
> We use hsregex on older Solaris (2.0-2.5 or something like that). 
> Theoretically maybe something stops working or starts working when the 
> switch is made, but beyond that theoretical possibility does anyone have 
> real knowledge that there is a non-trivial likelihood of that occurring 
> or that actual problems have been seen when this was done?

just to follow up on a previous stupid question:

100% likelihood of binary compatibility breakage since regmatch_t size 
changes, and Apache modules deal with size and layout of that structure :)