Мы работаем над сайтом корзины покупок с более чем 1 лакх продуктами, созданными на основе популярного приложения для электронной коммерции - NopCommerce версии 2.3 (просто для того, чтобы познакомить вас с NopCommerce - это один из лучших и популярных приложений с открытым исходным кодом.коммерческое приложение, построенное на основе ASP.net версии 4 и MVC3.).Сайт был опубликован с двумя языками и единой валютой.
Имея около 80 категорий и 30-40 тыс. Продуктов, он работает довольно хорошо.Я имею в виду не очень плохо.Но это тоже не было хорошо.Как только было добавлено больше продуктов, проблемы с производительностью начинались с таких симптомов, как длительное время отклика (более 40-50 секунд для загрузки) и высокая загрузка ЦП (использование 90-100%) всего с 10-20 пользователями.
Сервер является четырехъядерным процессором Xeon с 16 ГБ ОЗУ - Windows Server 2008 R2 и отлично работает с еще одним веб-сайтом электронной коммерции с 50 тыс. Продуктов на заказном коде разработки, который занимает всего 4–8% ЦП.
Мы использовали кэш для хранения избранных товаров домашней страницы и меню категорий в памяти, чтобы избежать вызовов БД.Он улучшил только домашнюю страницу.
Позже для исправления проблемы мы профилировали и обнаружили, что это был список в каталоге, который вызывал большую задержку при получении данных из базы данных, что точно нормализовалось.Похоже, что SQL-сервер занимает 80-90% процессорного времени, а w3wp - 30-40% процессорного времени, что постоянно приводит к 100% -ному процессору, и на сайте мало посетителей.Мы посоветовались с несколькими экспертами, они предложили нам хранить ненормализованные данные на диске в двоичном формате, чтобы обойти дорогостоящие соединения с базой данных.Мы провели некоторое исследование и использовали Protobuff для хранения данных нормализованных сериализованных объектов на диске, где хранятся только те поля, которые необходимы для каталога - страница со списком продуктов.Но из-за поддержки некоторых функциональных возможностей спецификации мы создали 3 двоичных файла.Один для объекта продукта, другой для объекта спецификации категории.Эти два файла для каждой категории.И еще один файл для отображения продукта и спецификации - занимает почти 5 МБ.Когда приходят запросы, он читает из сериализованного двоичного файла и возвращает данные объекту.Он считывает файл сопоставления только тогда, когда кто-то фильтрует продукт на основе спецификации.
Так что теперь, когда приходит запрос на страницу со списком продуктов, он проверяет, существует ли двоичный файл, созданный для этой категории, если он не 'Он генерирует хранимую процедуру и сохраняет объект в двоичный файл для последующего использования.Если файл существует, он напрямую читает его из двоичного файла.Благодаря этому мы избежали 90% вызовов БД при загрузке этой страницы.С несколькими пользователями (приложение 30-40) это работает как шарм.И мы можем сократить время отклика до 700-800 мс для каждой загрузки страницы.Это большое улучшение, если мы посмотрим на время загрузки, но процессор все еще находится на более высокой стороне.Разница в том, что теперь w3wp использует 60-70% ЦП при 20-30 посетителях, а sql вряд ли использует 5-8%.
Но с увеличением числа пользователей примерно до 100-120 серверы начинают зависать, а w3wpиспользуя более 100% постоянно.Запросы больше не обрабатываются в секундах, вместо этого загрузка занимает более 20-25 секунд.И тогда большинство запросов никогда не обслуживается.Мы заметили это, когда на сайт приходит несколько запросов.
Мы не являемся экспертами в сериализации и двоичном форматировании.Но мы считаем, что высокая загрузка ЦП обусловлена операцией чтения файла или операцией десериализации, выполняемой при каждой загрузке страницы каталога.
Сейчас мы рассмотрим вероятное решение для решения проблемы высокой загрузки ЦП.использование.В чем может быть проблема, и где мы должны искать, чтобы это исправить.Как вы думаете, это является причиной операции чтения файла или десериализации?Должны ли мы хранить денормализованный объект в БД?Какие у нас есть альтернативы для решения этой проблемы?
В ожидании вашего экспертного заключения по этому поводу.
Заранее спасибо.