0

В вашем браузере попытайтесь открыть следующую страницу в двух разных вкладках. нажмите кнопку обновления, чтобы избежать попадания на страницу из кэша браузера:Путаница о потоке рабочего процесса

protected void Page_Load(object sender, EventArgs e) 
    { 
     Thread.Sleep(10000); 
     Response.Write(DateTime.Now.ToString()); 
    } 

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

Теперь создайте следующие страницы, и GlobalCustomClass

GlobalCustomClass

public class GlobalCustomClass 
    { 
     public static string GlobalVariable 
     { 
      get; 
      set; 
     } 
    } 

Default.aspx

protected void Page_Load(object sender, EventArgs e) 
     { 
      GlobalCustomClass.GlobalVariable = "Default page"; 
      Thread.Sleep(10000); 
      Response.Write(DateTime.Now.ToString()); 
      Response.Write("<br />"); 
      Response.Write(GlobalCustomClass.GlobalVariable); 
     } 

Page2.aspx

protected void Page_Load(object sender, EventArgs e) 
     { 
      Response.Write(DateTime.Now.ToString()); 
      Response.Write("<br />"); 
      GlobalCustomClass.GlobalVariable = "Page2"; 
      Response.Write(GlobalCustomClass.GlobalVariable); 

     } 

Обновить страницу по умолчанию и до 10 секунд, обновить Page2 .... Default.aspx - это рендеринг «Страница 2». Да, это не потокобезопасно.

Теперь попробуйте это, откройте следующую страницу в двух вкладках браузера:

protected void Page_Load(object sender, EventArgs e) 
    { 
     Session["x"] = "ABC"; 
     Thread.Sleep(10000); 
     Response.Write(DateTime.Now.ToString()); 
    } 

Теперь, кажется, что первый замок резьбы на объекте сеанса, а другие должны ждать целых 10 секунд !!

Теперь попробуйте первый случай, но поместите Global.ascx в проект ... и скажите, что, первая нить блокирует что-то !!!!!

В реальном приложении, как правило, доступны глобальные переменные состояния, которым необходима безопасность потоков, например сеансов.

Если у вас есть приложение Backend, которое содержит отчет, для которого требуется 30 секунд. и если 60 пользователей откроют этот отчет, тогда пользовательский номер 61 будет ждать полчаса до загрузки страницы в свой браузер! Это типичная головоломка! и я, вероятно, буду уволен :(

1) Каждый пользователь ждет, пока другой не выполнит свой запрос. что должно сделать любую тяжелую страницу проблемой. потому что он может заставить все веб-приложение реагировать. Согласен?

2) Как исправить эту ситуацию?

3) По какой теме я должен исследовать это? Вы знаете хорошую книгу?

Благодаря

+1

Ну, это было бы Питти видеть Вас уволят! Поможем этому человеку. – usr

+1

http://stackoverflow.com/questions/3629709/i-just-discovered-why-all-asp-net-websites-are-slow-and-i-am-trying-to-work-out –

+0

Вы проверяете это на сервере dev или IIS? –

ответ

4

и если 60 пользователей откроют этот отчет, то пользовательский номер 61 будет ждать полчаса до загрузки страницы в свой браузер!

Это не так, потому что замок только за сессию но не глобальный для всех пользователей/сессий.

Поскольку вы использовали один и тот же браузер для вызова двух страниц, вы также использовали один и тот же сеанс ASP.NET (поскольку обе вкладки совместно используют cookie сессии ASP.NET). Если вы используете два разных браузера для имитации двух пользователей, вы увидите, что второй пользователь не будет заблокирован на 20 секунд.

Кроме того, блокировка, конечно, происходит только в том случае, если вы используете состояние сеанса. Если вы хотите создать высокопроизводительное веб-приложение (с большим количеством одновременных пользователей или одновременные/асинхронные запросы), вы должны стараться избегать состояния сеанса как можно больше.

1

Каждый пользователь ждет, пока другой закончит свою просьбу. что должно сделать любую тяжелую страницу проблемой. потому что он может сделать приложение в целом в сети . Согласен?

Я не согласен.Предположим, у вас есть сайт со страницей, для выполнения которой требуется всего 100 мс, но поддерживает 1000 одновременных пользователей. По вашей логике, до завершения последнего запроса потребуется 100 тыс. Мс. Очевидно, что это не так на местах с высоким трафиком.

Я сомневаюсь, что на ViewState есть какой-либо замок (почему бы это быть? Это относится только к экземпляру исполняемой страницы).

Сессия заблокирована в начале жизненного цикла страницы, но только на уровне пользователя, который поддерживает мое утверждение о том, что это не так важно, как вы думаете. Есть также ways around this.

Еще в .NET 1.1 Раньше я использовал тестирование параллелизма с помощью инструментов VS (Application Center Test) и - хотя трафик, безусловно, замедляет работу сайта - тысячи дорогостоящих запросов не создают линейное узкое место, которое вы описываете.

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

2

Давайте посмотрим на документы:

Параллельных запросов и состояния сеанса доступа к ASP.NET состояние сеанса исключительно на сессии, что означает, что если два разных пользователей делают одновременных запросов, доступ к каждому отдельному сессия предоставляется одновременно. Однако, если для одного сеанса выполняется два одновременных запроса (с использованием того же значения SessionID), первый запрос получает эксклюзивный доступ к информации сеанса. Второй запрос выполняется только после завершения первого запроса. (Второй сеанс также может получить доступ, если исключительная блокировка информации освобождается , потому что первый запрос превышает тайм-аут блокировки.) Если значение EnableSessionState в директиве @ Страницы установлено в ReadOnly, запрос информация сеанса только для чтения не приводит к исключительной блокировке данных сеанса. Тем не менее, запросы на чтение только для данных сеанса могут по-прежнему ждать блокировки, установленной запросом чтения-записи для очистки данных сеанса.

От http://msdn.microsoft.com/en-us/library/ms178581.aspx

Таким образом, только тот же пользователь будет вынужден ждать.Блокировка существует, но только для пользователя.

4

Если вам нужно иметь одновременные запросы от того же пользователя вы можете

  1. отключить состояние сеанса или
  2. установить сеанс быть ReadOnly в директиве страницы.

Очевидно, что если состояние сеанса ReadOnly вы не можете писать к ней, но вы все равно можете прочитать его, чтобы выяснить, кем является пользователь, и т.д.

Смежные вопросы