Live data from Hacker News

TcpKali – Fast multi-core TCP and WebSockets load generator

github.com

11–20 of 20 posts

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#11
post #7

One minor nit about the projects use of autoconf / automake. Projects should please check the generated files into git. Sure, they're auto-generated. But 90% of the time when they're not in git, I discover that I have a different version of autoconf, and I can't even build "configure" in order to build the project. The cost of a few more bytes in git is more than outweighed by the benefits of allowing people to use y…

This is inherently wrong. Auto-generated files should NEVER be in git.

However, they should be in the stable release tarball.

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#12
post #7

One minor nit about the projects use of autoconf / automake. Projects should please check the generated files into git. Sure, they're auto-generated. But 90% of the time when they're not in git, I discover that I have a different version of autoconf, and I can't even build "configure" in order to build the project. The cost of a few more bytes in git is more than outweighed by the benefits of allowing people to use y…

Checking in build products is not about saving a couple bytes. It's about having a DRY codebase that isn't of out sync with itself.

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#13
post #8
post #6

Surprised to see the name and image in the site. If you're wondering about the name and the image there, "Kali" is the Hindu goddess and the image depicts her. https://en.wikipedia.org/wiki/Kali

Yes, I initially thought this was a part of the pen-testing linux distribution[0] also named Kali. [0] https://www.kali.org/

My association with this name is the IPX over Internet app that was around in the 90s to play things like Doom over the internet. Strange :)

https://en.wikipedia.org/wiki/Kali_%28software%29

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#14
post #5

Is there a way to specify a sequence of messages every connection should send? Preferably even let it randomize it (want to load test a game with real input, not just set up the connection).

Something like Gattling or Artillery.io would probably be better for this use case. TcpKali looks good but purposed more for benchmarking servers than actual apps.

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#15
TcpKali mascot is an example of great visual identity for open source projects: kawaii-touched fearsome ancient god zapping servers. It's both memorable visual symbol and an apt metaphor for core feature (load generation).

RJ-45 connectors with a skull hanging from the neck and a latte cup are just cherries on top.

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#16
post #15

TcpKali mascot is an example of great visual identity for open source projects: kawaii-touched fearsome ancient god zapping servers. It's both memorable visual symbol and an apt metaphor for core feature (load generation). RJ-45 connectors with a skull hanging from the neck and a latte cup are just cherries on top.

To give credit where the credit is due: the mascot was created by a great graphical designer - Tatyana Alexandrova (https://twitter.com/Alextanya)

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#17
post #7

One minor nit about the projects use of autoconf / automake. Projects should please check the generated files into git. Sure, they're auto-generated. But 90% of the time when they're not in git, I discover that I have a different version of autoconf, and I can't even build "configure" in order to build the project. The cost of a few more bytes in git is more than outweighed by the benefits of allowing people to use y…

This is inherently wrong. Auto-generated files should NEVER be in git. However, they should be in the stable release tarball.

How am I supposed to contribute to your project if the files required to build it are in one place (the tarball) but patches have to be made in another (the git repo)?

If your best practices require you to make potential users and contributors jump through hoops, then maybe those best practices are a bit shit.

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#18
post #5

Is there a way to specify a sequence of messages every connection should send? Preferably even let it randomize it (want to load test a game with real input, not just set up the connection).

-m 'foo' -m 'bar' is one way. --message-file --message-file is another way.

You can randomize input somewhat by using \{connection.id % 100} expressions right in the -m and within the files.

But yes, tcpkali can do simple randomizations, but does not support full-blown scripting. For that, consider using http://github.com/machinezone/mzbench or other alternatives.

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#19

Earlier quoted context omitted.

This is inherently wrong. Auto-generated files should NEVER be in git. However, they should be in the stable release tarball.

How am I supposed to contribute to your project if the files required to build it are in one place (the tarball) but patches have to be made in another (the git repo)? If your best practices require you to make potential users and contributors jump through hoops, then maybe those best practices are a bit shit.

I do not understand this debate. The project should decide on which autotools version to use and everyone contributing should make sure everything can be generated and installed with roughly the following:

> autoreconf -ivf

> ./configure

> make

> sudo make install

Re: TcpKali – Fast multi-core TCP and WebSockets load generator

#20
post #19

Earlier quoted context omitted.

How am I supposed to contribute to your project if the files required to build it are in one place (the tarball) but patches have to be made in another (the git repo)? If your best practices require you to make potential users and contributors jump through hoops, then maybe those best practices are a bit shit.

I do not understand this debate. The project should decide on which autotools version to use and everyone contributing should make sure everything can be generated and installed with roughly the following: > autoreconf -ivf > ./configure > make > sudo make install

Well, not only that, autoconf and automake files themselves can set a minimum version.

For the problem case of "my version was old, but still executed, and produced a build system that wouldn't build", this has already been handled for a long long time.

But yeah, either autoreconf or explicit autogen.sh works.

Post reply on HN