High performance setup ro RO

Configurare de înaltă performanță

Acest lucru este exact opusul setării cu memorie mică și de obicei doriți să urmați aceste sfaturi dacă doriți să creșteți în continuare performanța ASF (în termeni de viteză CPU), cu potențialul cost de utilizare crescută a memoriei.

---

ASF încearcă deja să prefere performanța în ceea ce privește reglarea generală echilibrată; prin urmare nu puteţi face multe pentru a-i creşte performanţa, deși aveţi anumite opţiuni care pot fi configurate. Cu toate acestea, aveți în vedere faptul că aceste opțiuni nu sunt activate în mod implicit, ceea ce înseamnă că nu sunt suficient de bune pentru a le considera echilibrate pentru majoritatea utilizărilor; de aceea trebuie să vă decideţi dacă creşterea memoriei indusă de acestea este acceptabilă pentru dumneavoastră.

---

Reglaj Runtime (avansat)

Below tricks involve serious memory and startup time increase and should therefore be used with caution.

The recommended way of applying those settings is through DOTNET_ environment properties. Bineînțeles, ați putea folosi și alte metode, de ex. runtimeconfig.json, dar unele setări sunt imposibil de stabilit în acest fel, și pe deasupra ASF va înlocui fișierul personalizat runtimeconfig.json cu cel propriu la următoarea actualizare, de aceea recomandăm proprietățile de mediu pe care le puteți seta cu ușurință înainte de a lansa procesul.

.NET runtime allows you to tweak garbage collector in a lot of ways, effectively fine-tuning the GC process according to your needs. We've documented below properties that are especially important in our opinion.

gcServer

Configurează dacă aplicaţia se foloseşte de colectarea gunoiului de la staţia de lucru sau de colectarea gunoiului de pe server.

Puteti citi specificul serverului GC la fundamentale pentru colectarea de gunoi.

ASF is using workstation garbage collection by default. This is mainly because of a good balance between memory usage and performance, which is more than enough for just a few bots, as usually a single concurrent background GC thread is fast enough to handle entire memory allocated by ASF.

However, today we have a lot of CPU cores that ASF can greatly benefit from, by having a dedicated GC thread per each CPU vCore that is available. This can greatly improve the performance during heavy ASF tasks such as parsing badge pages or the inventory, since every CPU vCore can help, as opposed to just 2 (main and GC). Server GC is recommended for machines with 3 CPU vCores and more, workstation GC is automatically forced if your machine has just 1 CPU vCore, and if you have exactly 2 then you can consider trying both (results may vary).

Server GC itself does not result in a very huge memory increase by just being active, but it has much bigger generation sizes, and therefore is far more lazy when it comes to giving memory back to OS. You may find yourself in a sweet spot where server GC increases performance significantly and you'd like to keep using it, but at the same time you can't afford that huge memory increase that comes out of using it. Luckily for you, there is a "best of both worlds" setting, by using server GC with GCLatencyLevel configuration property set to 0, which will still enable server GC, but limit generation sizes and focus more on memory. Alternatively, you might also experiment with another property, GCHeapHardLimitPercent, or even both of them at the same time.

However, if memory is not a problem for you (as GC still takes into account your available memory and tweaks itself), it's a much better idea to not change those properties at all, achieving superior performance in result.

DOTNET_TieredPGO

Această setare activează optimizarea ghidată de profil dinamică sau pe nivele (PGO) în .NET 6 și versiunile ulterioare.

Dezactivat implicit. Pe scurt, aceasta va face ca JIT să petreacă mai mult timp analizând codul ASF și modelele acestuia pentru a genera un cod superior, optimizat pentru utilizarea ta obișnuită. Dacă vrei să afli mai multe despre această setare, vizitează îmbunătățirile de performanță în .NET 6.

DOTNET_ReadyToRun

Configurează dacă runtime-ul .NET Core utilizează cod precompilat pentru imagini cu date ReadyToRun disponibile. Dezactivarea acestei opțiuni forțează runtime-ul să compileze JIT codul framework-ului.

Activat implicit. Dezactivarea acestei opțiuni în combinație cu activarea DOTNET_TieredPGO îți permite să extinzi optimizarea ghidată de profil pe nivele la întreaga platformă .NET, nu doar la codul ASF.

---

Poți activa proprietățile selectate setând variabilele de mediu corespunzătoare. De exemplu, pe Linux (shell):

export DOTNET_gcServer=1

export DOTNET_TieredPGO=1
export DOTNET_ReadyToRun=0

./ArchiSteamFarm # Pentru build-ul specific sistemului de operare
./ArchiSteamFarm.sh # Pentru build-ul generic

Sau pe Windows (powershell):

$Env:DOTNET_gcServer=1

$Env:DOTNET_TieredPGO=1
$Env:DOTNET_ReadyToRun=0

.\ArchiSteamFarm.exe # Pentru build-ul specific sistemului de operare
.\ArchiSteamFarm.cmd # Pentru build-ul generic

---

Optimizare recomandată

• Asigură-te că folosești valoarea implicită a OptimizationMode, care este MaxPerformance. Aceasta este, de departe, cea mai importantă setare, deoarece utilizarea valorii MinMemoryUsage are efecte dramatice asupra performanței.
• Activează GC server. GC server poate fi imediat observat ca fiind activ prin creșterea semnificativă a memoriei comparativ cu GC-ul de stație de lucru. Aceasta va lansa un thread GC pentru fiecare thread CPU pe care îl are mașina ta, pentru a efectua operațiuni GC în paralel, cu viteză maximă.
• Dacă nu îți permiți creșterea memoriei din cauza GC server, ia în considerare ajustarea GCLatencyLevel și/sau GCHeapHardLimitPercent pentru a obține „ceea ce este mai bun din ambele lumi”. Cu toate acestea, dacă memoria ta își permite, este mai bine să o lași la valoarea implicită – GC server se ajustează deja în timpul execuției și este suficient de inteligent pentru a folosi mai puțină memorie atunci când sistemul tău de operare o va necesita cu adevărat.
• Poți lua în considerare și o optimizare crescută pentru un timp de pornire mai lung, cu ajustări suplimentare prin alte proprietăți DOTNET_ explicate mai sus.

Aplicarea recomandărilor de mai sus îți va permite să obții o performanță superioară a ASF, care ar trebui să fie extrem de rapidă chiar și cu sute sau mii de boți activi. CPU-ul nu ar trebui să mai fie un punct de blocaj, deoarece ASF este capabil să utilizeze întreaga putere a CPU-ului tău atunci când este necesar, reducând timpul necesar la minimul absolut. Următorul pas ar fi upgrade-ul CPU-ului și al RAM-ului.