Re: How to handle large number of users
- From: "Paul Nichols [TeamB]" <paul@xxxxxxxx>
- Date: Sat, 19 Jan 2008 06:40:49 -0500
Sandeep Chandra wrote:
At this stage I am just trying to study what will be required to get such a big application to work. The reason I was asking this question here was to find out if anyone here has done anything this big and how to go about doing things for such a big job.
The client app will work on mobile phones using WinCE and it is just a small app updating some tables in the database on the server.
I think the system is mission critical as the mobile phone has to be disabled (disable calling and sms) based on certain conditions and if not done the company will loose money. So, if the company thinks they will have millions of user and if they loose 1 dollar on a single mobile they end up loosing millions.
Regards
Sandeep
Well that is a little more clarity on the situation and that helps explain EVERYTHING!! Yes I can easily see this as a 10 million user system now.
OK, that narrows the field somewhat, so now I would think that the data streams would be rather small. Is the client written to talk directly to the database or is the client still in the works as well? If the latter, I would not consider direct database connections. Why? hundreds, thousands, tens of thousands and hundreds of thousands of clients being able to control their own connectivity to a centralized database erver is not a good idea at all.
Here's what I would do; use a Database Pooling mechanism, that controlled the number of active connections to the DB server through the pool. You could use some type of configuration file (XML or other type) to set the number of connections allowed, time out properties, etc. When the max number of connections were reached, then you could put these systems in a holding pattern; that is a wait state until a connection is freed from the pool. Then this client would be allowed access.
This would ensure several things, including (1) You do not have to worry about too many simultaneous connections, (2) Socket connections and threads can be controlled in a better fashion. (3) You can raise or lower connections according to hardware and bandwidth.
The server side code should be multi-threaded for sure, but doesn't seem there is a lot of actual coding work to do. Mainly what you will be doing is checking for data integrity and inserting some data into a table/tables. I am assuming it would send back some value to the cell phone, to disable some features you were talking about. Should be a small bit of data sent back to the client.
Using the Data Connection Pool, database choices are greater. When you were first describing the system, Oracle or DB/2 would logically seem the only choices. I am surprised the carrier doesn't have a preferred Enterprise database. But with the merging of companies as they have done in the telecom industry, could be they have a mix of everything! :)
Personally, I could see you using anything from Postgresql to Oracle or DB/2. You are not going to be storing mountains of data, the streams will be small and the data capture should be relatively small (unless you are collecting transaction times, rates, etc).
Since this is a pretty important system, I think I would opt for a Database that has industry wide support behind it. Most of the Enterrpise level databases could easily handle this. However, which one you should choose, would depend upon the budget for the project and personal preference(s).
Performance on the server is not a major issue, except at the database connection and transaction level, under my assumption that the data stream being sent, is small. Lets say the average amount of data transmitted is 10K. Let's say that you have an initial DB Pool of 500 connections. Lets say that you have an average of 10,0000 users per minute hitting your application. Lets assume that your transaction rate for inserting and/or updating the database for the 10K data stream is 100 milliseconds. Lets add another 200 milliseconds for data integrity checks. This means that the total time to complete one transaction is, so far, 250 milliseconds. Since you are using a DB pool, you do not have to worry about creating the connections; they are already exant.
However, you do need to consider the amount of time it takes to retrieve the connection from the pool and decrement the pool. Lets say this is another 200 milliseconds total. So we have 250+200=450 milliseconds for one good transaction to complete. Let add some latency time and thread time for each process. Lets add latency time and thread lock time at another 500 milliseconds, just to be safe. So now we have 950 milliseconds for a transaction to complete. We need to add any error information into the equation, so lets add that at 200 milliseconds. Our total now is 1150 milliseconds, or 1.15 seconds for every 500 transactions. This means you can process 500 transactions every 1.1 seconds, or handle 10,000 users roughly every 25 seconds. Alas, there is your system metrics for transactions.
Now please understand these numbers are totally made up. But it gives you a starting point. It also provides you with the manner in which you should think about your coding your application and what acceptable performance is. This is where I would start.
In these scenarios, keep in mind the DB Pool and THREADING ARE CRITICAL TO YOUR APPLICATION. If your host system cannot handle the number of threads that are being passed in and held, nor can they handle the threaded DB Pool you use or create, you are going to have problems. Of course if that becomes a major issue, you could use more than one server to handle incoming transactions. Some load balancing server system, something like Big IP, could control load balancing between servers. This could also provide you with the ability to handle more transactions more efficiently. In addition, this would also provide immediate failover and redundancy.
That's where I would start. Now what you need to do is find out how large the data streams from the client will be, and what bandwidth restrictions are. Then using this data, you could build a simulated test system to track total transaction times per number of users. You could present these initial findings and find out what is acceptable performance and thus determine what type servers you need.
I wish you had told me in the beginning what the clients were and what type of app you were working with. Would have saved me a lot of typing. :)
Hope this helps and good luck!
.
- Follow-Ups:
- Re: How to handle large number of users
- From: Sandeep Chandra
- Re: How to handle large number of users
- References:
- How to handle large number of users
- From: Sandeep Chandra
- Re: How to handle large number of users
- From: Paul Nichols [TeamB]
- Re: How to handle large number of users
- From: Sandeep Chandra
- Re: How to handle large number of users
- From: Paul Nichols [TeamB]
- Re: How to handle large number of users
- From: Sandeep Chandra
- How to handle large number of users
- Prev by Date: Re: How to handle large number of users
- Next by Date: Re: Activation limit reached - Told that I cannot increase the limit
- Previous by thread: Re: How to handle large number of users
- Next by thread: Re: How to handle large number of users
- Index(es):
Relevant Pages
|
