Embed Notice

HTML Code

<blockquote style="position: relative; padding-left: 55px;"><section><a href="https://were.social/objects/e01f6642-f87e-4b1f-802c-24d339c41b86">arcanicanis (arcanicanis@were.social)'s status on Thursday, 24-Nov-2022 06:01:00 JST</a><a href="https://were.social/users/arcanicanis" title="arcanicanis@were.social"><img src="https://gnusocial.jp/avatar/10459-48-20220918060352.webp" width="48" height="48" alt="arcanicanis" style="position: absolute; left: 0; top: 0;">arcanicanis</a><div><a href="https://awoo.fyi/objects/7f0adf8c-427c-4a7c-a347-107889bedba6" rel="in-reply-to">in reply to</a><ul><li><li><a href="https://gnusocial.jp/user/37630" title="ryle@awoo.fyi">Ryle</a></li></ul></div></section><article>Just a swap to a VPS with 'dedicated' cores versus 'shared' (at least per Linode's offerings; $30/mo v. $20/mo) was all that's needed to make a substantial difference. I'm sure if BEAM VM looks like it's eating spare processor cycles for busy-waiting, that the whole VPS itself starts to lose priority.<br><a href="https://stressgrid.com/blog/beam_cpu_usage/">https://stressgrid.com/blog/beam_cpu_usage/</a><br><br>I guess I should have tried disabling the busy-waiting function, to see if that would have made just as much of a difference, before scaling up:<br><a href="https://docs-develop.pleroma.social/backend/configuration/optimizing_beam/#bad">https://docs-develop.pleroma.social/backend/configuration/optimizing_beam/#bad</a><br><br>But either way, at least I have more predictable guaranteed performance now.</article><footer><a rel="bookmark" href="https://gnusocial.jp/conversation/653176#notice-1031311">In conversation</a><time datetime="2022-11-24T06:01:00+09:00" title="Thursday, 24-Nov-2022 06:01:00 JST">Thursday, 24-Nov-2022 06:01:00 JST</time> <span>from <span><a href="https://were.social/objects/e01f6642-f87e-4b1f-802c-24d339c41b86" rel="external" title="Sent from were.social via ActivityPub">were.social</a></span></span><a href="https://were.social/objects/e01f6642-f87e-4b1f-802c-24d339c41b86">permalink</a><h4>Attachments</h4><ol><li><article><header><div>Domain not in remote thumbnail source whitelist: stressgrid.com</div><h5><a href="https://stressgrid.com/blog/beam_cpu_usage/">The Curious Case of BEAM CPU Usage</a></h5><div> from <span>Stressgrid</span></div></header><div>While benchmarking Go vs Elixir vs Node, we discovered that Elixir (running on the BEAM virtual machine) had much higher CPU usage than Go, and yet its responsiveness remained excellent. Some of our readers suggested that busy waiting might be responsible for this behavior.</div><footer></footer></article></li><li><article><header><div>No result found on File_thumbnail lookup.</div><h5><a href="https://docs-develop.pleroma.social/backend/configuration/optimizing_beam/#bad">Optimizing the BEAM - Pleroma Documentation</a></h5><div></div></header><div></div><footer></footer></article></li></ol></footer></blockquote>

Corresponding Notice

Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Thursday, 24-Nov-2022 06:01:00 JSTarcanicanis
in reply to
- pawlicker
- Ryle
Just a swap to a VPS with 'dedicated' cores versus 'shared' (at least per Linode's offerings; $30/mo v. $20/mo) was all that's needed to make a substantial difference. I'm sure if BEAM VM looks like it's eating spare processor cycles for busy-waiting, that the whole VPS itself starts to lose priority.
https://stressgrid.com/blog/beam_cpu_usage/

I guess I should have tried disabling the busy-waiting function, to see if that would have made just as much of a difference, before scaling up:
https://docs-develop.pleroma.social/backend/configuration/optimizing_beam/#bad

But either way, at least I have more predictable guaranteed performance now.
In conversationThursday, 24-Nov-2022 06:01:00 JST from were.socialpermalink
Attachments
1. Domain not in remote thumbnail source whitelist: stressgrid.com
  The Curious Case of BEAM CPU Usage
  from Stressgrid
  While benchmarking Go vs Elixir vs Node, we discovered that Elixir (running on the BEAM virtual machine) had much higher CPU usage than Go, and yet its responsiveness remained excellent. Some of our readers suggested that busy waiting might be responsible for this behavior.
2. No result found on File_thumbnail lookup.
  Optimizing the BEAM - Pleroma Documentation

Public

Embed Notice

HTML Code

Corresponding Notice