Hi all, Paolo Lucente, 16.11.2006 02:03:
> Now, back to our syncronous approach: what was killing it was the excessive > slowness the database and the concurrent arrival of packets at very high > rates. Keeping the two entities (network and DB) asyncronous, segregated, > gave a big relief and better performances (under normal conditions). Things > that were requiring to be written down at the time were: a way to establish > a kind of normal database behaviour in order to promptly react to excessive > slowness, how the process can understand when to give up (pretty variable) > and, of course, how to react, ie. what to do if data continue to accumulate. of course separation of metering and DB access is a good thing. But I think what Chris is suggesting is to have the write-to-DB jobs queued in one single writer thread rather than creating a new thread for each job. I also have the feeling this might be more effective, but it's just a feeling, I have no clue how much new resources an additional thread really needs. Of course, if the data is coming too fast for the DB, it is to fast, no matter how the writer is organized. But if you use more resources for other stuff (like creating new threats) you might reach this limit earlier. Cheers, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
