Users changing rules IS the correct use-case of drools (I would even say that if rules
never change, drools is likely to be worse than pure java).
What others said is "changing the rules at each request by regenerating and
recompiling" is not.
I can't imagine that users may change rules at each request, so you must have, at
least for some time (thus a lot of requests), a stable rule base.
What is costly is to compile rules, but you already know that.
So the idea is to keep in some kind of cache the actual rules, and only recompile them
when they change.
The source of rules does not matter : you can generate the DRL according to your
configuration, or make you users directly write rules (with guvnor, which will fits well
if your rules are only basic filters).
The optimisation you have to do is to keep your compiled rules somewhere (by serializing
your KnowlegdePackages or simply keep it in a kind of map), and reuse it until your source
change : you have to find a way to detect that rules (or the config that is used to
generate them) have changed, and then recompile a new up-to-date KnowledgePackage.