Оптимизация ViewState - PullRequest
Новая
       30

Оптимизация ViewState

8 голосов
/ 04 декабря 2009

Есть ли у кого-нибудь какие-либо идеи или рекомендации, на которые они могли бы указать мне в отношении оптимизации состояния моего приложения ASP .NET? Я не хочу отключать все это вместе, и главная цель его оптимизации - повысить производительность, поэтому я не хочу запускать дорогостоящую функцию для рекурсивного отключения состояния просмотра для определенных элементов управления, потому что эта функция будет замедлять время загрузки страницы, которая победит цель.

Есть идеи?

Ответы [ 3 ]

9 голосов
/ 05 декабря 2009

Вот несколько идей, как можно оптимизировать размер ViewState, передаваемого по проводам ( скопировано из этого ответа ):

  • Отключить ViewState для элементов управления, которые в нем не нуждаются (это наиболее эффективное решение). Например. если вы можете кэшировать некоторые данные на сервере, то вы можете привязывать любые элементы управления, связанные с данными, к каждому запросу, и нет необходимости сохранять все в ViewState.
  • Включить сжатие HTTP на сервере (IIS) . Это уменьшает размер страницы, отправляемой клиенту, включая ViewState.
  • Сжать ViewState . Это имеет дополнительное преимущество перед HTTP-сжатием: оно также уменьшает размер PostBacks (данные отправляются обратно на сервер), поскольку ViewState всегда отправляется обратно на сервер во время PostBack. Для этого есть разные подходы, например, как показано в этом сообщении в блоге .
  • Храните ViewState на сервере вместо отправки его в скрытое поле со страницей. Самый простой способ сделать это - использовать SesionPageStatePersister , но есть и другие решения, которые сохраняют ViewState на диск вместо использования Session ( см. Здесь, например, ).
6 голосов
/ 04 декабря 2009

Я мало что могу вам сказать, кроме "не вкладывайте много в ваш ViewState".

Места, которые я бы искал для оптимизации:

  • Все, что вы добавили в ViewState самостоятельно
  • Большие объемы данных, связанные с элементами управления отображением данных, такими как GridViews, <x>Lists и Repeaters.

GridViews особенно плохо относятся к ViewState; все, что вы связываете с данными, входит в него, поэтому, если вы свяжете особенно большой список, ожидая, что ASP.NET выполнит разбивку на страницы, вы получите огромный ViewState. Единственный способ обойти это - привязывать только одну страницу за раз к GridView, но это означает, что вам придется выполнять нумерацию на стороне данных, которая может быть столь же болезненной, или отключить ViewState для GridView, что означает (возможно) полезные функции, такие как встроенное редактирование, больше не доступны.

Здесь нет серебряной пули.

1 голос
/ 03 апреля 2018

ViewState - это управление состоянием на стороне клиента, которое становится частью ваших пакетов запросов и ответов, и тяжелое состояние просмотра действительно может снизить производительность вашего приложения. Одним из быстрых вариантов оптимизации производительности ViewState является сохранение его на стороне сервера и использование его только тогда, когда это необходимо. Это имеет смысл, поскольку ViewState никогда не используется на стороне браузера клиента и всегда необходим на стороне сервера, когда вы выполняете постбэк. Вы можете использовать систему распределенного кэширования, такую ​​как AppFabric или NCache, для хранения вашего ViewState на стороне сервера, и это должно помочь повысить производительность.

Я лично работал с NCache, у которого нет поставщика изменений кода для кэширования ViewState.

Нажмите здесь, чтобы просмотреть статью о кэшировании состояния ASP.NET View

...