Nunc Stans stress test should assert it has 95% or high connection success rate #2213
Comments
|
Comment from firstyear (@Firstyear) at 2017-03-01 02:52:46 Metadata Update from @Firstyear:
|
|
Comment from firstyear (@Firstyear) at 2017-03-10 04:48:48 |
|
Comment from firstyear (@Firstyear) at 2017-03-10 04:49:36 Metadata Update from @Firstyear:
|
|
Comment from firstyear (@Firstyear) at 2017-03-10 07:33:17 |
|
Comment from firstyear (@Firstyear) at 2017-03-10 07:49:25 |
|
Comment from vashirov (@vashirov) at 2017-03-10 12:25:10 With the latest patch building in brew/mock fails on nuncstans test: I wonder if the limits should be adjusted in chroot or this test is too agressive? |
|
Comment from firstyear (@Firstyear) at 2017-03-11 00:24:47 The test has to be aggresive: We need to really "stress" the nunc-stans system to be sure it works. I can try turning it down a bit and see if that's better. What's the FD limit in chroots? |
|
Comment from vashirov (@vashirov) at 2017-03-11 14:16:29 I have 1024 in mock, I asssume brew/koji has the same default. If the test has to be aggressive and we really want to push nunc-stans to the limits, shouldn't we not abuse the build system and run stress tests on a dedicated hardware in a controlled environment? |
|
Comment from firstyear (@Firstyear) at 2017-03-13 01:18:19 tl;dr - I will make a second test that does a smaller number under the 1024 fd mark (maybe under 512 even). The reason I want this test here is that it often shows issues on different architectures like dropping connections or otherwise. It's hard for me to get access to any machines or platforms within RH. I only have my home lab, and it's x86_64 only. We want to be finding these issues sooner rather than later. And now, it may be inconvenient during the build while we iron out the kinks, but I would rather have a build fail, then see a dodgy nunc-stans ever make it's way to a customer. As a result, I think I will make a smaller test, that quickly checks a few of these assertions and threads. I think it's important for us to find these early. We can save the larger test for QE or for developers. |
|
Comment from firstyear (@Firstyear) at 2017-03-13 03:38:50 Okay, this patch makes the situation much better. I split it up to have two tests, a small and large. The small caps at 256 connections, ie 512 fds. This should keep us within the boundaries of mock, but still providing a quick sanity check that our work is correct. RPMS all build correctly, so lets see how this one goes. |
|
Comment from vashirov (@vashirov) at 2017-03-14 07:58:17 Build passes in brew/koji/mock now. Thanks! |
|
Comment from vashirov (@vashirov) at 2017-03-14 07:58:26 Metadata Update from @vashirov:
|
|
Comment from firstyear (@Firstyear) at 2017-03-14 08:00:37 commit 09ce17bb51ae500f9a110cd9c43ac3ff6c76babc |
|
Comment from firstyear (@Firstyear) at 2017-03-14 08:10:07 Metadata Update from @Firstyear:
|
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49154
Issue Description
The stress test often has connections time out, because it overwhelms the framework. This is normally in the order of 1%. We should assert that this is the case in the test for passing connections. For example, we don't want 90% of connections to timeout, even though the rest passes and matches.
The text was updated successfully, but these errors were encountered: