rigorMortis,

Не так. Очередь одна, а потоков, обрабатывающих запросы много (по 25 на ядро по умолчанию). Поэтому 5000 запросов не будут выполняться последовательно.

НО
1) Если ты используешь сессию, то запросы с одной сессией выполняются последовательно.
2) Ограничение на число подключений к SQL Server в пуле - 100, поэтому если все твои запросы упираются в базу, то ты начнешь со временем ловить эксепшены что нет свободных подключений/
3) Но еще до того, как ты упрешься в пул, ты упрешься в БД

Shocker.Progandjustas2) Ограничение на число подключений к SQL Server в пуле - 100, поэтому если все твои запросы упираются в базу, то ты начнешь со временем ловить эксепшены что нет свободных подключений/а) число настраивается
б) по идее, запросы встанут в очередь и если только SQL не будет справляться, и очередь начнет расти, получишь эксепшн по таймауту подключения, а не по количеству свободных подключений (если я ничего не путаю)
Не понял какая очередь?

1) если будет задействовано 100 подключений, то при попытке открыть 101-е код будет ждать освобождения, и может отвалится по таймауту пула. К таймауту подключения это не имеет отношения.
2) Если запросы упрутся в SQL, то начнут сыпаться эксепшены из-за request timeout, который по умолчанию 90сек.
3) А вот если увеличить таймаут, то уже можно упереться в лимит подключений, а если увеличить лимит подключений, то можо упереться в лимит очереди запросов в IIS. Но последнее на практике не встречалось.

Shocker.Progandjustas1) Если ты используешь сессию, то запросы с одной сессией выполняются последовательно.кстати, можно пруф? лично я не только не вижу такого эффекта, но и считаю его глупым для реализации.

На самом деле все сложнее, но активная работа с сессией приводит к такому эффекту.
http://msdn.microsoft.com/en-us/library/aa479041.aspx#aspnetsessionstate_topic3 If a page request sets a reader lock, other concurrently processed requests in the same session cannot update the session state but are at least allowed to read. This means that when a session read-only request is being served, awaiting read-only requests are given higher priority than requests needing a full access. If a page request sets a writer lock on the session state, all other pages are blocked, regardless of whether they have to read or write. For example, if two frames attempt to write to Session, one of them has to wait until the other finishes.

Shocker.Proа если спать на потолке, то одеяло будет падатьgandjustas1) Если ты используешь сессию, то запросы с одной сессией выполняются последовательно.короче, ерунды нагородил

А ты по ссылке прочитал? а то я не все что надо скопировал:
http://msdn.microsoft.com/en-us/library/aa479041.aspx#aspnetsessionstate_topic3 What if other pages attempt to concurrently access the session state? In that case, the current request might end up working on inconsistent data, or data that isn't up to date. Just to avoid this, the session state module implements a reader/writer locking mechanism and queues the access to state values. A page that has session-state write access will hold a writer lock on the session until the request terminates.

A page claims write access to the session state by setting the EnableSessionState attribute on the @Page directive to true . (This is the default setting.) A page, though, can also have read-only permissions on the session state, for example, when the EnableSessionState attribute is set to ReadOnly . In this case, the module will hold a reader lock on the session until the request for that page finishes. As a result, concurrent readings can occur.

If a page request sets a reader lock, other concurrently processed requests in the same session cannot update the session state but are at least allowed to read. This means that when a session read-only request is being served, awaiting read-only requests are given higher priority than requests needing a full access. If a page request sets a writer lock on the session state, all other pages are blocked, regardless of whether they have to read or write. For example, if two frames attempt to write to Session, one of them has to wait until the other finishes.


Короче первое же обращение к сессии тормозит все остальные запросы. А если поставить ReadOnly , то запросы на чтение могут идти параллельно, но первая же запись в сессию лочит все остальное.

Обрати внимание какой режим используется по умолчанию.

Shocker.ProgandjustasА ты по ссылке прочитал?Wintellect
September 2003

Видимо, с тех пор что-то изменилось. Мне не удалось воспроизвести описанное.


http://msdn.microsoft.com/en-us/library/vstudio/ms178581(v=vs.100).aspx However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.)

Ты прочитай внимательно. Целостность данных сессии нельзя обеспечить если каждый запрос может туда писать в любое время.

Начиная с .NET4 есть возможность указывать какие ключи сессии твой хендрер будет трогать, уменьшая гранулярность блокировки. Но это только для кастомных хендлеров.

Shocker.Pro,

Приведи код, которым "не получилось"