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

Question

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

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

Тем не менее, это лучшая практика?

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

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

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

Answer 4

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

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

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