> > 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.
You are confusing everything. Cisco load balancer has nothing to do with your application. It's a HTTP load balancer which work at the lowest level, much like a router. It works whatever you use in the backend. COM objects are event not related to HTTP at all. It's just a way to make programs or parts of programs to talk to each other. Hardware is probably the only solution to fast load balancing with high number of users. > > 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'? I mean the number of user sending a request while another is still executing. In my mind simultaneous and concurrent is the same. And remember, I'm thinking about HTTP request, not the application which uses HTTP as transport. > 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. You are talking about application user. This is not important. Idle users do not count in the load. You just need a little bit of memory to store session data. No network bandwidth, no CPU load, no activity for idle users. And even no socket is needed for idle user since HTTP is a stateless protocol. So you must forget (well almost) about idle users. Only think about concurrent, simultaneous user. > And this seems the main incomprehension I had. > I hope the point is clarified now. Two users are considered as concurrent is their request are overlapping in time. The maximum number of concurrent user a HTTP system has is the number of requests which are overlapping at a given time. > Currently we have COM-objects, running in asp-pages. > Every interface should be replaced with corresponding TCP > protocol, or SOAP wrappers must be supplied, correct? ASP pages are slow compared to Delphi compiled code. ASP is a semi-interpeted language, that's why it is slow. COM objects are very slow at establishing the communication, particulary if you use late binding. Once the communication is setup (the object is loaded and the interface pointers are setup), communication is fast. DCOM is relatively slow compared to hand crafted protocol using sockets. SOAP is a very very slow protocol. Forget about it if you want to support large number of user without buying huge hardware ! > 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 Scripting is not related at all to TCP/IP (Remember ICS is a TCP/IP component suite). Anyway, scripting is also very very slow. Forget it if you want to support large number of user without buying huge hardware ! SOAP is a layer above HTTP. You can implement it using ICS. But I repeat: SOAP is a very very slow protocol. Forget about it if you want to support large number of user without buying huge hardware ! I could summarize our conversation like this: If you want to build a system supporting a large number of users, first use the right technologies. To design the system, think about software layers and optimize each layer using the correct tool for each layer. If you currently have a slow system based on ASP, COM, SOAP, SCRIPTING then throw everything away and start again using the right technologies. Or simply buy huger servers and continue to use heavsy, slow technologies. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be -- 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
