> 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
