CI: Add sozu benchmark #1042
Closed
CI: Add sozu benchmark #1042
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
|
please squash the commits and add a description to this PR to give context, list objectives, show some output examples. |
GuillaumeASSIER
force-pushed
the
ci
branch
2 times, most recently
from
e72caf6 to
c40d21a
Compare
|
I like it very much. Can you please remove the "draft" mention to the pull request? Also, it would be great to have the output of the benchmark be displayed somewhere. The dream would be to have the same as the rustls repository, where a dedicated benchmarking bot is present and creates nice tables of results at will. |
GuillaumeASSIER
requested review from
FlorentinDUBOIS,
Keksoj and
Wonshtrum
as code owners
Keksoj
approved these changes
Feb 7, 2024
this solves an error where payload was partially transmitted Co-Authored-By: Eloi DEMOLIS <[email protected]>
Co-Authored-By: Eloi DEMOLIS <[email protected]>
create Channel::set_timeout() Co-Authored-By: Eloi DEMOLIS <[email protected]>
Due to how access logs are parsed inside CleverCloud, we can't have spaces in tags nor can a tag value end with a comma. This commit sanitizes the user-agent which is the only tag with client data. This is a temporary fix necessary until we make the logs binary. Signed-off-by: Eloi DEMOLIS <[email protected]>
Signed-off-by: Florentin Dubois <[email protected]>
Signed-off-by: Florentin Dubois <[email protected]>
Signed-off-by: Florentin Dubois <[email protected]>
The multi-threaded, event-based architecture was too complicated and prevented introducing protobuf channels. The new CommandServer functions on the same principle as the proxy logic of Sōzu: listen to events with Mio in an event loop, dispatch the events accordingly by creating WorkerSessions, ClientSessions. This new CommandServer allows to create Tasks, that can scatter requests to all workers, gather their responses as the event loop goes, and invoke the task finish() when all responses are gathered. A worker whose unix socket is disconnected will be killed, and automatically restarted if configurated to. Conversely, if the main process dies, the orphaned workers will perform a hard stop. Sōzu channels used everywhere for communication with workers and clients. Automatic counting and respawning of workers, at each tick implement soft stop and hard stop improve CLI: - disable logging in CLI when displaying JSON - sort list of workers when displaying status error handling with thiserror remove obsolete documentation on managing workers remove unused dependencies: smol, futures, futures-lite, anyhow Co-Authored-By: Emmanuel BOSQUET <[email protected]>
Signed-off-by: Eloi DEMOLIS <[email protected]> Co-Authored-By: Mbechezi Mlanawo <[email protected]>
|
I failed to fix the git history. I made a new clean PR |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
As sozu need strong performances, we need a simple way to benchmark sozu regularly.
I create a complete sozu benchmark script using python who's in charge of booting a sozu with lagging_server, load certificates with a complete configuration and run a stressing tool. At the end, we collect all the results in a log file archive as an artifact.
It's automated with a CI called benchmark.yml to automate the build and the benchmarking tool. For now, I use bombardier, but we can easily add new testing tools.
This setup test sozu performances with following settings :
The aim is not to get some reliable results, but to get a simple methodology that we can reuse in the future to track sozu performances.