Lingolol

Felix Palmen :freebsd: :c64:I just stress-tested the current dev state of <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> on <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a>. The first attempt failed miserably, got a lot of errors accepting a connection. Well, this lead to another little improvement, I added another static method to my logging interface that mimics <a href="https://mastodon.bsd.cafe/tags/perror" class="mention hashtag" rel="nofollow noopener" target="_blank">#perror</a>: Also print the description of the system errno. With that in place, I could see the issue was "too many open files". Checking <a href="https://mastodon.bsd.cafe/tags/ulimit" class="mention hashtag" rel="nofollow noopener" target="_blank">#ulimit</a> -n gave me 1024. Seriously? 🤯 On my <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> machine, as a regular user, it's 226755. Ok, bumped that up to 8192 and then the stress test ran through without issues.On a side note, this also made creating new timers (using <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#timerfd</a> on Linux) fail, which ultimately made swad crash. I have to redesign my timer interface so that creating a timer may explicitly fail and I can react on that, aborting whatever would need that timer.Anyways, the same test gave somewhat acceptable results: throughput of roughly 3000 req/s, response times around 500ms. Not great, but okayish, and not directly comparable because this test ran in a <a href="https://mastodon.bsd.cafe/tags/bhyve" class="mention hashtag" rel="nofollow noopener" target="_blank">#bhyve</a> vm and the requests had to pass the virtual networking.One major issue is still the <a href="https://mastodon.bsd.cafe/tags/RAM" class="mention hashtag" rel="nofollow noopener" target="_blank">#RAM</a> consumption. The test left swad with a resident set of > 540 MiB. I have no idea what to do about that. 😞 The code makes heavy use of "allocated objects" (every connection object with metadata and buffers, every event handler registered, every timer, and so on), so, uses the <a href="https://mastodon.bsd.cafe/tags/heap" class="mention hashtag" rel="nofollow noopener" target="_blank">#heap</a> a lot, but according to <a href="https://mastodon.bsd.cafe/tags/valgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#valgrind</a>, correctly frees everything. Still the resident set just keeps growing. I guess it's the classic <a href="https://mastodon.bsd.cafe/tags/fragmentation" class="mention hashtag" rel="nofollow noopener" target="_blank">#fragmentation</a> issue...

Felix Palmen :freebsd: :c64:Nice, <a href="https://mastodon.bsd.cafe/tags/threadpool" class="mention hashtag" rel="nofollow noopener" target="_blank">#threadpool</a> overhaul done. Removed two locks (<a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#mutex</a>) and two condition variables, replaced by a single lock and a single <a href="https://mastodon.bsd.cafe/tags/semaphore" class="mention hashtag" rel="nofollow noopener" target="_blank">#semaphore</a>. 😎 Simplifies the overall structure a lot, and it's probably safe to assume slightly better performance in contended situations as well. And so far, <a href="https://mastodon.bsd.cafe/tags/valgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#valgrind</a>'s helgrind tool doesn't find anything to complain about. 🙃Looking at the screenshot, I should probably make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> default to *two* threads per CPU and expose the setting in the configuration file. When some thread jobs are expected to block, having more threads than CPUs is probably better.<a href="https://github.com/Zirias/poser/commit/995c27352615a65723fbd1833b2d36781cbeff4d" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/poser/commit/995c27352615a65723fbd1833b2d36781cbeff4d</a>

Felix Palmen :freebsd: :c64:<a href="https://mastodon.bsd.cafe/@matuzalem" class="u-url mention" rel="nofollow noopener" target="_blank">@matuzalem</a> here's a release to test 😉 I'm pretty sure it won't crash, but can't guarantee. It's been examined a lot, also with <a href="https://mastodon.bsd.cafe/tags/lldb" class="mention hashtag" rel="nofollow noopener" target="_blank">#lldb</a> and <a href="https://mastodon.bsd.cafe/tags/valgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#valgrind</a>, but doesn't have any automated tests so far. I'm still undecided about investing the time and effort to change that, would need to pick a library/framework first (C doesn't offer any testing capabilities in the language) and then, while a few modules like the unicode string functions are perfectly unit-testable, the whole project is a large "event processor" (like any GUI application) and depends on these external events, so a *lot* of tedious mocking would be required for better test coverage ...edit: btw, fixed a weird bug before releasing this, it was possible to enter a state where processing X11 events stopped (requesting to minimize with the WM ignoring the request). Not a crash, but a bug 😅

Jim RamsayNo! As usual, the reviews and IRC chats with <a href="https://mastodon.social/@andriyngvason" class="u-url mention" rel="nofollow noopener" target="_blank">@andriyngvason</a> were extremely kind and valuable.First of all, wayvncctl needed a better human-friendly pretty-printer for the json responses. Sure!More importantly, we were using libjansson for the json library which uses a refcount system for memory management. <a href="https://fosstodon.org/tags/valgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#valgrind</a> pointed out a number of mistakes I made on both the server and the client that required more refactoring.Finally, it was ready: <a href="https://github.com/any1/wayvnc/pull/171" rel="nofollow noopener" target="_blank">https://github.com/any1/wayvnc/pull/171</a>

Philip Withnallgcov and valgrind technical details

Recent searches

Search options

Administered by:

Server stats:

#valgrind