[zeromq-dev] not binging to all LISTEN port

[Charles Remes]

No, home grown to read our logs. The instrumentation code also relies on our application protocol to identify sources and sinks. Unfortunately there would be very little to gain by releasing the source.

It might be an interesting exercise for the list to develop a standard application protocol that has support for this kind of instrumenting built in.

cr

On Sep 23, 2014, at 4:50 PM, Matthew Hawn <matthewh at donaanacounty.org> wrote:

> Charles,
> 
> I am very curious what tool you use to analyze the traffic data.  Is it by chance open-source?
> 
> Matt
> From: zeromq-dev-bounces at lists.zeromq.org [zeromq-dev-bounces at lists.zeromq.org] on behalf of Charles Remes [lists at chuckremes.com]
> Sent: Tuesday, September 23, 2014 11:44 AM
> To: ZeroMQ development list
> Subject: Re: [zeromq-dev] not binging to all LISTEN port
> 
> Mohit,
> 
> Your application should have end-to-end latency and throughput measurements. I build this functionality into any project that uses zeromq so that I can track the latency between any two endpoints (and any intermediate points too). This data is printed to a log in a format that is easily parsed by an external tool. The tool reads the log and calculates all of the timing measurements along with statistics (mean, median, mode, standard deviation, etc). It outputs the results into a tabular format which can then be loaded into Excel for pretty graphs & charts.
> 
> During testing, you set a baseline for messages/sec, latency, or whatever else you think is important. The reporting tool can then highlight any parts that are outside of bounds from your baseline.
> 
> This information then let’s me decide if I have any bottlenecks.
> 
> Good luck. It takes some effort early on to build this mechanism but it is reusable on any future project.
> 
> cr
> 
> On Sep 23, 2014, at 12:35 PM, Mohit Anchlia <mohitanchlia at gmail.com> wrote:
> 
>> I understand the basic part of performance testing and all other related things that need to happen. I was really looking from troubleshooting perspective. Say load increased more than anticipated or tested numbers, when that happens are there any metrics available that can point to router/dealer being a bottleneck. How can I really tell if I need to scale?
>> On Tue, Sep 23, 2014 at 10:30 AM, Gregg Irwin <gregg at pointillistic.com> wrote:
>> Hi Mohit,
>> 
>> MA> I was more of referring to debugging overload issues in prod.
>> MA> that we might not have been able to catch in performance
>> MA> environment. How can I tell that router/dealer is overloaded and
>> MA> need more router/dealers?
>> 
>> While it's always good to test, if you provide a rough hardware
>> outline, and the number and size of messages you need to support, you
>> may get one of three answers borne of experience by users here.
>> 
>> 1) No problem. You are well within a single socket's capabilities.
>> 
>> 2) One socket will not support that load. You might need N sockets.
>> 
>> 3) It could be close. You should test in your environment.
>> 
>> -- Gregg
>> 
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140923/356d1685/attachment.htm>