IIS Big Data Request Setup method

Large concurrent large data volume requests are generally divided into several situations:

1. A large number of users at the same time the system's different functions of the page to find, update operations

2. A large number of users at the same time on the same page of the system, the same table of the large amount of data query operation

3. A large number of users at the same time on the same page of the system, the same table for update operations

For the first case, the general approach is as follows:

One. Processing at the server level

1. Adjusting the IIS 7 application pool queue Length

Changed from the original default of 1000 to 65535.

IIS Manager > ApplicationPools > Advanced Settings

Queue length:65535

2. Adjust the Appconcurrentrequestlimit settings for IIS 7

Changed from the original default of 5000 to 100000.

C:\windows\system32\inetsrv\appcmd.exe Set config/section:serverruntime/appconcurrentrequestlimit:100000

You can view this setting in%systemroot%\system32\inetsrv\config\applicationhost.config:

<appconcurrentrequestlimit= "100000"/>  

3. Adjust the settings of the Processmodel>requestqueuelimit in Machine.config

Changed from the original default of 5000 to 100000.

1. <configuration>
2. <system.web>
3. <processModel requestqueuelimit="100000"/>

4. Modify the registry to adjust the number of simultaneous TCPIP connections supported by IIS 7

Changed from the original default of 5000 to 100000.

REG ADD hklm\system\currentcontrolset\services\http\parameteris/v maxconnections/t reg_dword/d 100000

To complete the above 4 settings, you can basically support 100,000 simultaneous requests. If the traffic reaches more than 100,000, you can consider deploying the program and database to multiple servers by partitioning the function module to share the access pressure. In addition, hardware and software load balancing can be considered. Hardware load balancing can be realized directly through the intelligent switch, the processing ability is strong, and the system is independent, but the price is expensive, the configuration is difficult, can not distinguish between the internship system and the state. So the hardware load balancer is suitable for a large number of devices, large traffic, simple application. Software load balancing is based on system and application, and can better distribute load according to the condition of system and application. Good value for money. PCL load balancer software, LVS software under Linux.

Two. Processing at the database level

When two users access one page at the same time, one user may update a record that another user has deleted. Or, in the time between a user loading a page and clicking the Delete button, another user modifies the contents of the record. So we need to consider the problem of database lock

There are three concurrency control strategies to choose from:

Ø do nothing – if the concurrent user modifies the same record, the result of the last commit (the default behavior)

Ø optimistic concurrency (optimistic Concurrency) -Assuming that concurrency conflicts occur only occasionally, most of the time, it does not occur, so when a conflict occurs, simply informing the user that his changes cannot be saved, Because another user has modified the same record

- pessimistic concurrency (pessimistic Concurrency) – Assuming concurrency conflicts often occur, and users cannot tolerate being told that their changes cannot be saved because of the concurrency of others; then, when a user starts editing a record, locks the record, This prevents other users from editing or deleting the record until he finishes and submits his or her own changes

When multiple users attempt to modify data at the same time, a control mechanism is needed to prevent one user's modifications from adversely affecting the modifications made by other users at the same time. The system dealing with this situation is called "concurrency control".

Types of concurrency control

Typically, there are three common ways to manage concurrency in a database:

• pessimistic concurrency control -The row is unavailable to the user during the time from which the record is fetched until it is updated in the database.
• optimistic concurrency control -The row is not available to other users until the data is actually updated. The update checks the row in the database and determines whether any changes have been made. If you attempt to update a record that has changed, it causes a concurrency violation.
• The last update takes effect -the row is not available to other users until the data is actually updated. However, the update is not compared to the initial record, but only the record is written, which may overwrite changes made by other users since the record was last refreshed.

Pessimistic concurrency

Pessimistic concurrency is typically used for two purposes. First, in some cases, there is a lot of contention for the same record. The cost of placing locks on data is less than the cost of rolling back changes when a concurrency conflict occurs.

