Нещодавно, коли я працював над проєктом, деякі сторінки потребували завантаження великої кількості даних, і іноді я натискав на сторінку, не чекаючи, поки сторінка завантажиться, а потім знову переходив на іншу сторінку
Під час завантаження веб-сторінки буде дуже повільний стан призупиненої анімації, тож давайте сьогодні уважно це вивчатиме.
Спочатку я думав, що така ситуація трапиться на багатьох сайтах або з проблемою зі швидкістю мережі комп'ютера, але виявив, що на цьому сайті такої ситуації немає, іноді я застрягав під час публікації, але натискав на інші сторінки вкладки, щоб швидко завантажитися.
Давайте сьогодні розглянемо це ближче!! Спочатку тестували код:
Код Homeview:
Код контролера:
Для аналізу тестового коду наш контролер має 3 методи: один — головна сторінка, а два інші — тестові методи
Запит Test1 блокується на 5 секунд, а потім повертає дані користувачу
Запити Test2 не блокують і повертатимуть дані безпосередньо користувачу
На нашій головній сторінці є два інтерфейси для запитів Ajax, які є асинхронними, тому проблем із блокуванням немає.
Ми побачимо, що метод Test1 виводить контент лише після того, як Test2 видає контент (Зазвичай сторінка безпосередньо виводить вміст, повернений Test2, а потім чекає 5 секунд, щоб вивести контент, який повернув Test1, оскільки js не блокує）
Потім ми безпосередньо отримуємо доступ до інтерфейсів Test1 і Test2, спочатку отримуємо доступ до Test1, а потім одразу до Test2, і з'ясовуємо, що Test2 має чекати, поки Test1 повернеться, щоб завершити, як показано на рисунку нижче:
Якщо запит на сторінку встановлює блокування читача, інші запити, які обробляються одночасно в тій же сесії, не зможуть оновити стан сесії, але принаймні їх можна прочитати. Якщо сторінка запитує блокування запису для стану сесії, то всі інші сторінки блокуються, незалежно від того, чи хочуть вони читати чи писати контент. Наприклад, якщо два варіанти програм одночасно пишуть контент в одній сесії, одна програма повинна чекати, поки інша програма буде завершена, перш ніж її можна буде написати. У програмуванні AJAX важливо усвідомлювати це відбувається.
Особлива примітка: Лише під час написання сесії Asp.net блокуватиме запит, але якщо ви відвідали сторінку, де записано сесію, наприклад, операцію після входу в систему з нею (сесія заблокована до закінчення дії, звісно, лише якщо SessionID залишається таким самим). Ця проблема виникне.
Інформація на netizen
Поки сайт використовує сесію, кожен запит блокуватиме її протягом усього її життя, тому запити з тим самим sessionid мають чекати на розблокування
Це означає, що якщо на сайті є сторінка з обмеженим часом, він нічого не може зробити, і вам доводиться чекати завантаження сторінки з обмеженим часом.
Ви теж не можете це зробити — кілька одночасно запитів Ajax на одній сторінці, ви не можете це зробити, запити на опитування повідомлень.
Підсумовуючи:Якщо ви проведете сесію на запит, якщо не принесете сесію на запит, вищезазначена ситуація не повториться
Рішення:
Додано функцію SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) до контролера контролера
Примітка:
Обов'язковий означає, що ви запитуєте ексклюзивне блокування на Session (тобто відсутність паралельної обробки запитів на той самий session ID)
ReadOnly означає, що ви запитуєте неексклюзивне блокування на Session (тобто ваш запит все одно має чекати на завершення запитів з ексклюзивним блокуванням, але ви можете обробляти запити з неексклюзивним блокуванням Замки паралельно. Однак це залежить від вас — переконатися, що ваш код не записується в Session. Це не обов'язково контролюється фреймворком)
ReadOnly означає, що сесія, яку ви запитуєте, є неексклюзивним блокуванням (тобто ваш запит все одно має чекати на завершення, запит на ексклюзивне блокування, але ви можете обробляти запит із паралельним неексклюзивним блокуванням). Але важливо переконатися, що ваш код не записує сесії. Це не обов'язково має виконувати фреймворк)
|
Опубліковано 22.09.2017 17:32:59
|
|
|
|
Орендодавець