Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Statistics desired #76

Open
gdamore opened this issue Feb 4, 2015 · 14 comments
Open

Statistics desired #76

gdamore opened this issue Feb 4, 2015 · 14 comments

Comments

@gdamore
Copy link
Contributor

gdamore commented Feb 4, 2015

It may be nice to have methods to track statistics. There are probably a great number of potentially useful stats. We need to think about them.
@nkev
Copy link

nkev commented Jan 9, 2016

+1 I also cannot find any benchmarks compared to nanomsg or any other messaging platform.

@gdamore
Copy link
Contributor Author

gdamore commented May 25, 2016

Just a note @nkev -- we do have the local_lat, remote_lat, local_thr, and remote_thr utilities that nanomsg has. You can run them against each other -- or you can run them against nanomsg. (There are four permutations for each of these .) As far as just benchmarking locally, you can also use the Go benchmark facility in the test subdirectory. There are throughput and latency tests there. Obviously you cannot really compare the results against anything else, but it may still be useful. (For evaluating local changes to code and their impact on performance for example.)

@eelcocramer
Copy link

eelcocramer commented Feb 7, 2017 •
edited
Loading

I've added mangos to an existing message benchmark that I stumbled upon. It compares benchmarks of python and golang messaging solution. For golang it compares zmq, redis and now mangos. You can find my code here:

https://github.com/eelcocramer/two-queues

I'm not sure if a made it as efficient as possible but currently mangos does not come even close to zmq and redis.

update removed the graph as the figures are reliable.

Any hints to improve the performance of my code?

@gdamore
Copy link
Contributor Author

gdamore commented Feb 7, 2017 via email

@eelcocramer
Copy link

Thank you for the response and the solution pointers. I'll dig into this and post results back.

I will remove the graph because it probably does not good reliable information.

@gdamore
Copy link
Contributor Author

gdamore commented Feb 7, 2017 via email

@eelcocramer
Copy link

Thanks for the extensive answer.

@gdamore
Copy link
Contributor Author

gdamore commented Feb 7, 2017 via email •
edited
Loading

@gdamore
Copy link
Contributor Author

gdamore commented Feb 7, 2017 

package main

import (
	"fmt"
	"sync"
	"time"

	"github.com/go-mangos/mangos"
	"github.com/go-mangos/mangos/protocol/pub"
	"github.com/go-mangos/mangos/protocol/sub"
	"github.com/go-mangos/mangos/transport/tcp"
	"github.com/go-mangos/mangos/transport/inproc"
)

var addr1 = "tcp://127.0.0.1:4455"
var addr2 = "tcp://127.0.0.1:4456"
//var addr1 = "inproc://127.0.0.1:4455"
//var addr2 = "inproc://127.0.0.1:4456"

func client(loops int) {
	p, e := pub.NewSocket()
	if e != nil {
		panic(e.Error())
	}
	defer p.Close()
	s, e := sub.NewSocket()
	if e != nil {
		panic(e.Error())
	}
	defer s.Close()

	p.AddTransport(tcp.NewTransport())
	s.AddTransport(tcp.NewTransport())
	p.AddTransport(inproc.NewTransport())
	s.AddTransport(inproc.NewTransport())

	s.SetOption(mangos.OptionSubscribe, []byte{})

	if e = p.Dial(addr1); e != nil {
		panic(e.Error())
	}
	if e = s.Dial(addr2); e != nil {
		panic(e.Error())
	}

	msg := mangos.NewMessage(8)
	msg.Body = append(msg.Body, []byte("hello")...)
	now := time.Now()

	time.Sleep(time.Millisecond * 100)

	for i := 0; i < loops; i++ {
		if e = p.SendMsg(msg); e != nil {
			panic(e.Error())
		}
		if msg, e = s.RecvMsg(); e != nil {
			panic(e.Error())
		}
	}
	end := time.Now()
	delta := float64(end.Sub(now))/float64(time.Second)

	fmt.Printf("Client %d RTTs in %f secs (%f rtt/sec)\n",
		loops, delta, float64(loops)/delta);
}

func server() {
	p, e := pub.NewSocket()
	if e != nil {
		panic(e.Error())
	}
	defer p.Close()
	s, e := sub.NewSocket()
	if e != nil {
		panic(e.Error())
	}
	defer s.Close()
	p.AddTransport(tcp.NewTransport())
	s.AddTransport(tcp.NewTransport())
	s.AddTransport(inproc.NewTransport())
	p.AddTransport(inproc.NewTransport())
	s.SetOption(mangos.OptionSubscribe, []byte{})

	s.Listen(addr1)
	p.Listen(addr2)
	
	for {
		msg, e := s.RecvMsg()
		if e != nil {
			println(e.Error())
			return
		}
		e = p.SendMsg(msg)
		if e != nil {
			println(e.Error())
			return
		}
	}
}

func main() {
	clients := 32
	loops := 10000

	go server()
	time.Sleep(time.Millisecond*100)

	wg := sync.WaitGroup{}
	wg.Add(clients)

	for i := 0; i < clients; i++ {
		go func() {
			defer wg.Done()
			client(loops)
		}()
	}

	wg.Wait()
}

@gdamore
Copy link
Contributor Author

gdamore commented Feb 7, 2017

I see that I actually added a 100 ms delay inside the initial timing, so my numbers are 100 ms worse than they should be. But for large message counts that should amortize into the noise. Still should fix that....

@gdamore
Copy link
Contributor Author

gdamore commented Feb 7, 2017

The sleep is there to ensure that the connections are established. It can take several dozen milliseconds for TCP connections and the go routines on both sides to establish.

@gdamore
Copy link
Contributor Author

gdamore commented Oct 19, 2018

statistics support will be a mangos v2 deliverable. Probably following along with NNG in that regard.

@gdamore gdamore transferred this issue from nanomsg/mangos-v1 Nov 3, 2018
@gdamore gdamore mentioned this issue Dec 24, 2019
Closed
@BHare1985
Copy link

Did this every make v2, if not, is there something on the roadmap?
I am curious about using mangos and writing my own pub/sub system in order to reduce code complexity and maintainability with KISS but would be interested to know how it benchmarks/performs with very little helper code and design around throughput

@gdamore
Copy link
Contributor Author

gdamore commented Mar 22, 2024

It did not. Problem here is too many projects and not enough time.

If this is important enough to you to sponsor (or to contribute code) let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@eelcocramer @gdamore @BHare1985 @nkev