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

Emulate multiple failures #658

Open
krizhanovsky opened this issue Aug 11, 2024 · 2 comments
Open

Emulate multiple failures #658

krizhanovsky opened this issue Aug 11, 2024 · 2 comments
Labels
question Further information is requested

Comments

@krizhanovsky
Copy link
Contributor

krizhanovsky commented Aug 11, 2024

This task is TBD, but here is what I observed from the traffic from the bunch of recent issues, where we faced many new crashes.

The traffic is quite modest in volume (just about 170RPS and 4Mbps). The only thing I could say about reproducing our problems in tests:

  1. POST with relatively large binary body, I saw up to 97KB bodies. All are encoded with content-length.
  2. high variability in URLs, e.g. Restart tempesta under heavy load tempesta#2184 was caused by this reason. This should be also reproducable by DDoS mitigation testing #38 (random URL is a common attack pattern)
  3. maybe long URLs, but frankly something about 300 bytes doesn't look interesting
@krizhanovsky krizhanovsky added the question Further information is requested label Aug 11, 2024
@krizhanovsky krizhanovsky added this to the LA for tests milestone Aug 11, 2024
@krizhanovsky krizhanovsky changed the title Pilot failures Emulate multiple failures Aug 11, 2024
@RomanBelozerov
Copy link
Contributor

POST with relatively large binary body, I saw up to 97KB bodies. All are encoded with content-length.

We have tests sending one request with 500 MB body (t_long_body) and stress tests with a lot of request and 65KB body. I think we have enough tests for this case.

high variability in URLs, e.g. tempesta-tech/tempesta#2184 was caused by this reason. This should be also reproducable by #38 (random URL is a common attack pattern)

maybe long URLs, but frankly something about 300 bytes doesn't look interesting

These cases are almost not checked in our tests, but #438 should solve the problem. Also we can add a request/response generation for the deproxy and this allow us to simulate more real and different traffic. But we need good logging or reports for this (for example - allure)

I can add:

  • our tests doesn't contain such a variety of headers (this is very important for http 2 which uses hpack). Probably DDoS mitigation test #438 will help us with this too

@krizhanovsky
Copy link
Contributor Author

Many headers case should be covered with tempesta-tech/tempesta#1181

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants