--- Alan DeKok <[EMAIL PROTECTED]> wrote: > Alexander Serkin <[EMAIL PROTECTED]> wrote: > > Do you mean just comment out line 1012 in > request_list.c ? > > Yes. > > > I think i'll try this first because speeding up DB > is not a trivial task > > by now. > > But it's the real source of the problem... >
How large a DB is this? And what type of link is there between FR and the DB? Unless there are, literally, (tens of) thousands of records and/or a *slow* link (think "dial-up") and/or ancient hardware there should be some reasonable ways to speed up the DB response. Archiving of records and indexing are two that come to mind first. More complicated, but effective, would be clustering or optimization, even review of the DB version (deprecated?). Alan is correct, you are "fixing" (hiding) a symptom, and I can say from personal experience it *will* bite you in the butt at some point :) The worst part of it, too, will be that the new issue may not be clearly linkable back to the FR problem you have currently and you may not remember this piece of the puzzle. Patching also breaks your upgrade path... Just some friendly advice. Laker > Alan DeKok. > -- > http://deployingradius.com - The web site of > the book > http://deployingradius.com/blog/ - The blog > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html