[thelist] Link security and performance

[Judah McAuley]

On Fri, Feb 5, 2010 at 11:43 AM, Bill Moseley <moseley at hank.org> wrote:
> On Fri, Feb 5, 2010 at 10:38 AM, Judah McAuley <judah at wiredotter.com> wrote:
>
>> I think you are making unwarranted assumptions about the cost of
>> certain behaviors. That's known as premature optimization.
>>
>
> Thanks.  That's the normal approach we have taken.  It's been a bit more
> work trying to retro-fit in caching since it's not been part of the initial
> design.  It's a trick finding good balance.  Don't want to think too much
> about optimization up front, but also don't want to be sloppy.

Certainly and one risk mitigation strategy there is to try and
identify before hand which parts of the system will be most difficult
to change later and spend more time on those up front.

I have a notification system that uses a rules-based engine for
figuring out who needs to be contacted with what info based on which
rule. Unfortunately, the original design of the system made the choice
to put that engine execution at the end during the time we are
contacting, going through each rule and figuring out what it ought to
contact.  This has the downside of being 1) inefficient because the
heavy lifting is happening during the contact period and 2) makes the
system opaque as it is very difficult to answer the question "who will
be contact today and what will we tell them" ahead of time. You'd need
to run the entire rules-processing method just to answer that
question.

So now, some 3 years on, we are finally getting around to reworking
that piece and flipping it on its head, running the decision logic on
each contact as it gets imported, figuring out the best matching rule,
then storing that result so that the actual contact process can be
dead simple and multithreaded, just saying "grab a contact, do what
the contact says to do".  But it took this long to make the change
because that process is the fundamental part of notification system
and everything tied into it with insufficient separation.

>> Code it right, first, so it is logically correct and works. Then find
>> the true bottlenecks and fix them.
>>
>
> That's kind of the stage we are at. ;)

When it does come to fixing the bottle neck problems, do look into
pre-computing results. In a permissions example, permissions can be
either checked at runtime or precalculated. Which one will perform
better depends on how complex your permissions are (cascading
inherited permissions versus simple object level permissions) , how
many users will have some access to each object and how often the
objects/permissions change.  In my case above, once a contact is
imported, I can safely go through the rules engine and determine its
final fate. If the rules change after the contact has been imported,
it is ok within my system that the final fate not be changed, all rule
changes are forward looking only. If that were not the case and I
would have to recalculate the fate of each contact and handle
potential conflicts where the new rule change would produce an
undefined situation, I might reconsider my solution, asking how often
will rules change? How will I deal with resolving conflicts? etc.

Hope this gives you some useful ideas and good luck with your project.

Judah