[rsyslog] RFC: On rsyslog output modules and supportforbatchoperations
Rainer Gerhards
rgerhards at hq.adiscon.com
Tue Apr 21 07:31:24 CEST 2009
> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of RB
> Sent: Monday, April 20, 2009 9:16 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] RFC: On rsyslog output modules and
> supportforbatchoperations
>
> On Mon, Apr 20, 2009 at 13:09, <david at lang.hm> wrote:
> > is it really any more efficiant to define a stored procedure or
> prepared
> > statement through the API than through the exec() call?
> >
> > and even if it is, is this something that is done once per startup or
> > every command? if it's once per startup the complexity cost may not
> be
> > worth the small time savings.
>
> I don't have numbers on the overhead bit, there are application notes
> for MySQL (http://dev.mysql.com/doc/refman/5.1/en/sql-syntax-prepared-
> statements.html,
> paragraph 2) that notes that the SQL interface is not as efficient as
> their binary protocol, but gives no justification. I won't argue
> whether binary protocols are faster, but agree with the assertion that
> the gain may not be sufficiently significant in this use case.
My main concern was that we could not do those things with a "string-only"
calling interface. As I now know we can, I don't see any performance problems
for most cases (it may be different in those rare cases where every cycle
counts, but they should be very, very seldom). I think I can even formally
proof that the overhead is not significant if the batch size is sufficiently
large (> 500). Let me check the priorities, probably I'll do the proof.
Rainer
More information about the rsyslog
mailing list