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.

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

It's a FAQ #238

Merged
merged 3 commits into from
May 3, 2021
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ Not to be used in production systems.
* See the [Session documentation](./docs/session.md) for an overview of quilkin sessions and metrics.
* See [Filter documentation](./docs/extensions/filters/filters.md) for a list of filters, and their configuration options.
* The [Administration interface](./docs/admin.md) provides access to health and metrics endpoints.

* Finally, we also have a [FAQ](./docs/faq.md)
## Code of Conduct

Participation in this project comes under the [Contributor Covenant Code of Conduct](code-of-conduct.md)
Expand Down
55 changes: 55 additions & 0 deletions docs/faq.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# FAQ

## Just how fast is Quilkin? What sort of performance can I expect?

Our current testing shows that on Quilkin shows that it process packets _quite fast_!

We won't be publishing performance benchmarks, as performance will always
change depending on the underlying hardware, number of filters, configurations and more.

We highly recommend you run your own load tests on your platform and configuration, matching your production
workload and configuration as close as possible.

Our [iperf3](https://iperf.fr/) based performance test in the [examples' folder](../examples/iperf3) is a good
starting point.

Since this is still an alpha project, we have plans on investigating further performance improvements in upcoming
releases, both from an optimisation and observability perspective as well.

## Can I integrate Quilkin with C++ code?

Quilkin is also released as a [library](https://crates.io/crates/quilkin), so it can be integrated with an external
codebase as necessary.

Using Rust code inside a C or C++ project mostly consists of two parts.

* Creating a C-friendly API in Rust
* Embedding your Rust project into an external build system

See [A little Rust with your C](https://docs.rust-embedded.org/book/interoperability/rust-with-c.html) for more
information.

Over time, we will be expanding documentation on how to integrate with specific engines if running Quilkin as a
separate binary is not an option.

## I would like to run Quilkin as a client side proxy on a console? Can I do that?

This is an ongoing discussion, and since console development is protected by non-disclosure agreements, we can't
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@luna-duclos what did you think of this answer?

comment on this directly.

That being said, we are having discussions on how we can release lean versions of certain filters that would work
with known supported game engines and languages for circumstances where compiling Rust or providing a separate
Quilkin binary as an executable is not an option.

## Any reason you didn't contribute this into/extend Envoy?

This is an excellent question! [Envoy](https://www.envoyproxy.io/) is an amazing project, and has set many of the
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@luna-duclos what did you think of this answer?

standards for how [proxies are written and orchestrated](./xds.md), and was an inspiration for many of
the decisions made on Quilkin.

However, we decided to build this project separately:

* Envoy seems primarily focused on web/mobile network workloads (which makes total sense), whereas we wanted
something specialised on gaming UDP communication, so having a leaner, more focused codebase would allow us to move
faster.
* We found the Rust and Cargo ecosystem easier to work with than Bazel and C++, and figured our users would as well.