COM+ or...what?
-
I am curious what would be a better design stategy for a Website that may have 10's of thousands of users. I am considering using: 1.) Object Pooling through COM+ 2.) Designing a component with Shared Variables so only one instance of it is created for all Clients (but this may be bad for things like DB Connections with an Open DataReader on them) 3.) Creating a new Object (of my own classes) for every Client. Does anyone have any suggestions? Should I be concerned with this at all? :wtf:
-
I am curious what would be a better design stategy for a Website that may have 10's of thousands of users. I am considering using: 1.) Object Pooling through COM+ 2.) Designing a component with Shared Variables so only one instance of it is created for all Clients (but this may be bad for things like DB Connections with an Open DataReader on them) 3.) Creating a new Object (of my own classes) for every Client. Does anyone have any suggestions? Should I be concerned with this at all? :wtf:
The default Max Connection Pool count in IIS is 100. This means you can have 100 connection objects allocated at any one time. Now, as long as you remember to close each connection as soon as you've finished with it, and as long as each query runs very quickly, then 100 connections in the pool should be able to cater to thousands of users accessing the site (each connection object is only used by each user for a very short period of time) You can always increase the Max Connection Pool count if there is a problem here. Try out a few stress tests to help you determine the best architecture. (Personally I'd steer clear of COM+ and think about a webservice if you want a seperate data access object) John www.silveronion.com[^]
-
The default Max Connection Pool count in IIS is 100. This means you can have 100 connection objects allocated at any one time. Now, as long as you remember to close each connection as soon as you've finished with it, and as long as each query runs very quickly, then 100 connections in the pool should be able to cater to thousands of users accessing the site (each connection object is only used by each user for a very short period of time) You can always increase the Max Connection Pool count if there is a problem here. Try out a few stress tests to help you determine the best architecture. (Personally I'd steer clear of COM+ and think about a webservice if you want a seperate data access object) John www.silveronion.com[^]
Thanks for the insight John. First, let me ask if you think designing a DLL with "Shared" variables would be a bad idea (i.e. a DataComponent that shares one Connection between all instances)? I always Connect / Disconnect as fast as possible in my DLLs since every Object created relies on the DataComponent for Database access. However, since this will be my first website, I cannot determine how fast the Queries will actually run and also how many Users will be trying to Query at the same time. I am just trying to determine before I start getting too heavy into the DataAccess Component how it should be designed. Currently, for WindowsForms apps, I go with the "Shared" Instance of the Class since it is only created one time per Client PC. I can see so far that "Connection Pooling" will kick in since the ConnectionStrings will always be the same no matter what. I would also like to steer clear of COM+ but I am looking into it as an option if I think it'll help in this situation. So I guess the only other alternative would be to create a New Instance of the DataComponent Class for every User and then Destroy it when not needed?
-
Thanks for the insight John. First, let me ask if you think designing a DLL with "Shared" variables would be a bad idea (i.e. a DataComponent that shares one Connection between all instances)? I always Connect / Disconnect as fast as possible in my DLLs since every Object created relies on the DataComponent for Database access. However, since this will be my first website, I cannot determine how fast the Queries will actually run and also how many Users will be trying to Query at the same time. I am just trying to determine before I start getting too heavy into the DataAccess Component how it should be designed. Currently, for WindowsForms apps, I go with the "Shared" Instance of the Class since it is only created one time per Client PC. I can see so far that "Connection Pooling" will kick in since the ConnectionStrings will always be the same no matter what. I would also like to steer clear of COM+ but I am looking into it as an option if I think it'll help in this situation. So I guess the only other alternative would be to create a New Instance of the DataComponent Class for every User and then Destroy it when not needed?
Mikasa, I don't think you should overcomplicate the application. The ASP.NET architecture has a natural 'split' into three tiers already; the web browser, the server-side .NET code, and the database backend. It's unlike conventional applications which require a tiered architecture to be developed. For example, developing a VB6 front-end which accesses a DCOM object on a server which reads a SQL database. When you write
Dim myConnection As New SqlConnection(connstr)in your ASP.NET code, that code is running on the server, the object is being created on the server, and the connection pool is being allocated on the server. It's already there, in the middle tier. The client tier is just the HTML code with the necessary buttons etc. - All the ASP.NET code sits on the server. Try it out. Stress test it. You might find it's easy to just keep everything in one place, rather than messing about with COM+. If you want to keep things neat, you can put all your DB access stuff into a nice class, but it's still running on the server the same as the rest of the .NET code. John www.silveronion.com[^] -
Mikasa, I don't think you should overcomplicate the application. The ASP.NET architecture has a natural 'split' into three tiers already; the web browser, the server-side .NET code, and the database backend. It's unlike conventional applications which require a tiered architecture to be developed. For example, developing a VB6 front-end which accesses a DCOM object on a server which reads a SQL database. When you write
Dim myConnection As New SqlConnection(connstr)in your ASP.NET code, that code is running on the server, the object is being created on the server, and the connection pool is being allocated on the server. It's already there, in the middle tier. The client tier is just the HTML code with the necessary buttons etc. - All the ASP.NET code sits on the server. Try it out. Stress test it. You might find it's easy to just keep everything in one place, rather than messing about with COM+. If you want to keep things neat, you can put all your DB access stuff into a nice class, but it's still running on the server the same as the rest of the .NET code. John www.silveronion.com[^]