Forum Moderators: phranque
I don't deal with Apache, then I ask orientation about the code below. I need to know if the code is done properly, since I heard many times that rewriting urls in the .htaccess can have big performance issues.
RewriteEngine on
Options +FollowSymlinks
RewriteBase /
RewriteRule ^products/([a-zA-Z0-9\]+)/([a-zA-Z0-9\+\ ]+)$ index.php?section=products&category=$1&title=$2 [L]
RewriteRule ^news/([a-zA-Z0-9\]+)$ index.php?section=news&newsid=$1 [L]
RewriteRule ^articles/([a-zA-Z0-9\]+)$ index.php?section=articles&articleid=$1 [L]
I appreciate any help.
Best regards,
- Michaelsen
([a-zA-Z0-9\]+)
([^/]+)
As far as performance goes, the issue isn't so much one of the *nature* of your mod_rewrite rules in a .htaccess file, but simply the fact that they're there at all. More information about this is documented at [httpd.apache.org ], in the 'API Phases' section.
Looking at the API Phases I found something I'm not quite understanding.
"While URL manipulations in per-server context are really fast and efficient, per-directory rewrites are slow and inefficient due to this chicken and egg problem."
What does this exactly means? Maybe I'm doing something very bad.
Best regards,
- Michaelsen
No, not bad. Running code in .htaccess is comparatively slower than running the same code in httpd.conf, but unless you have a huge .htaccess file and a very busy site, it's no problem.
While it is good to be concerned about making things as efficient as possible, never forget that the computers are supposed to work for us, and not the other way around...
If you have a fairly busy site -- >10,000 unique impressions per day, then this may be cause for concern. Otherwise, the standard advice applies: Start with small .htaccess code, optiize it for efficiency, test it, and then evaluate the impact on your server's performance.
Just as a metric: I have a site where the main .htaccess file is 35kB in size. The site gets around 2,000 unique hits a day. I cannot measure any performance impact -- If there is an impact, it is buried in the time to process SSI, PERL scripts, PHP, and database lookups.
Jim