> > 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

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

> 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
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)

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