[HN Gopher] Dimensions of Scalability
___________________________________________________________________
Dimensions of Scalability
Author : luu
Score : 17 points
Date : 2022-11-16 07:16 UTC (15 hours ago)
(HTM) web link (jenniferplusplus.com)
(TXT) w3m dump (jenniferplusplus.com)
| gmuslera wrote:
| The human component of a system matter a lot, and there is a
| point at which it may have troubles scaling up, because is
| something that doesn't scale so well as computers and
| technological resources. And a part of designing an scalable
| system is taking the human side into factor, the cognitive load
| on people that should make it work and keep it in that state. The
| complexity of a system, the different roles, data flows, non-
| standard configurations, exceptions, the use of pets instead of
| cattle, how things are interrelated, knowledge bases and so on
| are topics that should be taken into consideration.
|
| This is a related problem with what is discussed in The Mythical
| Man-Month, is not about building a program, but keeping a complex
| system running and evolving. And to make things worse, you can
| put another identical computer and handle twice the load. But
| people are not identical, and not just in knowledge that can be
| written down and transmitted but in different skills and areas
| covered.
| stblack wrote:
| Definition of scalability: (Change in performance) over (the
| change in something else).
|
| As math: Scalability = d Performance / d x
|
| ... where x can be almost anything.
|
| Take note: performance == "throughput" in most cases.
|
| THEREFORE, when scalability questions arise, you should be
| specific about which dimension of scalability is in question.
|
| Some dimensions of "scalability"
|
| * Number of customers
|
| * Total number of users
|
| * Number of concurrent users
|
| * Number of locations where a business or application runs
|
| * Size of the database
|
| * Transaction volume
|
| * Output volume
|
| * Response time
| jameshart wrote:
| It's not very constructive to respond to an article which sets
| out a thesis about thinking of scalability along multiple
| dimensions by instead just setting out your own _different_ way
| of thinking about scalability in dimensional terms.
|
| At least maybe address how your thinking about scalability in
| this way fits with or contradicts the original article.
| marcosdumay wrote:
| At what X is that?
|
| It's way more useful to define it as the maximum X such that
| dPerformance / dX is higher than some minimum viable amount. So
| you can say things like "this algorithm scales up to 1000
| requests for second on our infrastructure"
| jameshart wrote:
| That is not a statement about scalability. That is a
| statement about a _lack_ of scalability.
|
| If you multiply your infrastructure by _n_ , what RPS does
| your algorithm now scale up to? 1000 _n_ is good. > 1000 _n_
| is excellent. < 1000 _n_ is not scalable.
| marcosdumay wrote:
| > If you multiply your infrastructure by n
|
| You've read it wrong. That number doesn't change with the
| size of your infrastructure, it changes with its cost/size.
| jameshart wrote:
| I'm confused.
|
| If someone tells me that an algorithm scales to 1000 RPS
| on their infrastructure, and we are having a conversation
| about _scalability_ , I am interested in _what I have to
| do to increase the number of requests per second by some
| factor_.
|
| Unless what you meant by 1000 RPS was 1000 RPS _per
| server_ , say. In which case you're claiming that your
| system scales linearly - adding another server adds
| another 1000RPS.
___________________________________________________________________
(page generated 2022-11-16 23:02 UTC)