[dns-operations] DSCng 0.1.0

Bedrich Kosata bedrich.kosata at nic.cz
Wed May 15 07:05:38 UTC 2013


Now that I read my post again, I found out that all your questions were 
about the collector, not the presenter.

Unfortunately, I am not on the operations side of things, so I have no 
experience with the resources that the DSC collector consumes :(

Best regards

Beda

On 15/05/13 08:53, Bedrich Kosata wrote:
> Hi Peter,
>
> as the data are aggregated on the collector, it does not change much
> with the traffic but mainly with its variability.
>
> For the data we collect at .cz, storage requirements are roughly 1 GB
> per year per server. The typical size of the files transferred each
> minute from each server is about 70 KB (10 KB gzip compressed).
>
> As for CPU utilization, this is hard to answer. Part of the CPU time is
> needed to process new data, but this is more an I/O intensive job and
> depends on the performance of your database. Most of the CPU time is
> consumed when serving data to clients and this of course depends mainly
> on the number of clients concurrently visiting the website. Currently we
> do not do that much caching on the server side, so each client request
> results in a new database query. In future, this will certainly be one
> of the areas where optimizations will be added.
>
> Best regards
>
> Beda
>
> On 14/05/13 13:55, Peter Andreev wrote:
>> Hello, everybody,
>>
>> I have never touched DSC, but I'm dreaming to replace our present
>> statistic system, so I have some questions:
>> Assuming qps about 10k to 40k,
>> How much disk space the collector utilizes for its needs?
>> How much traffic the collector generates in case of default installation
>> (when data is being sent to presenter every 60 seconds)?
>> And, of course the collector's CPU usage in mentioned conditions.
>>
>>
>>
>> 2013/5/14 fenghe <fenghe at dnsbed.com <mailto:fenghe at dnsbed.com>>
>>
>>     于 2013-5-14 18:55, Bedrich Kosata 写道:
>>
>>         I think that the biggest weakness of DSCng is that it has not
>>         seen much
>>         real-world usage, so there will probably be some rough edges to
>>         smooth
>>         in future releases. Any feedback is most welcome.
>>
>>
>>     I have the idea to deploy it in my product server, but it needs some
>>     time, currently I am a little busy.
>>
>>     Regards.
>>
>>     _________________________________________________
>>     dns-operations mailing list
>>     dns-operations at lists.dns-oarc.__net
>>     <mailto:dns-operations at lists.dns-oarc.net>
>>     https://lists.dns-oarc.net/__mailman/listinfo/dns-__operations
>>     <https://lists.dns-oarc.net/mailman/listinfo/dns-operations>
>>     dns-jobs mailing list
>>     https://lists.dns-oarc.net/__mailman/listinfo/dns-jobs
>>     <https://lists.dns-oarc.net/mailman/listinfo/dns-jobs>
>>
>>
>>
>>
>> --
>> AP
>>
>>
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> dns-jobs mailing list
>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>>
>
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>

-- 
Bedrich Kosata
CZ.NIC Labs <http://labs.nic.cz>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4276 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130515/9cca9d28/attachment.bin>


More information about the dns-operations mailing list