rlm_sql: %{sql:<long query>} - length limit

[Alan DeKok]

Paul TBBle Hampson wrote:
> Or talloc, which lets you allocate hierarchially, so when you delete
> a request, all the stuff in it gets deallocated as well, without having
> to guess ahead of time how much space it's all gonna take.

  I've been following Samba for a while.  talloc is nice, but I think
it's way overkill for what we need.

> And it has destructors.

  Which I don't think we need.

  For RADIUS, all memory allocation is either global, per-module
instance, or tied to a REQUEST.  The memory pools are probably best used
for REQUESTs.  My tests indicate that malloc/free overhead for a REQUEST
with few VALUE_PAIRs can be up to 10% of CPU time.  So fixing that would
help performance, and would likely simplify the code.

  What's in a REQUEST?  RADIUS_PACKETs, VALUE_PAIR's, and not much else.
 They don't need destructors on exit, so that overhead in a memory pool
can be lost.  We don't need thread locks on a REQUEST, as the server
design guarantees that only one thread is accessing a REQUEST at a time.

  I think we can have simple 2k-page memory pools with only 100 to 200
lines of code.  And, that means no external dependencies, either.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog