Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm dealing with a hosting team that is fairly skittish of managing many rewrite rules. What are your experiences with the number of rules your sites are currently managing?

I can see dozens (if not more) coming up as the site grows and contracts and need to set expectations that this isn't out of the norm.


share|improve this question

closed as primarily opinion-based by larsks, Dave M, Christopher Perrin, mdpc, Ward Aug 9 '13 at 0:25

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

The fewest you can get away with. – John Gardeniers Apr 9 '10 at 3:36

Are they concerned about the logistics of managing many rules, or the performance?

In the former case, consider combining a hashmap generated from a DB, managed by either your CMS or a CRUD tool if, like Alex, most of your rules actually come from things like content moves and marketing campaigns. They can be tested by your content people and then migrated into production with little effort for your server teams.

If the problems is performance, well, that's a "how long is a piece of string" question, but I've certainly worked on sites with literally hundreds of rewrite rules to support things like content migrations where there's been no measurable impact on the response times for the servers.

share|improve this answer

You could consider using which would allow a single rule read from a hashfile.

share|improve this answer

We recently had a practical experience about this. See my answer here:

I had the very same question recently. As I found no practical answer, we implemented an htaccess 6 rules of which 3 had 200,000 conditions.
That means an htaccess file with the size of 150 MB. It was actually fine for half a day, when noone was using this particular website, even though page load times were in the seconds. However next day, our whole server got hammered, with loads well above 400. (machine is 8 cores, 16 GB RAM, SAS RAID5, so no problem with resources usually)

I suggest if you need to implement anything like this. Design your rules, so they don't need conditions, and put them in a dbm rewrite map. this easily solved the performance issues for us.

share|improve this answer
Welcome to Server Fault! Generally we like answers on the site to be able to stand on their own - Links are great, but if that link ever breaks the answer should have enough information to still be helpful. Please consider editing your answer to include more detail. See the FAQ for more info. – slm Aug 8 '13 at 8:33
@slm: That is a link to an answer on another StackExchange site. If that link ever breaks this site is probably going with it. – larsks Aug 8 '13 at 10:33
@larsks - true but how hard would it have been to add some context to the link? – slm Aug 8 '13 at 11:12
Or better yet, copy and paste. – Michael Hampton Aug 8 '13 at 12:54
sorry about it. would have probably quoted if it was an external site... – Gergely Zsamboki Aug 12 '13 at 11:27

Obviously everyone is going to have a significantly different number of rules to manage depending on individual situations. I would guess that dozens of rules are not uncommon. We typically use rewrites to deal with things like content moves, technology changes. Our marketing department is constantly coming at us with search engine optimization requests for things like expired content which we typically handle with a rewriterule. We also end up handling things like marketing campaigns that get printed specifying a URL that doesn't exist, so we make it valid by adding a rewriterule.

For a comparison, at my organization, we have 140 rewriterules spanning 19 subdomains in our production environment.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.