XML-разбор / запрос производительности вопрос для asp.net

Question

Мне нужно портировать приложение Windows Forms (конфигуратор продукта) меньшего размера на приложение asp.net, которое будет использоваться на веб-сайте крупной компании, спрос должен быть умеренным, поскольку он предназначен для специализированной линейки продуктов.

У меня нет доступа к базе данных, и использование XML является требованием их веб-разработчиков.

В файлах xml хранится примерно 30 различных продуктов с примерно 300 различными возможными конфигурациями, а также связанные вопросы / ответы, которые приводят к рекомендации по продукту. Также некоторые производственные варианты. Приложение доступно на 6 языках.

Как бы вы решили слой доступа к данным, если бы могли называть его так? Я думал о чтении / десериализации xml-файлов в их объекты и сохранении их в кеше asp.net, если их там уже нет, а затем читал из кеша при последующих запросах. Но это означало бы, что все объекты живут в памяти весь день и ночь.

Это даже необходимо, или разумно, с точки зрения производительности? Как я уже говорил, приложение не такое большое, XML-файлы не такие большие. Могу ли я просто создать некоторый класс Repository, который читает файлы xml при каждом запросе объекта (т. Е. «Сведения о продукте» или «Следующий вопрос») и возвращает его таким образом, а также снижает потребление памяти?

Answer 1

Весь подход, кажется, придерживается одного сервера. Сначала подумайте, подходит ли это вам, поскольку вы упомянули «сайт крупной компании», который устанавливает для меня красный флаг. Если вам нужно масштабировать сайт, у вас будет более одного сервера, что не позволяет рассматривать простой локальный файл.

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

Answer 2

Использование кеша и установка соответствующей политики истечения срока действия в соответствии с рекомендациями других - разумный подход. Я бы посоветовал вам взглянуть на использование LINQ to XML в качестве основы для кода доступа к данным, поскольку его намного проще использовать, чем традиционные методы запросов XML. Вы можете найти достойное введение здесь .

Answer 3

Я использую Cache, когда могу. Я кеширую объекты по их первому запросу. Если память имеет какое-либо значение, я устанавливаю политику истечения срока действия. И независимо от того, есть или нет, при нехватке памяти фреймворк все равно будет выгружать кеш.

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

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

Если вы установите зависимость, объекты всегда будут оставаться текущими.

Я за это.