> Sorry, but you are again making assumptions about the solution without 
> giving the requirements.
> I can't give you correct advice it you don't tell me the numbers I asked. 
> Don't think about servers, cpu, timouts, sessions and the like. Only what 
> the application require seen from the highest level possible.
That's clear. I think I answered all question, though I'd eliminate
the superlatives. When we talk about scalability, there should be no
highest possible level. It is always possible to reach a level higher than
the planned "highest", and the application must be easily (without
redesign/rebuild) scaled to the new level. This is why I preferred to talk
about numbers per server, not overall values.

> You can buy devices to load-balance your application to several servers. For 
> example: http://www.cisco.com/en/US/products/hw/contnetw/ps792/
Hm, hardware, it seems like a very expensive and straightforward approach.
We'd like to use it as the last thing. And the more, I'm not sure the device
(content service switch or something similar) will allow us to create and
maintain a cluster of distributed COM-objects automatically. I foresee large
additional efforts to be made for balancing of the application servers.

> >> - What is the maximum allowed latency time ?
> > 1 second.
> This is a quite low latency time for a web application. Usually transport 
> over internet make this time simply much larger.
In fact, yes. My answer was actually the desired time. Maximum allowed is
indeed _undefined_ because the application is available through the Web,
and there is no way to guarantee the timing less then eternity.

> This processing is not the web server application. You have to use high end 
> servers to do the processing. This processing alone require selecting a 
> server with suitable CPU power. This is completely independent of the HTTP 
> transport if your application is designed properly.
Yes. Nevertheless, HTTP transport is involved, and I'd like to design this
part of the application in a proper way. In other words, my initial question is
related to web technologies and assumes that inner processing nuances
should/could/can be put aside to a certain degree.

> >> The question is: why would a session be 10 minutes ? Why not 10 seconds 
> >> or 10 hours ?
> > This number is deduced as an avarage value of use cases and ergonomics of 
> > the application.
> > The 10 min is given, and there is no place for "why".
> OK. Then we probably have a language problem (note that english is not my 
> native language). I would have said "since session timeout is set to 10 
> min...".
Oh. I think this is not the case of misunderstanding, though I'm also not
a native English speaker, you know. Even for the extended passage I'd answer
the same: the timeout is deduced from common practices. Lets say, the value lies
between 1 and 15 minutes, and 10 is the average. It's up to an administrator.

> This is 23 requests per second on average. If requests must be executed in 
> one second, it means you have - on average - 23 simultaneous connections.
Yes. Do you assume that 'simultaneous' = 'concurrent'? Then, the question:
>- How many concurrent users do you have to support ?
is in fact:
How many users/sessions per second do we have to support ?
I think I answered the question: 6000 for current configuration, 30000 -
in the near future. In fact, I don't think this is actually _concurrent_
users, because most of them are in idle state. And this seems the main
incomprehension I had. I hope the point is clarified now. If not, I apologize,
it seems my usually acceptable mental state is temporary unavailable ;-).

> Probably peaks with 2-3 times that number. You just need a good server.
Ha! But then what is the scalability at all? If we construct the application on
the single server, without any underlying scaling facilities, then what to do if
after a month or so we find out that real load exceeds the planned 100%?
To redesign/replace the single server architecture with another, more
sophisticated one? This is exactly what I'd like to make just now,
before we reach 100%. And I want the decision will work even then
the load becomes 1000%.

> Using ICS, it is easy and probably better to have a single HTTP server 
> application (no problem with 23 requests per second) which talk to your 
> application servers, probably using basic TCP (socket) communication.
Yes, this is possibly what we need, if not to be overoptimistic about
the service popularity growth.   But!
Currently we have COM-objects, running in asp-pages. Should we re-design
the objects in order to interact with ICS-based server? Every interface
should be replaced with corresponding TCP protocol, or SOAP wrappers
must be supplied, correct? I'm possibly wrong, but these are the only things
I can think of now as a work around. As far as I know, neither scripting nor
SOAP is supported by ICS out of the box, so we will need to implement
them from the ground. This is why I mentioned reverse-proxy in my initial
post. The proxy could allow us to preserve current architecture behind itself,
but the proxy itself requires consideration, designing, and development.

Best wishes,
Stanislav Korotky,
Russia, Moscow, GMT +3.00

To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to