I haven't downloaded the newest code yet, so forgive me
if this is what you are headed for.
I've been using acid for a few years and have had to
look at the code several times. In my mind, it's a
great free initiative, but is quite a mess compared to
object oriented design techniques expected today (and
available via PHP5).
Have you ever thought of refactoring the whole shooting
match and redesigning the whole thing to be able to
ONLY work with PHP5, using classes, interfaces,
iterators, etc.? Goodness, wouldn't this
maintainability be music to your ears?
Some other things I've checked out, considered, learned.
Way back when, I did a performance test in PHP4
comparing thousands of "$mystring .= "some more text"
versus "$myvar = $myvar . "some more text" and the
former was orders of magnitude faster.
Seems I recall there was a code versus index problem
somewhere. Indexes typically can't be used unless the
left-most field of the index (same for all fields
working your way to the right) is in the where clause.
So, for instance, if an index contains sid/cid, a
query that just uses cid can't be used because sid
wasn't used. Another thing is that indexes should be
created with the greatest cardinality available, which
means the index should start with cid first (less
repetition than the sensor pk/number). I can't recall
if this was an acid problem.
I realize the theory behind using the multiple primary
key, but I think it is the root cause of lots of
performance problems. MySQL is famous for being
blazingly fast, but ACID is infamous for being
make-you-cuss slow. The Snort/ACID database is
probably too normalized for the environment (validated
by SQUIL), and I can't see how the multiple key joins
can be helping that.
I've used MS SQL, Oracle, and MySQL, but only have
MySQL experience with ACID (which I think is the most
used combo by far). I remember (I think) the ACID code
using table locks to insert alerts using the MyISAM
data storage engine. Table locks are a huge problem if
you are inserting records while a user wants to make a
request. Or, if a user sits on their thumbs while
records are added to the alert cache. Lately, I've
been wondering if anyone has done any performance
checks using the InnoDB table storage engine and no
hard-coded table locks? InnoDB is supposed to be
slower than MyISAM, but hey, if the table is constantly
locked, speed doesn't mean anything.
Finally, I know I'm probably pileing on performance
drags here, but have you guys considered using a
templating engine (something like smarty) to separate
the code (classes baby) from the presention? This
might be a hit, but it also might allow huge numbers of
users to tweek a little bit of screen real estate to
their own desires, plus, allow more people to
contribute (designers, coders, css'ers, etc.).