0

Consider Mastodon as an example - basically open source Twitter. Tweets can be up to 500 characters long. Of course, since it's open source, you can modify it to allow longer tweets. Unmodified Mastodon can connect to other copies of Mastodon, including modified ones. Mastodon will accept long tweets from other servers and display them to users, so I call this a "soft" limit.

My question is about hard limits. If an application like Mastodon would enforce a strict length limit on tweets, as well as the number of replies displayed under a tweet, and the length of usernames, and the number of users a user can follow, and so on, we could calculate the worst-case memory usage and processing time of any request. Then, we could calculate the worst-case requests per second of our server, as well as RPS under some reasonable conditions (average-length tweets, different request mixes, etc) and thus prove we've met our performance requirements. Of course, if performance is really important, we'll then add a safety factor.

Even though compile-time memory calculation is overkill for a Twitter clone, having well-defined hard limits still allows us to know what the worst-case input is, and then give the application that input and measure the resources needed to process it.

Is it a good idea to set limits across the codebase to ensure predictable resource usage, or is it a waste of development effort and a pile of unnecessary limitations for users?

Improve this question
11
  • Why are you asking it then?
    – Philip Kendall
    Jul 15 at 17:58
  • There is no singular answer here. For the same reason that a medical life saving device is significantly more rigorously tested than a baby piano, different websites will have different baselines for how much pre-emptive effort they want to put forward, based on the odds and consequences of something going wrong in production.
    – Flater
    Jul 15 at 23:57
  • @Flater: when your baby piano has a comment function which does not restrict comment length to some reasonable limit, sooner or later someone will post enough data as comment to make the thing unusable (now imagine the app is quite popular with >10K users). My point is, as soon as a web app is facing the public internet, a minimum of safety and security measures become necessary, and forbidding unlimited resource requests is one of them.
    – Doc Brown
    Jul 16 at 7:29
  • 2
    @Flater: sorry, but I disagree. Any web app for the public internet should take regard to certain security and safety measures by default, this isn't something professional software engineers should leave to the marketing or business guys. Switching these safety measures off becomes only a business decision when one delibrately wants to create something like a honeypot app.
    – Doc Brown
    Jul 16 at 10:36
  • 2
    Ultimately, all applications have a worst case limit / finite resources. Even in the cloud, you set a limit to the autoscaler. But the question, if availability or cost is more important, is a business decision. And if business prioritizes cost, it would be wasteful to size the servers by the worst case usage.
    – DasKrümelmonster
    Jul 16 at 16:11

3 Answers 3

Reset to default
3

Should web applications have predictable worst-case resource usage?

  • "Web applications" in general? Not necessarily.

  • Web applications facing the public internet? Definitely! You don't want your server flooded by some malicious bots, or abused as a cheap storage medium by some script kiddies, or just become victim of some erronous client request.

That does not mean you have to restrict the amount data for each and every post operation. For lots of applications it is sufficient to restrict the total resource usage per user over a certain time frame. That may lead to a better user experience than setting hard limits for each low level block of data.

Any reasonable server environment allows control over resource quotas for your web application in case the application will not limit resource consumption by itself (this was possible for decades, but has become even more fine-grained in containerized environments). Still when you allow malicious or erronous clients to request unlimited resources, this would end up in a denial-of-service situation. Hence, such issues are way better handled inside the application, the outer resource quotas should be just a last resort.

Improve this answer
0
1

Having predictable worst-case resource usage is indeed considered a best practice in the development and operation of web applications. It allows you to have better control over the performance and scalability of your system, as well as enables you to set appropriate resource limits.

The concept you are describing, where strict limits are enforced on various aspects of the application, and worst-case resource usage can be calculated, is part of a practice commonly known as "capacity planning" or "performance engineering." It involves analyzing the application's behavior under different scenarios and workload conditions to determine its resource requirements and ensure it meets performance objectives.

By enforcing hard limits and measuring worst-case resource usage, you can estimate the maximum load your application can handle within specified performance thresholds. This information is valuable for making informed decisions about scaling your application.

Improve this answer
1

In practice you care about average case behaviour. Only if you fear a DoS attack you care about worst case.

It’s not useful saying “my server can handle 10,000 worst case requests” when it handles 100,000 average requests all the time. And if you do, you are not going to buy enough servers to handle 100,000 worst case requests.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.