|WikiProject Computing||(Rated Start-class, Mid-importance)|
|This article has been mentioned by a media organisation:|
I added three paragraphs. I hope it's not too verbose. Maybe scalability should be described as expandability, and ability to load balance or maintain performance despite difference in resources and added load?
Scalability: controlling for costs
Every problem takes certain resources to solve: in software engineering as in many areas these are labour (including skills, knowledge), capital goods and time. There are also various parameters for success, including system performance, system complexity (maintainability), system flexibility, financial cost, etc.
Scalability is the ability to change the system so as to benefit one or more of the parameters by increasing the resource input in a chosen mix.
What that mix might be will vary according to the situation: in the dot-com boom people were fixated on being first to market, and were willing to throw capital good and labour at any problem to achieve increased system performance (i.e. to cope with more users) but demanded that absolutely the minimum time should elapse before the the next release. When that bubble burst, time, performance and flexibility (the ability to do new, unforeseen things) became much less of a factor, but financial cost, labour, capital goods and maintainability became seen as much more important.
A scalable system is therefore one that allows (in the first case) more people and money to be thrown at the problem to achieve greater performance and capability very rapidly or (in the second case) people and money to be taken away without seriously impacting on the current performance or causing a failure of maintainability; this latter is "scaling down". A system is commonly said to be "not scalable" if it performs poorly in this regard.
A system that scales well according to the assumptions at its original design time, and also has sufficient flexibility to scale well when the controlling paradigm changes dramatically, is either a careful compromise (and so not highly optimised for its original design goals) or is a work of rare genuis.Msahutty 00:40, 4 Jul 2004 (UTC)
I'm responding to the "Dubious" tag, where virtualization is considered "almost always" less expensive than adding new computing systems. Recently, a number of computers are quite hard to expand, yet have a low initial cost. Kenneth Parker, Seattle, WA [User:sea7kenp] 04:11 4 Dec 2012 (PST) — Preceding unsigned comment added by Sea7kenp (talk • contribs)
I changed the definition to describe "total throughput" instead of "performance". The addition of resources to a scalable system increases the total amount of work done in a unit of time, but individual users may not see an improvement in performance (and may even see degradation).
IS THERE AN IMAGE
to illustrate the "vertical" and "horizontal" scaling part? A simple xy graph would work. Erudecorp 03:24, 24 September 2007 (UTC)
Since Scale is being treated as a VERB here, it begs for the Wiktionary entry be to be expanded.
I moved the section on the Black Swan. If this is included, it should not be in the intro. I wonder if it should be included at all, but as I have an allergy for gurus (especially management gurus!) and their name dropping, it is better that more objective people decide. Klungel (talk) 11:56, 28 March 2008 (UTC)
- Then you shouldn't include Bondi as reference, met him, he consists only of management and has ideas to measure some data which where already measured... —Preceding unsigned comment added by 22.214.171.124 (talk) 10:43, 2 June 2010 (UTC)
Scalability - Had to add that definition to my spelling checker... Scalability intrinsically implies not only increases in dimensions, but also decreases in dimensions. Is there another section that deals with decreasing dimensions, i.e. decreasing X, Y, Z. For something to be truly scale able it would seem that it would scale in both directions. Or even a combination of whatever scales apply. Technology (imo) should not concentrate only in the direction demand goes. — Preceding unsigned comment added by Wikicadger (talk • contribs) 01:52, 7 December 2011 (UTC)
A comment about the line on quadratic growth in the third paragraph of introductory section: if n is the size of the input, then the _algorithm's runtime_ (e.g., the number of comptutations required) should be less than n^2. right now it says that n should grow slower than n^2, which doesn't make any sense. Phuf (talk) 22:09, 15 March 2013 (UTC)