[Twisted-Python] Twisted receiving buffers swamped?

Tobias Oberstein tobias.oberstein at tavendo.de
Tue Jan 20 13:40:37 MST 2015


> > Anyway. I think WAMP is a great choice to hook up components of a
> distributed test system - which is what I am after (e.g. I want to orchestrate
> 10 TCP load probes running on different machines, stressing a target TCP
> echo server).
> >
> > This difference in opinion might be because we have different
> _scopes/requirements_ to start from. Or not. I don't know.
> 
> This is Jean-Paul's personal opinion on the implementation choices involved.
> This is only really relevant if JP is going to be working on the performance
> testing framework directly or needs to interact with the WAMP bits directly.

Ok.

Yes, WAMP is an implementation detail here.

@Jean-Paul: I don't want to leave a bad impression here: you have been helping me
so often, and I learned so much from your hints, code, suggestions and opinions. I do
value that very much, and I have read everything you wrote. I swear;)

> If you're the one doing the work, you get to make the technology choices
> and, within certain reasonable constraints like "no PHP", I'm sure that we

omg, no;)

> would be happy to run whatever performance testing system you come up
> with if it satisfies our requirements and has a reasonable API.

Alright. We want to contribute, and if that is welcome, awesome!

"our requirements":

This is very important, as we need to fold in Twisted project specific requirements
into the list we have. If this is to be used not only in-house, but be of real
use/value to Twisted as a project. I think there will be a big overlap, but I want to
make sure we have it consolidated _before_ starting with code.

Can we collect those requirements from a Twisted project perspective?

I have skimmed through this thread and dumped it to:

https://github.com/oberstet/scratchbox/blob/master/python/twisted/speed/requirements.md

E.g. 10. + 11. + 12. + 15. from Glyph's comments.

If anyone has more to add to this list, please reply, I'll append it, and clean it up /structure it
in the end.

> > So I thought, for the time being, it might be better if we (Tavendo) develop
> something for internal use / privately ("in-house"), and probably come again
> / show something when we actually have it running.
> 
> Well, we'd want to see something that actually works before officially
> standardizing Twisted on it anyway, but please feel free to share it early.  I

Yes. Will do. I hate _talking_, instead of showing.

> guarantee you that we will not reject something simply for using WAMP :-).

=)

> 
> > Regarding the "charting sub-issue":
> >
> > I came across https://plot.ly/
> >
> > This is kinda cool and very quick to get started:
> >
> > http://picpaste.com/pics/Clipboard01-i4Karh0D.1421692351.png
> >
> > It does histograms and tons of fancy stuff and hosts everything for free.
> 
> This is hosted-service only?  Not that that's a dealbreaker, I guess, we are

Yes, this is hosted only. Which is part of why it's attractive. But: we don't want
to be locked into this too much.

Means: the test result _data_ should stay in a database open and accessible to
the Twisted project. We could host that database. Or it could reside on TSF.

The data is where the value is and the Twisted project needs to own/control that.

The data from that DB is then just read and requests to above service issued
to produce graphs.

But if we at some point want to kick that service, and generate graphs on our
own or whatever, that should definitely be possible.

/Tobias

> pretty sure we're going to move everything to Github anyway...
> 
> -glyph
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python




More information about the Twisted-Python mailing list