Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
MTS vs Westwind server pooling
Message
De
20/10/1999 14:00:09
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
Applications Internet
Titre:
MTS vs Westwind server pooling
Divers
Thread ID:
00278989
Message ID:
00278989
Vues:
48
These are quotes directly from westwind's white page on large scale web apps at www.west-wind.com/presentations/largeweb

He is pointing out inherent weaknesses in MTS the way it handles Pool management. He seems to say that each time you connect to a server it is re-loaded, while westwind preloads all its servers, which greatly reduces the amount of overhead. I'm looking for understanding, so if this information is incorrect please let me know.


"MTS in its current state does not provide server pooling – it only provides server deactivation and reactivation of unused servers without the client knowing about it. Works like this: You connect to a server, then call MTS's SetAbort or SetComplete method, which releases the server's context and actually causes MTS to release the server. If you call the server again with the same reference MTS automatically reloads the COM object and then calls the method. Lot of overhead here, but it can be useful if you have huge numbers of simultaneous clients who have persistent connections to your server. Typical Web Applications don't work this way though – current models use either a limited pool of client connections or each request loads and unloads the server on its own (CreateObject and Release, which is typical for ASP applications). The only scenario that would fit the MTS activation model is assigning object references to ASP Session vars and keeping the reference around, but this would probably be as slow or slower than loading and unloading the object on each page with no gain in scalability at all."

"Pool of Single Use EXE or InProc DLL servers
For scalable Web applications the pool managers built into these tools provide much better control over the load placed on a machine by allowing a pool of objects to be created and references being passed off out of that pool. The benefit here is that the servers are already loaded and only direct method calls occur. ISAPI directly talks to the pool manager, which is built into the ISAPI extension. The pool is also managed and kept to a predetermined size so if your server gets too busy you don't overload your machine with too many simultaneously running servers that would kill the server on CPU load – pending requests are queued until servers become available."
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform