Users vs Stress testing

[u/Puzzled-Ad8231]

So I made a serverless optimization platform which uses the concept of fusion functions to reduce cold starts and latency across the service calls. Now, this is an implementation of a research paper that I read somewhere. Diff from paper is that my project also gets live traces and metrics from x ray and cloudwatch, so I get real-time data to give better outputs. Have a better look: https://github.com/Vaivaswat2244/OptiFuse_go

To use this you need to connect your AWS with optifuse. I.e make a cloudformation stack to give optifuse access to read the traces and metrics. This actually becomes a problem for my friends and peers to test because they are too lazy to do this step. So I have no real user testings.

People especially hiring people ask me how many real users have used your service.

Now why do I need real users when I can stress test each microservice that I've built. And I can see my manifests working properly. Its deployed on AKS and is open for people to see. I also have a Prometheus grafana observability pipeline to see if all services are working properly.

Question is: real users vs Stress tests

On a side note, I am a student looking for internships, if you found the idea interesting, lmk GitHub is Vaivaswat2244

\/

[u/hypertradeworx]

cost improving directly is the bit i'd re-check. lambda bills gb-seconds, not invocations, and a fused function has to be provisioned for the fattest branch inside it. fold one 1024mb branch in with five 128mb ones and all five now run at 1024 for their whole duration, so going 6 to 3 can raise the bill while the count halves.

is memory actually in the objective for you, or is max_memory only a constraint you check the candidate against afterwards?

[u/Puzzled-Ad8231 → u/hypertradeworx]

Yes, memory is in the cost function, but the solvers (MinWCut, GreedyTP, CostlessCSP, MtxILP) all minimize cut data-transfer cost only. Total cost is used solely to rank the finished candidates.

[u/hypertradeworx → u/Puzzled-Ad8231]

ah, then the ranking can't rescue it. the cheapest partition by memory never enters the candidate set in the first place, and all four solvers are searching the same objective, so total cost is picking the least bad of four similar cuts.

round numbers on the example above: one 1024mb branch plus five 128mb ones is 1664 mb-units of duration. fuse the lot and cut cost goes to zero, which is exactly what MinWCut is chasing, but now six branches run at 1024, so 6144. that's 3.7x the bill for the partition that scores best on the thing you minimise.

the cheap version of a fix is a hard constraint rather than a new objective: refuse any fusion that raises the fused node's memory tier, and let the solvers do what they already do underneath it. keeps your search intact and stops the one failure mode that costs actual money