Parallelizing in startups does not reduce overload

[d4m4g1c]

Hey everyone! So I'm having trouble understanding how to scale up startups.

I have this base design for the blood center:
https://steamcommunity.com/sharedfiles/filedetails/?id=1631703500

Which uses 2 dlls:
https://steamcommunity.com/sharedfiles/filedetails/?id=1631703392
https://steamcommunity.com/sharedfiles/filedetails/?id=1631703441

As you can see, the limiting factor here is the rgb.dll, namely its input which can not handle the theoretical 0.041s rate. But at the beginning, as the startup has not many users, that's not a problem. On the other hand, the outputs are well scaled with shapes-forest-parallel.dll "eating" the outputs of rgb.dll at near full capacity.

But now the startup just hit the point where it has more users that it can handle. Well I said to myself, that's simple, to reduce overload on the rgb.dll just double the design and parallelize. And when I tested it it was fine: the design could handle with no stress on the input, with an increased delay due to the additional load balancer. Here a screenshot showing the design "eating" the incoming elements at full capacity:
https://steamcommunity.com/sharedfiles/filedetails/?id=1631703535

But in the end... The startup serviced less users! Which is weird because I basically doubled the number of processed elements... I have the impression that the number of serviced users is purely based on the estimated delay and not the average number of processed elements. Can someone else confirm this?

Here is a capture of my startups, the day that has a slight drop in processed users is the day where I tested the parallel design. Btw you can see that I made similar tests on the dissident-friendly tracking system, with 2 days of tests leading to less serviced users.
https://steamcommunity.com/sharedfiles/filedetails/?id=1631714008

In this case, how do someone services more users through parallelization? (without making dlls for every level of parallelization and every startup, which effectively reduces latency, but feels like cheating and is not possible anyway because of the limited amount of dlls)
Thanks

[SamuraiJones]

Honestly, I skimmed your post because I haven't ♥♥♥♥♥♥ to the level you mentioned. But I would feel better if the results of the startup were better explained (ie: "you had 90% accuracy vs the target of 80%, and .74s processing time, thus your result is... X"). I'm pretty sure I found a bug in the DLL processing, and it doesn't seem crazy to me that the lack of visibility in startups could be hiding more issues.

[GospodinNoob]

Thanks. I will check it

[Vladolf Putler]

it has to be, all of my "patches" totaly broke startups and cannot get past 2,5k served users :p

[Caffiend]

For me I get benefit from parallelizing with 1 server, if I double that again to 3 servers the cost goes up but the serviced users stays the same. Currently Blood Center and Tracking System are missing out on half of their users at least.

[furrykef]

I suspect you're running into this issue I've noticed.

[Azranite]

I'm getting this aswelll. I'm using the Dissident Friendly Tracking System for kitchentalk startup as example. Guessing by the numbers, it looks like the OP had the same issue in their Tracking System aswell.

Using a DLL that was already parallelized once and did about 4 decisions per second.
https://steamcommunity.com/sharedfiles/filedetails/?id=1877129211
It could handle 9997 users and produced about 2849 $ income per day.
Using that DLL twice with a balancer reduced the output to 2381 users and 401 Cat$ income.
Throwing out the DLLs and stuffing all the logic into the main puzzle window produced the same sad results.
When I used a single DLL and put a blancer infront, soldering both outputs into that single DLL, it behaved the same as using two balanced DLL in parallel. (extremely reduced output)
https://steamcommunity.com/sharedfiles/filedetails/?id=1877129904

Going back to the single DLL setup, I slapped a balancer to one of the DLL's outputs and soldered the balancers outputs together again. With this I got 9995 users producing 3031 Cat$ income a day. This showed that having the pure balancer's additional cost in the setup didn't cause this effect. But something's really weird as the profit has increased.
Using a decision tree as a reduntant extra filter after the DLL changed that to 9999 users and 3283 Cat$ income. Really weird.
https://steamcommunity.com/sharedfiles/filedetails/?id=1877131878

The worst Startup sell Value in this experiment, a balancer before the DLL, gave me 6378 Cat$ after 139 days:
https://steamcommunity.com/sharedfiles/filedetails/?id=1877131300
The best Startup with a single DLL and the redundant decision tree sold for a whopping 140300 Cat$ after 212 days:
https://steamcommunity.com/sharedfiles/filedetails/?id=1877132412


I also noticed that as the yellow user numbers increased, the processing time did aswell. With almost 10000 users advancing a day took about a second. (yes, my pc is old)

[Tiwaking! 56k NZ]

İlk olarak d4m4g1c tarafından gönderildi:

Hey everyone! So I'm having trouble understanding how to scale up startups.

Using Custom and DLL nesting is the only true way to scale startups. Using balancers costs too much money. Nested solutions along with a node limit and correctly routing inputs to outputs generates the most amount of money and lasts for the longest time.

[d4m4g1c]

@Tiwaking this post is kinda old, the devs have improved the game since then, and as I've read from the changelogs this issue is now fixed. Haven't replayed since so I cannot confirm.

[Tiwaking! 56k NZ]

İlk olarak d4m4g1c tarafından gönderildi:

@Tiwaking this post is kinda old, the devs have improved the game since then, and as I've read from the changelogs this issue is now fixed. Haven't replayed since so I cannot confirm.

Oh I didnt notice the date on this post!

But the issue still exists. If I use a parallel on this solution, the number of supported users doesnt change and the amount of money decreases
https://steamcommunity.com/sharedfiles/filedetails/?id=2260861161
To be honest.....this is an obscene amount of money anyway and Im just being greedy so its not that big of an issue.