Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
UPDATED: I'm asking this from a development perspective, however to illustrate, a canoical non-development example that comes to mind is that if it costs, say, $10,000
to keep a uptime rate of 99%, then it theoretically can cost $100,000 to keep a rate
of 99.9%, and possibly $1,000,000 to keep a rate of 99.99%.
Somewhat like calculus in approaching 0, as we closely approach 100%,
the cost can increase exponentially. Therefore, as a developer or PM, where do you decide
that the deliverable is "good enough" given the time and monetary constraints, e.g.: are you getting a good ROI at 99%, 99.9%,
99.99%?
I'm using a non-development example because I'm not sure of a solid metric for development. Maybe in the above example "uptime" could be replaced with "function point to defect ratio", or some such reasonable measure rate of bugs vs. the complexity of code. I would also welcome input regarding all stages of a software development lifecycle.
Keep the classic Project Triangle constraints in mind (quality vs. speed vs. cost). And let's assume that the customer wants the best quality you can deliver given the original budget.
There's no way to answer this without knowing what happens when your application goes down.
If someone dies when your application goes down, uptime is worth spending millions or even billions of dollars on (aerospace, medical devices).
If someone may be injured if your software goes down, uptime is worth hundreds of thousands or millions of dollars (industrial control systems, auto safety devices)
If someone looses millions of dollars if your software goes down, uptime is worth spending millions on (financial services, large e-commerce apps).
If someone looses thousands of dollars if your software goes down, uptime is worth spending thousands on (retail, small e-commerce apps).
If someone will swear at the computer and looses productivity while it reboots when your software goes down, then uptime is worth spending thousands on (most internal software).
etc.
Basically take (cost of going down) x (number of times the software will go down) and you know how much to spend on uptime.
The Quality vs Good Enough discussion I've seen has a practical ROI at 95% defect fixes. Obviously show stoppers / critical defects are fixed (and always there are the exceptions like air-plane autopilots etc, that need to not have so many defects).
I can't seem to find the reference to the 95% defect fixes, it is either in Rapid Development or in Applied Software Measurement by Caper Jones.
Here is a link to a useful strategy for attacking code quality:
http://www.gamedev.net/reference/articles/article1050.asp
The client, of course, would likely balk at that number and might say no more than 1 hour of downtime per year is acceptable. That's 12 times more stable. Do you tell the customer, sorry, we can't do that for $100,000, or do you make your best attempt, hoping your analysis was conservative?
Flat out tell the customer what they want isn't reasonable. In order to gain that kind of uptime, a massive amount of money would be needed, and realistically, the chances of reaching that percentage of uptime constantly just isn't possible.
I personally would go back to the customer and tell them that you'll provide them with the best setup with 100k and set up an outage report guideline. Something like, for every outage you have, we will complete an investigation as to why this outage happened, and how what we will do to make the chances of it happening again almost non existent.
I think offering SLAs is just a mistake.
I think the answer to this question depends entirely on the individual application.
Software that has an impact on human safety has much different requirements than, say, an RSS feed reader.
The project triangle is a gross simplification. In lots of cases you can actually save time by improving quality. For example by reducing repairs and avoiding costs in maintenance. This is not only true in software development.Toyota lean production proved that this works in manufacturing too.
The whole process of software development is far too complex to make generalizations on cost vs quality. Quality is a fuzzy concept that consists of multiple factors. Is testable code of higher quality than performant code? Is maintainable code of higher quality than testable code? Do you need testable code for an RSS reader or performant code? And for a fly-by-wire F16?
It's more productive to make informed desisions on a case-by-case basis. And don't be afraid to over-invest in quality. It's usually much cheaper and safer than under-investing.
To answer in an equally simplistic way..
..When you stop hearing from the customers (and not because they stopped using your product).. except for enhancement requests and bouquets :)
And its not a triangle, it has 4 corners - Cost Time Quality and Scope.
To expand on what "17 of 26" said, the answer depends on value to the customer. In the case of critical software, like aircrafct controller applications, the value to the customer of a high quality rating by whatever measure they use is quite high. To the user of an RSS feed reader, the value of high quality is considerably lower.
It's all about the customer (notice I didn't say user - sometimes they're the same, and sometimes they're not).
Chasing the word "Quality" is like chasing the horizon. I have never seen anything (in the IT world or outside) that is 100% quality. There's always room for improvement.
Secondly, "quality" is an overly broad term. It means something different to everyone and subjective in it's degree of implementation.
That being said, every effort boils down to what "engineering" means--making the right choices to balance cost, time and key characteristics (ie. speed, size, shape, weight, etc.) These are constraints.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Now I want to make app to show pic from server.But found it is so slowly to make the pics come out. Is there any way or code to make the http request be more faster?
Approach the problem from a different angle. Think it as an entropy/economy thing.
There is two distant point in the problem you are describing and they want to transfer a data between them. Lets say this is going to cost 100 units to realize in ideal conditions. And again lets assume it is not possible to further lower this cost. This cost is where the energy required to transfer is minimum
Now assuming that transfer rates are not under our control. Here are some theoretical "seemingly" improvements which are actually just different trade-off sets.
Forward Caching / Caching: Preload/download all images whenever possible so they will be ready when the user requests them. Install everything static with the first time installation.
Trade-off: You spent most of your 100 points on disk space and pre-process power this may make your app go little slower always but the performance will be great once they are loaded on disk. Effectiveness decrease as images you want changes frequently
Compression / Mapping: If your bottleneck is at transfer rates compress/map the images as much as you can so they will be transferred with low cost but when they arrive you will use much processor power once they arrive at the app.
Trade-off: CPU power is used a lot more then before but while in transfer they will be moving fast. Side that compresses uses a lot more memory and side that decompress also uses more memory and CPU. Only good if your images are slow moving because they are huge then you will see this trade-offs benefits. If you want to try this install 7z and check advanced zipping settings and try really huge maps.
Drawing algorithms: If your images are drawings instead of bitmaps/real pictures. Send only vector graphics format, change all your pictures(raster images to be technical) to vector images. Will greatly reduces the number of bytes to carry an image to app but it will need more processor power at the end.
Trade-off: Aside from not all pictures can be converted to vector graphics. you are going to be using more CPU and memory but there excellent libraries already built in which are very optimized. You can also think this as "mathematical compression" where a single infinite line can not be stored in any computer in universe a simple one line mathematical expression such as x = y + 1 will make it happen.
Write your own server: If you are sure the bottleneck is at the communication time with the service provider(in this case a http server which is most probably very efficient). Write you own server which answers you very quickly and starts sending the file. The likely hood of this improvements is to low to even talk about a trade off.
Never be forced to send repeating information: Design and tag your information and pictures in such a way. You will only send non-repeating chunks where the receiving side will store any chunk received to further improve its cache of information.
Trade-Off:Combination of 1,2 and 3 you this is just another form of disturbing 100 points of cost. You get the point.
BitTorrent Ideology:If the bottleneck is your servers bandwidth there is a simple formula to see if using your user's bandwidth is logical and have positive effects. Again it is probably only effective if your data set is very large.
Trade-Off: This is an interesting option to discuss about trade-off. You will be using your users bandwidth and proximity to compensate for your servers lack of bandwidth. It requires a little bit more CPU then conventional way of acquiring data(Maintain more TCP connections)
As a closing note: There can not be a function call that can improve and make the cost of transferring information from 100 points to 95 points. In current technology level it seems that that we are really close to effectively transfer. I mean compression, mapping and various other techniques are pretty mature including network transfer methodologies but there is always a room for improvement. For example currently we think sending data with the light speed is the absolute maximum as they are electrical signals but quantum entangled observation technique denies this limit where two entangled particles theoretically send and receive information in infinite speed across universe(??). Also If you can develop a better and more efficient way of compression that will be awesome.
Anyway, as you have asked a question which does not provide much information where we can talk. I would strongly recommend thinking like an engineer, creating a test environment pointing out to the main cause and attacking it with all you got. If you can define the problem with better mathematical expression or pointing out the bottleneck we can answer it better than generic information theory.
Also one last note. I am not saying information transfer is not going to be any more efficient it may go up %1000 percent tomorrow, I am just saying this field is pretty mature to get any huge improvements without working on mathematics and theory for years. Like any other field of research.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
how to expand spinner time ?
From The Nature of Time:
The Nature of Time
We have all been asked the question
'what is the time?', but this entry
will be addressing the subtly
different question: 'what is time?'
Many people, on being asked this
question, would probably say that they
don't have the time to answer. In this
entry, we will explore many theories
about the nature of time. No one
theory has unquestioning truth about
it, so it will be up to you to decide
on the one you see is best.
The Classical Approach to Time
There is not very much to say on this
theory since it is the one with which
we are most familiar. Traditionally,
time is simply seen as a measure of
the distance between events. It has a
past, present and a future. The past
is considered to have already happened
and to be unchangeable, while the
future is considered to be open to
many possibilities. Humans measure
time using many units, some based on
real events like the rotation of the
Earth, others that are even more
arbitrary.
Isaac Newton's classical description
of time in his highly-regarded work
Principia is that it 'flows equably of
itself', which means that time 'flows'
at a constant rate that is the same
for everybody - it is independent of
the events that take place in it. It
would be untrue to say that this idea
was unchallenged until the twentieth
century - the 18th-Century empiricist
philosopher George Berkeley, for
example, disagreed with Newton and
held that time was 'the succession of
ideas in the mind' - but there was no
serious evidence to suggest that
Newton's elegant and absolute
description was wrong until Einstein
destroyed it.
Unfortunately, the classical view of
time is biased towards the human
perception of the 'flow' of time. We
see events in one direction, and we
assume time to be the same everywhere.
The classical approach to time does
not explain exactly why we perceive
time in this way, and it does not
describe how the effect is achieved.
The other theories of the nature of
time challenge the very roots of this
natural point of view.
Relativity
The Theory of Relativity is the
celebrated discovery of the physicist
Albert Einstein. Originally, it was
two theories: the Special Theory of
Relativity came first in 1905 and
states that the rate at which time
passes is not the same all over the
universe - it is dependent on the
observer (in other words, it is
relative). It is not hard to see that
different people perceive the passing
of time at a different rate to others:
as we get older, less information is
processed about our surroundings per
second, so we perceive time to be
going faster.
But Einstein's theory went further
than this. The relativity of time is
based not on our age, but on our speed
of movement through space. The faster
we travel through space, the slower we
travel through time. Although this
sounds crazy at first, it makes sense
when thought of in a particular way.
The theory of relativity demands that
we view space and time not as separate
entities but as one concept called
space-time. Time becomes a fourth
dimension, just like the other three
dimensions of space that we are used
to (height, width and length). This
view of time is crucial to
understanding most of the other
theories about time's ultimate nature.
Humans only possess two-dimensional
retinae (the light-receptive surface
at the back of our eyes), which means
that we can only see in two
dimensions. Our vision of the third
dimension is a result of perspective
and the existence of our binocular
vision. If we had three-dimensional
retinae, we would be able to see all
of an entire room simultaneously - its
walls, its floor and its ceiling at
the same time! For this reason, it is
very difficult, if not totally
impossible, for humans to visualise a
fourth dimension.
To overcome this impairment, it is
useful to use lower-dimensional
analogies when talking about
dimensions above three, even if we are
talking about time as one of these
dimensions. So in this case, let us
imagine that the universe is shaped
like a cuboid1, and that humans are
two-dimensional and have
one-dimensional retinae. Imagine that
the spatial dimensions are the width
and height of a cross-section of the
cuboid, meaning that humans can move
up, down, left and right at will
within the cuboid. Imagine that the
depth of the cuboid is time.
Right, now imagine that you are a
two-dimensional human within the
cuboid and that you start off being
midway up the cuboid. Then you start
moving upward (ie, through space, but
not time). Eventually you hit the edge
of the cuboid. Now imagine that you
move downwards, but that you also move
through time in a forward direction.
This time it will take you longer to
get back to being mid-way up the
cuboid because you are not taking a
direct route downwards - you are also
moving through time. As you can see,
moving through time slows down your
movement in space.
It works the other way around too. If
you stay still in space and just move
forward in time, then it will take
less time to get to a particular point
in time than if you move upwards and
forwards in time simultaneously. So
movement in space slows down your
movement in time. This is what
relativity states about how time
really is. However, the amount by
which time is slowed down when you
move through space is very small in
everyday situations, and you would
need to move at a speed of a
considerable percentage the speed of
light in order for it to make any
noticeable difference.
Relativity has been proven too. Atomic
clocks2 have been placed in aeroplanes
moving at high speeds and then
compared with clocks that were on
Earth. Slight differences that are
exactly predicted by the mathematical
equations of relativity were indeed
detected.
The general theory of relativity goes
a step further and was published in
1916. Einstein stated that mass curves the 'fabric' of space-time to create
the illusion of the force of gravity.
Again, a lower-dimensional analogy is
best. Imagine putting bowling balls on
a sheet of rubber. They bend the
rubber. Any object coming into the
vicinity of the curve begins to move
around the curve like something
spiralling around a sink basin.
Einstein's picture of gravity is that
simple. And again, this has been
proved. Einstein made predictions
about how light would be taking
technically curved paths around large
masses, and this effect was measured
during a total eclipse of the sun.
Time and Determinism
You will have noticed that the theory
of relativity does not carry any
description of a 'flow' of time, and
in fact, it describes time in almost
exactly the same way that we are used
to thinking about space. Relativity
unifies space and time. All points in
space are in existence simultaneously
- this is common sense; so are all points in time in existence
simultaneously too? This would suggest
that all events in time are already
'here' and that there is no scope for
choosing what happens in the future.
This view of time is called
determinism because events are
pre-determined.
It is worth noting that relativity
does not rule out the idea of free
will, but does not provide any support
for it either. Many people can get
upset about the evidence supporting
determinism because humans like to
think they have a free will to make
independent decisions. Such people
would not feel better if they heard
about the many worlds theory of
quantum mechanics.
Time in the Many Worlds Theory of
Quantum Mechanics
To understand this theory, we need to
go back to our cuboid example. You
will notice that each event in time is
simply a cross-section of the cuboid
(a square). Humans effectively
perceive the dimension of time in this
cuboid to be a succession of these
squares. Like frames in a movie, these
create the illusion of a smooth
passage of time. But why is it that we
see time like this? The answer to this
question will be explored later.
If you think about the world around
you, you will most likely notice that
it seems to have been tailor-made for
life. The universe has the precise
properties that led to the formation
of life on Earth. For example, in the
early universe there was a 'battle'
between matter and anti-matter3. The
particles with the certain quantum
properties that we now characterise as
'matter', for a hitherto inexplicable
reason, won the battle. If this hadn't
happened, we could not exist, or we
would not be the same as we are today.
Many physicists have speculated that
this and other similar events are too
much of a coincidence to be regarded
as just that: a coincidence.
Martin Rees, the Astronomer Royal of
the UK, paints an analogous picture of
going into a clothes shop. If you go
into a clothes shop that only sells
one size of clothing, it would be a
big coincidence if you found it was
your size. However, we get no surprise
when finding our own clothes size in a
clothes shop because good clothes
shops sell a wide range of clothes
sizes. We can now extend this picture
to the universe. It is very unlikely
that the universe should exist because
of how biased it seems to have been
towards gravitational stability and
the creation of diverse life later on.
However, if we see the universe as
providing a wide range of 'universes'
of different properties, it will come
as no surprise if we find one universe
that supports life.
You can think of this theory as
multiple cuboids in a vast universe of
cuboids, all with their own
space-time. Each cuboid represents one
universe that has a different set of
laws of physics, and therefore could
be wildly different from all the other
universes. There may in fact be a
large number of universes that support
life but with small differences, just
as there might be many shirts of your
size in the clothes shop, but perhaps
in different colours.
In this view, there are multiple
timelines. Some people have likened
this view of time to train tracks. We
move along a train track in one
direction, but there are huge numbers
of other train tracks running parallel
to ours. Each train track may be
different in some way (it might have
trains on it, for example). For this
reason, the other universes around us
in this 'multiverse'4 are referred to
as parallel universes.
A multiverse of space-times is not
just a theory that solves the question
of why our environment is so suited to
life; it is also a theory of quantum
mechanics. In the quantum theory there
are many events that take place
because of random chance. In electric
currents, for example, the electrons
that make up the current follow a
random path in the wires that is
influenced by a fields of electrical
forces they pass through, which is why
it always seems that the current is
split 50:50. Many physicists believe
that with each quantum decision like
this, every possibility has a separate
universe in which it is enacted.
Hence, in one universe the electron
goes one way; in another, it goes the
other way.
In this theory - which is called the
many worlds interpretation of quantum
mechanics - every possibility gets
enacted. Since quantum interactions
are the fundamentals of any larger (or
'macroscopic') reaction, we can infer
that everything happens in one
universe or other. So if you have a
decision to make, say whether to take
a holiday to Hawaii or not, there is
one universe where you go, and one
universe where you don't. This also
spells trouble for free will. All
possibilities get played out, so it is
just a matter of which universe you
are in to determine which way you go.
There is a variation of this theory.
For this variation we will need to
think another dimension lower. So,
instead of imagining universes as
cuboids, we need to imagine them as
rectangles. Imagine the length of the
rectangle is time; and its other
dimension, space. The rectangle has no
thickness whatsoever, so if you put
multiple rectangles (ie, multiple
universes) on top of each other, the
whole structure becomes no thicker.
This version of the many worlds
interpretation is slightly easier to
grasp, because otherwise we would have
universes branching off from one
another to eternity, which is rather
difficult to imagine. There is no real
evidence for or against either of the
theories of the multiverse,
unfortunately.
You will have noticed that in all
these theories, time has two
directions just like all the other
dimensions. In theory, there is
nothing to stop us from moving in the
other direction. There is another
slightly different theory of time as
being bi-directional, and you might
also be interested to see how this
could lead to possibilities of
time-travel.
Why Do We Perceive Time the Way We Do?
What, then, is time? If no one asks
me, I know what it is. If I wish to
explain it to him who asks me, I do
not know.
- St Augustine. If time is a dimension just like all the others,
why do we experience it so
differently? This is the question that
interests James Hartle of the
University of California in Santa
Barbara, along with physicists Stephen
Hawking, Murray Gell-Mann and Steven
Weinberg. They believe that the
passage of time is just an illusion.
Hartle thinks that time's arrow is a
product of the way we process
information. Gell-Mann gave creatures
that process time in this way the name
'information gathering and utilising
systems' (IGUSs). Humans are IGUSs.
Because of our two-dimensional
retinae, we can't take in multiple
cross-sections of the 'cuboid' - ie
'frames' of time - simultaneously. We
gather information about this frame -
our surrounding environment - using
our senses, and then we store the
information in an input register. This
does not have an unlimited capacity,
so we have to transfer the information
to our memory registers before we can
input the information about the next
frame. Humans have a short-term and a
long-term memory, as well as our
cerebellums that store 'unforgettable'
information (such as how to swim).
IGUSs also carry something called a
'schema', which is a generalised model
of our perception of our environment.
It holds several rules about what is
best to do and what is not a good idea
to do. The information we receive from
our surroundings is passed to the
schema to determine how we react in
certain situations. The decision is
conscious, but we also do unconscious
computation of information: the schema
is updated unconsciously. The
conscious part of the IGUS in humans
focuses on the input register, which
we call the present. The unconscious
part focuses on information in the
memories, and we call that the past.
This is why we consciously experience
the present and remember the past.
The movement of the information
through the IGUSs registers creates
the illusion of the flow of time. It
is not time itself that flows. Each
IGUS has a different speed for the
flow of its information between
registers. This corresponds to
differences between the perception of
the speed of the flow of time. Flies,
for example, need to process more
information per second in order to fly
so quickly but still avoid common
obstacles; therefore, they perceive
time as going slower. To us, a fly's
perception of time would look like
slow motion. Flies only live for a few
days, or a few weeks as a maximum, and
to a human, this is a very short
lifetime. But to a fly, this feels a
lot longer.
So the reason that we experience a
'flow' of time could just be because
of how we process information. It is a
competitive advantage to us as a
species to process information bits at
a time. It wouldn't make sense for us
to have evolved with the capability to
see all time simultaneously.
Digital Time, or, Is Time Like a
Movie?
You may have noticed a reference to
'frames' of time in the explanations
above. We usually think of time as
continuous - a smooth passage of
events. However, most physical
theories define space and time as
being the opposite of a continuous
passage of events. M-theory and Loop
Quantum Gravity, for example, are both
serious scientific theories (not
proven theories, though) that state
that space and time have minimum
units. There was even a theory of
quantum mechanics to suggest that time
was made of particles called
'chronons'!
The theorised minimum length of time
possible is called the Planck time and
is equivalent to 10-43 seconds. When
space or time is 'digital' like this,
we say that it is 'discrete'.
If this theory is true, then our
perception of time could be like a
movie. Movies are not continuous: if
you slow them down enough, you see
that they are just collections of
still photographs played in quick
succession. We process information
about our surroundings and obtain a
picture just like one frame of a movie
or animation. When 'played' in quick
succession, this creates the illusion
of smooth, continuous movement.
Is Time Really That Much Like Space?
So far, time has been seen as very
much like a dimension of space, and
its passage in one direction has been
seen as an illusion. But there are
some counter-arguments; there are
still some big differences between
time and space that cannot easily be
explained as illusions.
One way of supporting the idea that an
'arrow of time' is irrelevant is by
proving that all processes are the
same if done forwards or backwards. In
quantum mechanics, most interactions
between particles are 'time-symmetric'
- it doesn't matter whether you look at them from past to future or future
to past because they look the same.
But this is not true of macroscopic
objects. Wine glasses shatter, but you
rarely see shards of glass assemble
themselves into wine glasses.
Physicists can explain why shards of
glass do not form wine glasses by
postulating the existence of 'the
thermodynamic arrow of time'.
Thermodynamics is basically a
collection of laws. Here is how the
chemist PW Atkins summarises them:
There are four laws. The third of
them, the Second Law, was recognised
first; the first, the Zeroth law, was
formulated last; the First Law was
second; the Third Law might not even
be a law in the same sense as the
others. The gist of it is that the
universe is always becoming more
disordered. The disorder of the
universe is called 'entropy', so we
say that entropy is always increasing.
Nobody really knows why this is the
case, but we see it all the time in
experiments. This is why heat always
flows into colder areas, but never the
other way round. Heat is simply the
result of giving particles in a given
system more energy; they begin to move
and vibrate randomly, which is a
disordered state. Colder things are
more ordered because their constituent
particles tend to be harder to move.
This in-built arrow explains why
macroscopic objects have irreversible
interactions. This is a clear
difference from space. If you think of
the spatial manifestation of a table,
it does not follow that one end of the
table is more disordered than the
other, but it does follow that the
table will end up more disordered in
the future than when it has just been
made. Hence, there is a very distinct
difference between time and space.
Can Time Be Reversed?
If time's 'flow' in one direction
really is an illusion, what is there
stopping us from reversing it? In
theory, nothing! Lawrence Schulman of
Clarkson University in New York
thoroughly believes that time can run
backwards. In other words, shards of
glass can turn into wine glasses,
people grow younger and younger and
the universe gets smaller and smaller.
In fact, Schulman goes as far as to
say that such reversed-time zones can
exist as spaces within our own
universe. A computer simulation has
shown that regions with opposite time
arrows do not cancel each other out
and do not disturb each other at all.
The great thing about this theory is
that if a civilisation in a
reversed-time region kept records of
events that occur in our future, the
records might have survived to our
past (which is their future). Finding
these records could tell us the
future. This is, of course, a long
shot, but still a physical
possibility.
Another possibility is that the
universe's arrow of time (as far as
thermodynamics is concerned) will
naturally reverse itself at a crucial
point in the history of the universe.
At this point, the universe would
start to get smaller and everybody
would get younger until there was a
big crunch analogous to the big bang.
This creates a perfect symmetry to the
universe.
Again, there is little evidence that
shows us that reversed-time regions
exist, and there is no evidence that
the universe's thermodynamic arrow of
time will naturally reverse itself.
Equally, there is little evidence
against these theories either.
So what is time? Is it a dimension
just like space? Does it flow, or is
that just an illusion? Is time digital
like the frames of a movie, or does it
flow continuously? And can time really
be reversed or manipulated? None of
these questions can be answered with
definite confidence, but next time
somebody asks you what the time is,
perhaps you'll think of the answer
differently.
Kernel::sleep ?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
G'day,
I was reading the item Quantify in the book "97 Things Every Software Architect Should Know" (sanitised Amazon link) and it got me wondering how to quantify scalability.
I have designed two systems for a major British broadcasting corporation that are used to:
detect the country of origin for incoming HTTP requests, or
determine the suitable video formats for a mobile phones's screen geometry and current connection type.
Both of the designs were required to provide scalability.
My designs for both systems are scalable horizontally behind caching load-balancing layers which are used to handle incoming requests for both of these services and distribute them across several servers which actually provide the service itself. Initial increases in service capacity are made by adding more servers behind the load-balance layer, hence the term horizontal scalability.
There is a limit to the scalability of this architecture however if the load balance layer starts having difficulty coping with the incoming request traffic.
So, is it possible to quantify scalability? Would it be an estimate of how many additional servers you could add to horizontally scale the solution?
I think this comes down to what scalability means in a given context and therefore the answer would be it depends.
I've seen scalability in requirements for things that simply didn't exist yet. For example, a new loan application tool that specifically called out needing to work on the iPhone and other mobile devices in the future.
I've also seen scalability used to describe potential expansion of more data centers and web servers in different areas of the world to improve performance.
Both examples above can be quantifiable if there is a known target for the future. But scalability may not be quantifiable if there really is no known target or plan which makes it a moving target.
I think it is possible in some contexts - for example scalability of a web application could be quantified in terms of numbers of users, numbers of concurrent requests, mean and standard deviation of response time, etc. You can also get into general numbers for bandwidth and storage, transactions per second, and recovery times (for backup and DR).
You can also often give numbers within the application domain - let's say the system supports commenting, you can quantify what is the order of magnitude of the number of comments that it needs to be able to store.
It is however worth bearing in mind that not everything that matters can be measured, and not everything that can be measured matters. :-)
The proper measure of scalability (not the simplest one;-) is a set of curves defining resource demanded (CPUs, memory, storage, local bandwidth, ...), and performance (e.g. latency) delivered, as the load grows (e.g. in terms of queries per second, but other measures such as total data throughput demanded may also be appropriate for some applications). Decision makers will typically demand that such accurate but complex measures be boiled down to a few key numbers (specific spots on some of the several curves), but I always try to negotiate for more-accurate as against simpler-to-understand measurements of such key metrics!-)
When I think of scalability I think of:
performance - how responsive the app needs to be for a given load
how large a load the app can grow into and at what unit cost (if its per server include software, support, etc)
how fast you can scale the app up and how much buffer you want over peak period usage (we can add 50% more bandwidth in 2-3 hours and require a 30% buffer over planned peak usage)
Redundancy is something else, but should also be included and considered.
"The system shall scale as to maintain a linear relationship of X for cost/user".
Here's one way:
"assume that a single processor can process 100 units of work per second..."
From http://www.information-management.com/issues/19971101/972-1.html
As a programmer I make revolutionary findings every few years. I'm either ahead of the curve, or behind it by about π in the phase. One hard lesson I learned was that scaling OUT is not always better, quite often the biggest performance gains are when we regrouped and scaled up.
What reasons to you have for scaling out vs. up? Price, performance, vision, projected usage? If so, how did this work for you?
We once scaled out to several hundred nodes that would serialize and cache necessary data out to each node and run maths processes on the records. Many, many billions of records needed to be (cross-)analyzed. It was the perfect business and technical case to employ scale-out. We kept optimizing until we processed about 24 hours of data in 26 hours wallclock. Really long story short, we leased a gigantic (for the time) IBM pSeries, put Oracle Enterprise on it, indexed our data and ended up processing the same 24 hours of data in about 6 hours. Revolution for me.
So many enterprise systems are OLTP and the data are not shard'd, but the desire by many is to cluster or scale-out. Is this a reaction to new techniques or perceived performance?
Do applications in general today or our programming matras lend themselves better for scale-out? Do we/should we take this trend always into account in the future?
Because scaling up
Is limited ultimately by the size of box you can actually buy
Can become extremely cost-ineffective, e.g. a machine with 128 cores and 128G ram is vastly more expensive than 16 with 8 cores and 8G ram each.
Some things don't scale up well - such as IO read operations.
By scaling out, if your architecture is right, you can also achieve high availability. A 128-core, 128G ram machine is very expensive, but to have a 2nd redundant one is extortionate.
And also to some extent, because that's what Google do.
Scaling out is best for embarrassingly parallel problems. It takes some work, but a number of web services fit that category (thus the current popularity). Otherwise you run into Amdahl's law, which then means to gain speed you have to scale up not out. I suspect you ran into that problem. Also IO bound operations also tend to do well with scaling out largely because waiting for IO increases the % that is parallelizable.
The blog post Scaling Up vs. Scaling Out: Hidden Costs by Jeff Atwood has some interesting points to consider, such as software licensing and power costs.
Not surprisingly, it all depends on your problem. If you can easily partition it with into subproblems that don't communicate much, scaling out gives trivial speedups. For instance, searching for a word in 1B web pages can be done by one machine searching 1B pages, or by 1M machines doing 1000 pages each without a significant loss in efficiency (so with a 1,000,000x speedup). This is called "embarrassingly parallel".
Other algorithms, however, do require much more intensive communication between the subparts. Your example requiring cross-analysis is the perfect example of where communication can often drown out the performance gains of adding more boxes. In these cases, you'll want to keep communication inside a (bigger) box, going over high-speed interconnects, rather than something as 'common' as (10-)Gig-E.
Of course, this is a fairly theoretical point of view. Other factors, such as I/O, reliability, easy of programming (one big shared-memory machine usually gives a lot less headaches than a cluster) can also have a big influence.
Finally, due to the (often extreme) cost benefits of scaling out using cheap commodity hardware, the cluster/grid approach has recently attracted much more (algorithmic) research. This makes that new ways of parallelization have been developed that minimize communication, and thus do much better on a cluster -- whereas common knowledge used to dictate that these types of algorithms could only run effectively on big iron machines...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am interested in doing some Collective Intelligence programming, but wonder how it can work?
It is said to be able to give accurate predictions: the O'Reilly Programming Collective Intelligence book, for example, says a collection of traders' action actually can predict future prices (such as corn) better than an expert can.
Now we also know in statistics class that, if it is a room of 40 students taking exam, there will be 3 to 5 students who will get an "A" grade. There might be 8 that get "B", and 17 that got "C", and so on. That is, basically, a bell curve.
So from these two standpoints, how can a collection of "B" and "C" answers give a better prediction than the answer that got an "A"?
Note that the corn price, for example, is the accurate price factoring in weather, demand of food companies using corn, etc, rather than "self fulfilling prophecy" (more people buy the corn futures and price goes up and more people buy the futures again). It is actually predicting the supply and demand accurately to give out an accurate price in the future.
How is it possible?
Update: can we say Collective Intelligence won't work in stock market euphoria and panic?
The Wisdom of Crowds wiki page offers a good explanation.
In short, you don't always get good answers. There needs to be a few conditions for it to occur.
Well, you might want to think of the following "model" for a guess:
guess = right answer + error
If we ask a lot of people a question, we'll get lots of different guesses. But if, for some reason, the distribution of errors is symmetric around zero (actually it just has to have zero mean) then the average of the guesses will be a pretty good predictor of the right answer.
Note that the guesses don't necessarily have to be good -- i.e., the errors could indeed be large (grade B or C, rather than A) as long as there are grade B and C answers distributed on both sides of the right answer.
Of course, there are cases where this is a terrible model for our guesses, so collective intelligence won't always work...
Crowd Wisdom techniques, like prediction markets, work well in some situations, and poorly in others, just as other approaches (experts, for instance) have their strengths and weaknesses. The optimal arenas therefore, are ones where no other approaches do very well, and prediction markets can do well. Some examples include predicting public elections, estimating project completion dates, and predicting the prevalence of epidemics. These are areas where information is spread around sparsely, and experts haven't found effective models that reliably predict.
The general idea is that market participants make up for one another's weaknesses. The expectation isn't that the markets will always predict every outcome correctly, but that, due to people noticing other people's mistakes, they won't miss crucial information as often, and that over the long haul, they'll do better. In cases where the exerts actually know the answer, they'll be able to influence the outcome. Different experts can weigh in on different questions, so each has more influence where they have the most knowledge. And as markets continue over time, each participant gets feedback from their gains and losses that makes them better informed about which kinds of questions they actually understand and which ones they should stay away from.
In a classroom, people are often graded on a curve, so the distribution of grades doesn't tell you much about how good the answers were. Prediction markets calibrate all the answers against actual outcomes. This public record of successes and failures does a lot to reinforce the mechanism, and is missing in most other approaches to forecasting.
Collective intelligence is really good at coming up to to problems that have complex behavior behind them, because they are able to take multiple sources of opinions/attributes to determine the end result. With a setup like this, training helps to optimize the end result of the processes.
The fault is in your analogy, both opinions are not equal. Traders predict direct profit for their transaction (the little part of the market they have overview over), while the expert tries to predict the overall field.
IOW the overall traders position is pieced together like a jigsaw puzzle based on a large amount of small opinions for their respective piece of the pie (where they are assumed to be experts).
A single mind can't process that kind of detail, which is why the overall position MIGHT overshadow the real expert. Note that this is particularly phenomon is usually restricted to a fairly static market, not in periods of turmoil. Expert usually do better then, since they are often better trained and motivated to avoid going with general sentiment. (which is often comparable to that of a lemming in times of turmoil)
The problem with the class analogy is that the grading system doesn't assume that the students are masters in their (difficult to predict) terrain, so it is not comparable.
P.s. note that the base axiom depends on all players being experts in a small piece of the field. One can debate if this requirement actually transports well to a web 2 environment.