Лучшая практика - загрузите много вещей в application_start?

Question

У меня есть интернет-магазин с большим количеством продуктов и другого контента. В настоящее время я загружаю весь контент в глобальный список на Application_Start, который занимает примерно 15-25 секунд.

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

Однако, это лучшая практика?

В настоящее время у меня есть веб-отель, который не является сервером VPS/Dedicated, поэтому время от времени он перерабатывает приложение, что дает случайным посетителям время загрузки до 15-25 секунд (только чтобы стать большим числом с большим количеством содержание). Это, конечно, совершенно неприемлемо, но я думаю, что это было бы решено с помощью VPS.

Каков нормальный способ сделать это? Я думаю, что интернет-магазин, подобный Amazon, вероятно, не загружает все свои продукты в огромный список :-D

Любые мысли и идеи будут высоко оценены.

Answer 1

Похоже, что вы ответили на ваш вопрос по поводу ваш случай «Это, конечно, совершенно неприемлемо».

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

Большие сайты часто используют распределенное кэширование, такое как MemcaheD.

Answer 2

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

Answer 3

Разделение ответственности поможет вам масштабировать в будущем.

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

Если вы разделяете бремя каждого запроса страницы с помощью SQL Server, вы открываете приложение, чтобы оно могло масштабироваться по мере необходимости. Со временем вы можете решить добавить еще несколько веб-серверов, кластер SQL Server или полностью переключиться на новую базу данных базы данных. Однако, если все бремя находится на пуле приложений, то вы решительно ограничиваете себя.

Answer 4

Прежде всего, 15-20 секунд для загрузки данных слишком много времени, так что я подозреваю, что это случаи

• Это время для компиляции, а не загрузок данных
• данных слишком много и вы полный память
• метод, который используется для чтения данных очень медленно
• хранение данных слишком медленно, или структура на текстовый файл и чтение из него медленно

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

1. Если у вас много бассейнов, вы читаете одни и те же данные на всех пулах, и вы тратите память без причины.
2. Данные, которые вы кешируете, вы не можете их изменить - это только для чтения
3. Даже если вы кешируете некоторые данные, вам необходимо отобразить страницу, и там, где вам действительно нужно сделать кеш, в финале рендеринг, а не по данным.

Что и как кешировать.

• Кэш окончательной страницы рендеринга.
• Мы также устанавливаем кеш для страницы и других элементов для клиента.
• Мы читаем и записываем данные из базы данных по мере их поступления, и мы оставили базу данных в кеше, он знает лучше.
• Если мы кэшируем данные, то они должны быть небольшим количеством, которое необходимо использовать для длинного цикла, и мы часто вызываем вызов базы данных.

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

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

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