It is said as for code, developing a website that can stand 10,000
concurrent visitors is much different from developing a website that
can stand 1,000 concurrent visitors, is it true?
"tenxian"
news:99b73986-17ce-4a0a-871b-3b7f7d18762a@i29g2000prf.google groups.com...
> It is said as for code, developing a website that can stand 10,000
> concurrent visitors is much different from developing a website that
> can stand 1,000 concurrent visitors, is it true?
it's been said by an idiot then!
On Dec 20, 4:15 pm, tenxian
>
> It is said as for code, developing a website that can
> stand 10,000 concurrent visitors is much different from
> developing a website that can stand 1,000 concurrent
> visitors, is it true?
Since I don't know how to convert "concurrent visitors" into a more
commonly used unit (such as requests per second), I can't answer your
question as asked. However, there is one thing that sets high-load
application development apart; the application design should conform
to the expected deployment environment. In practice, it means that
applications that are to run on top of replicated databases can read
from any DB server in the replicating setup, but must write to one and
only one -- the master. So the application must maintain two separate
DB access routes -- one for reading, the other for writing.
Cheers,
NC
"NC"
news:96e9dff5-2c5e-44d0-8135-02adbcedfc37@i29g2000prf.google groups.com...
> On Dec 20, 4:15 pm, tenxian
>>
>> It is said as for code, developing a website that can
>> stand 10,000 concurrent visitors is much different from
>> developing a website that can stand 1,000 concurrent
>> visitors, is it true?
>
> Since I don't know how to convert "concurrent visitors" into a more
> commonly used unit (such as requests per second), I can't answer your
> question as asked. However, there is one thing that sets high-load
> application development apart; the application design should conform
> to the expected deployment environment.
You mean "production" environment.
> It is said as for code, developing a website that can stand 10,000
> concurrent visitors is much different from developing a website that
> can stand 1,000 concurrent visitors, is it true?
Well, an application that *only* can stand 1,000 concurrent visitors is
probably different from one that can only stand 10,000.
But if you really want to push the limits, you will have to know where
the weak spots of the system are. If they are in your software, you will
either have to fix that or work around them in other ways (by
load-balancing servers, for instance).
Regards,
--
Willem Bogaerts
Application smith
Kratz B.V.
http://www.kratz.nl/
On Dec 21, 2:15=A0am, tenxian
> It is said as for code, developing a website that can stand 10,000
> concurrent visitors is much different from developing a website that
> can stand 1,000 concurrent visitors, is it true?
It's all about the aim of the project. A 1000 concurrent visitor
project which uses complex database queries and processes will consume
more resources than a static site project with 10,000 concurrent
visitors or vice-versa.
However more visitors consumes more system resources (ram-cpu) - and
traffic, etc.
"Betikci Boris"
news:fa42e8cc-a641-4054-9678-25e230618240@a35g2000prf.google groups.com...
On Dec 21, 2:15 am, tenxian
> It is said as for code, developing a website that can stand 10,000
> concurrent visitors is much different from developing a website that
> can stand 1,000 concurrent visitors, is it true?
It's all about the aim of the project. A 1000 concurrent visitor
project which uses complex database queries and processes will consume
more resources than a static site project with 10,000 concurrent
visitors or vice-versa.
However more visitors consumes more system resources (ram-cpu) - and
traffic, etc.
======
numbnuts, you miss again! the 'aim of the project' doesn't change regarless
of expected hit rates!!! it's how you design it that *might*. you've just
tried to pass off an orange-to-apple comparison as valid advice.
zzzzzzzzzzz....