Comment on I measured the idle RAM of 19 self-hosted apps on identical hardware so you can size a VPS without guessing

atzanteol@sh.itjust.works ⁨3⁩ ⁨days⁩ ago

• mushroommunk@lemmy.today ⁨3⁩ ⁨days⁩ ago

  I was gonna say, no way their memory estimate is anywhere near real world for some of those. This feels quite useless because “using the apps will blow past the floor” is some real “draw the rest of the owl”.

  Especially since they said this was inspired by beginners not knowing what they can actually run on what, this is gonna get them way underestimating what they need

  original

  • smallserverdata@lemmy.ml ⁨3⁩ ⁨days⁩ ago

    That is a legitimate hit and the beginner framing makes it worse, agreed. A floor shown to someone who does not know it is a floor gets read as a budget, and then they buy the 1 GB box.

    Two things I am changing. First, I am measuring peak RSS under concurrent load now so no app is ever listed with only an idle figure. Second, the site framing goes, because “here is the floor, good luck” is exactly the rest-of-the-owl problem you are describing.

    If you have a multiplier you actually trust for the gap between idle and real usage, I would rather publish yours with credit than invent one.

    original
• smallserverdata@lemmy.ml ⁨3⁩ ⁨days⁩ ago

  You are right, and the 1070 MiB vs 173 MB gap is exactly the thing that makes my number misleading.

  Mine is a cold instance, no repos, no CI, no users, sampled 60 seconds after start. Yours is doing real work with real repo data cached. So the honest reading of my figure is “Forgejo will not start in less than 173 MB”, not “Forgejo runs in 173 MB”. I framed it as the second thing and I should not have.

  I am re-running the whole set under concurrent load now to publish a second column.

  If you are willing: roughly how many repos and how many users hit your instance? I would rather put a real-world datapoint next to the synthetic one than keep publishing only the synthetic one.

  original

  • frongt@lemmy.zip ⁨3⁩ ⁨days⁩ ago

    You should simulate a number of repos and users to produce a realistic estimate. I would find that extremely useful, as would some of my colleagues at work. You should be able to scale up to a few hundred of each without too much trouble, and there will be no risk to running into any limits. I’m looking forward to this!

    original

    • smallserverdata@lemmy.ml ⁨3⁩ ⁨days⁩ ago

      This is the most useful comment in the thread and it is the thing I am going to build next.

      You are describing the actual failure of what I posted. Hammering an HTTP endpoint with concurrent clients barely moves these apps. Forgejo went 171 to 313 MB under 24 concurrent clients at 4144 req/s, and the Go single binaries moved almost nothing, Caddy 40 to 47, ntfy 27 to 36. That is because the request path is cheap. What costs memory is data, so repo count and size and the working set of the database.

      So the harness needs to create state, not traffic. What I plan for Forgejo is to create N repos through the API, push real history into them, create users, then measure at several values of N so you get a curve rather than one number. A curve is also more honest because your answer depends on your N.

      Since you would use this: what values are worth reporting? I was thinking 10, 100 and 500 repos. And is repo count the thing that hurts, or is it total repo size, or CI, or concurrent git operations? You and your colleagues run this for real and I do not, so I would rather measure what you would actually check than guess.

      original