Использование статических методов и статических классов в веб-приложениях - Следует ли его избегать?

Question

У нас есть приложение MVC с трафиком около 800 пользователей в день, в последнее время мы наблюдаем, что наш пул приложений прекращается сам по себе. Переходя к журналам, мы обнаружили MemoryOutOfException. Мы не смогли понять, почему это может происходить, поэтому мы просмотрели код. Во время обзора кода мы выяснили, что у нас есть статические классы, статические методы/методы расширения. У нас нет никаких статических переменных, и мы используем блок для размещения DbContext. Возможно ли, что наши статические методы класса/статики являются причиной проблем с памятью?

Как создаются экземпляры внутри статических методов и классов? Собираются ли они GC?

Пожалуйста, предложите, что еще мы можем сделать, чтобы выяснить проблему.

EDIT Извините, что не предоставили никаких кодов. Я хочу понять жизненный цикл статического класса в веб-приложении. Могут ли они создать проблему, если я выполняю сложную операцию, которая занимает память?

Например, если я перевести мою модель домена для просмотра модели в моем статическом классе, как так:

public static class PersonTranslator{ 

    public static PersonVM (this Person p) 
    { 
      return new PersonVM{ 
       Name = p.Name, 
       //etc... 
       //lots of property here 
      } 
    } 


} 

Это хорошая практика, или я должен просто использовать обычные классы, а буду для методов расширения. Может ли код как это создавать проблемы?

Благодаря

EDIT 2: контекста Нашей дб реализуется в базовом классе и весь класс доступа к данным derieve от него. Я думаю (и я могу ошибаться), что здесь что-то не так.

public class DataAccessBase : IDisposable 
    { 

     protected ApplicationDataContext dataContext = null; 

     public DataAccessBase() 
     { 
      dataContext = new ApplicationDataContext(); 
     } 


     public DataAccessBase(ApplicationDataContext dataContext) 
     { 
      if (dataContext == null) 
       dataContext = new ApplicationDataContext(); 

      this.dataContext = dataContext; 
     } 



     ~DataAccessBase() 
     { 

      Dispose(false); 
     } 

     public void Dispose() 
     { 

      Dispose(true); 
      GC.SuppressFinalize(this); 
     } 

     // The bulk of the clean-up code is implemented in Dispose(bool) 
     protected virtual void Dispose(bool disposing) 
     { 
      if (disposing) 
      { 
       // free managed resources 
      } 
      // get rid of unmanaged resources 
      if (dataContext != null) 
      { 

       dataContext.Dispose(); 

      } 


     } 
    } 

Answer 1

Откровенно это может быть что угодно:

• Сколько оперативной памяти на сервере есть?
• Сколько еще сайтов работает на сервере?
• Насколько широко вы используете кеширование?
• Какое хранилище сеансов используется и что вы разрешаете пользователям хранить в сеансе?

В этот момент Id предлагает профилировать приложение с помощью мастера производительности. Как правило, если бы вы сделали это до производства и измерили свое приложение, потому что, как еще вы можете решить, какой размер сервера/виртуальной машины требуется вашему приложению?

распределение памяти .NET дает представление о управлении памятью приложения, поскольку он анализирует каждый объект в памяти от создания сбора мусора. Монитор может работать в двух разных режимах: . Первым и менее эффективным является выборка. Он может также сделать гораздо более глубокий просмотр инструментов, где код добавлен в двоичный файл, чтобы отслеживать работу памяти.

Вы также можете рассмотреть возможность использования счетчиков производительности и perfmon на сервере. По крайней мере, вы должны получать предупреждения до того, как AppPool будет сброшен. I.e. например, при 80% мощности.

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