Pessimistic concurrency is also useful in situations where it is inappropriate to change records during a transaction. An inventory application is a good example. Suppose a company representative is checking inventory for a potential customer. You typically lock a record until the order is generated, which typically marks the item as "ordered" and removes it from the available inventory. If an order is not generated, the lock is freed so that other users checking the inventory get an accurate count of available inventory.

However, pessimistic concurrency control cannot be performed in a disconnected structure. When the connection is open only enough to read or update the data, you cannot keep the lock for a long time. In addition, applications that retain locks for long periods of time will not be able to scale.

Optimistic concurrency

In optimistic concurrency, locks are set and persisted only when the database is accessed. These locks prevent other users from updating records at the same time. Data is always available in addition to the exact moment of the update. For more information, see optimistic concurrency.

When you try to update, the initial version of the changed row is compared to an existing row in the database. If the two are different, the update fails and a concurrency error is raised. At this point, you will use the business logic you created to reconcile the two lines.

The last update takes effect

When the last update is in effect, the initial data is not checked, but the update is written to the database. It is clear that the following conditions may occur:

• User A obtains a record from the database.
• User B obtains the same record from the database, modifies it, and then writes the updated record back to the database.
• User A modifies the "old" record and writes it back to the database.

In the above scenario, user A never sees changes made by user B. If you plan to use the "Last update effective" method of concurrency control, be sure that this is acceptable.

concurrency control in ADO and Visual Studio. NET

Because data structures are based on disconnected data, both ADO and Visual Studio. NET use optimistic concurrency. Therefore, you need to add business logic to take advantage of optimistic concurrency to solve the problem.

If you choose to use optimistic concurrency, there are two general ways to determine whether a change has occurred: The version method (actual version number or date timestamp), and the Save all Values method.

Version number method

In the version number method, the record to be updated must have a column that contains a date timestamp or version number. When the record is read, the date timestamp or version number is saved on the client. The value is then partially updated.

One way to handle concurrency is to update only if the value in the WHERE clause matches the value on the record. The SQL representation of the method is:

UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2WHERE Datetimestamp = @origDateTimeStamp

Alternatively, you can use the version number to compare:

UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2WHERE RowVersion = @origRowVersionValue

If the date time stamp or version number matches, the record in the data store has not been changed, and the record can be safely updated with the new value in the data set. If they do not match, an error is returned. You can write code that implements this form of concurrency check in Visual Studio. NET. You must also write code to respond to any update conflicts. To ensure that the date timestamp or version number is accurate, you need to set a trigger on the table to update the date timestamp or version number when changes to the row occur.

Save All Values Method

An alternative to using a date timestamp or version number is to get a copy of all the fields when the record is read. The DataSet object in ADO maintains two versions of each modified record: The initial version (the version originally read from the data source) and the modified version (indicating user updates). When you try to write a record back to the data source, the initial value in the data row is compared to the record in the data source. If they match, it indicates that the database record has not been changed since it was read. In this case, the changed values in the dataset are successfully written to the database.

For the four commands of the data adapter (DELETE, INSERT, SELECT, and UPDATE), each command has a collection of parameters. Each command has parameters for the initial value and the current value (or modified value).

Treatment for the second case:

Because it is a large concurrent request, you can also use the first case of the processing method, in addition, because it is a large amount of data retrieval, it is necessary to consider query efficiency issues

1. Indexing tables by query criteria

2. Optimization of query statements

3. You can consider using caching for query data

For the treatment of the third case:

You can also use the first case approach, and because you are updating the same table, consider using the following processing methods:

1. Save the data to the cache first, and then update to the database when the data reaches a certain amount

2. Divide the table by index (table, partition), such as: for a table that stores information about the people of the whole country, this amount of data is very large, if divided into multiple tables by province, in the country's people to save the information to the corresponding table, and then according to the province corresponding and query and update, So the problem of big concurrency and Big data volume will be reduced a lot

This article is forwarded, not verified, and so on.

IIS Big Data Request Setup method