Just074 Опубликовано 20 июня, 2017 Жалоба Поделиться Опубликовано 20 июня, 2017 (изменено) Продолжаю борьбу за оптимизацию В общем, проблема следующая, в базе около 60,000 товаров (активных около 30,000), сортировка по умолчаинию и позиции работает отлично, без проблем, а вот сортировка по цене вешает базу тут же, если в категории много товаров - в моем случаи около 10,000 шт Сам запрос выглядит следующим образом: $order = '(SELECT -pv.price FROM __variants pv WHERE (pv.stock IS NULL OR pv.stock>0) AND p.id = pv.product_id AND pv.position=(SELECT MIN(position) FROM __variants WHERE (stock>0 OR stock IS NULL) AND product_id=p.id LIMIT 1) LIMIT 1) DESC'; Вопрос к знатокам, как оптимизировать этот запрос? Как еще можно решить эту проблему? Увеличение мощности сервера? Что-то еще? Читал здесь, что симпла успешно работает с большим объемом товаров и т.д., Она из коробки работает или все же требует оптимизацию для больших объемов данных? Параметры сервера 1 ГБ RAM 30 ГБ SSD 1 CPU Изменено 20 июня, 2017 пользователем Just074 Цитата Ссылка на сообщение Поделиться на другие сайты
Maksclub Опубликовано 20 июня, 2017 Жалоба Поделиться Опубликовано 20 июня, 2017 (изменено) 1Gb оперативки -- маловато как-то у меня 4 стоит для тестовых штук побаловаться всего 600-700 в месяц отдаю > Читал здесь, что симпла успешно работает с большим объемом товаров и т.д., Она из коробки работает или все же требует оптимизацию для больших объемов данных? поверьте -- с Битриксом или другими ЦМС вообще легли бы, Симпла хороша, хотя при больших базах/нагрузках коробочное решение как правило нужно пилить... вообще БД -- первое, что сыпется от нагрузки/количества на всех проектах https://ruhighload.com/post/4+%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D0%B8+%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B+%D1%81+%D0%B2%D1%8B%D1%81%D0%BE%D0%BA%D0%B8%D0%BC%D0%B8+%D0%BD%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0%D0%BC%D0%B8+%D0%B2+MySQL я вообще ноль по оптимизации запросов, потому по самому запросу не подскажу,но нужно кешировать... особенно сортировку http://forum.simplacms.ru/topic/8554-2-%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8C-%D0%BA%D0%B5%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-mysql-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%BE%D0%B2/ memcahe подключили? он хранит уже результат запросов, то есть мускул не будет напрягатьсяhttps://habrahabr.ru/post/61736/кстати -- для мемкеша нужна оперативка, он в ней держит кеш, так что по0любому величить нужно кеширвоание на самом Мускуле?https://habrahabr.ru/post/41166/ Изменено 21 июня, 2017 пользователем Maksclub Цитата Ссылка на сообщение Поделиться на другие сайты
ЯкЦинДрак Опубликовано 21 июня, 2017 Жалоба Поделиться Опубликовано 21 июня, 2017 Продолжаю борьбу за оптимизацию В общем, проблема следующая, в базе около 60,000 товаров (активных около 30,000), сортировка по умолчаинию и позиции работает отлично, без проблем, а вот сортировка по цене вешает базу тут же, если в категории много товаров - в моем случаи около 10,000 шт Сам запрос выглядит следующим образом: $order = '(SELECT -pv.price FROM __variants pv WHERE (pv.stock IS NULL OR pv.stock>0) AND p.id = pv.product_id AND pv.position=(SELECT MIN(position) FROM __variants WHERE (stock>0 OR stock IS NULL) AND product_id=p.id LIMIT 1) LIMIT 1) DESC'; Вопрос к знатокам, как оптимизировать этот запрос? Как еще можно решить эту проблему? Увеличение мощности сервера? Что-то еще? Читал здесь, что симпла успешно работает с большим объемом товаров и т.д., Она из коробки работает или все же требует оптимизацию для больших объемов данных? Параметры сервера 1 ГБ RAM 30 ГБ SSD 1 CPU Во-первых, указанным образом выглядит не запрос, а лишь его фрагмент, связанный с сортировкой.Во-вторых, желательно показать запрос ПОЛНОСТЬЮ, и знать бы, сколько записей он возвращает. Скорее всего, дело в их количестве.А оптимизировать - например, изменением структуры базы, чтобы фрагмент сортировки был проще. Сейчас он просто жуткий - с подзапросом второго уровня Пробуйте простой (и не совсем правильный) способ, заменить тот фрагмент на $order = '(SELECT -pv.price FROM __variants pv WHERE (pv.stock IS NULL OR pv.stock>0) AND p.id = pv.product_id LIMIT 1) DESC'; Должно сократить время работы. Если не даст удовлетворительного результата, то применять более тонкие методы. Предлагавшееся выше кеширование вряд ли поможет. Потому что разных запросов таких - миллиарды, никакой хостинг кеширование таких объемов не выдержит (есть запросы по фильтру, и есть еще поиск). Большинство кеша будет просто занимать место без пользы. А каждый новый запрос (с новой поисковой фразой, например) будет вешать базу... Цитата Ссылка на сообщение Поделиться на другие сайты
Just074 Опубликовано 21 июня, 2017 Автор Жалоба Поделиться Опубликовано 21 июня, 2017 (изменено) Коллеги, доброго дня, спасибо за комментарии, выявил для себя много полезного! Начну сразу с результатов: проблему удалось нейтрализовать! Решение оказалось не таким уж и сложным, чуть чуть настроил MySQL, включил штатное кеширование (query_cache_type=1, query_cache_size=128M), оптимзировал таблицы и все! И сервер тоже апгрейдил, теперь конфигурация 2 ГБ RAM 40 ГБ SSD 2 CPU В базе 60,000 товаров, в самой большой категории ~10,000 товаров, сортировка летает, даже намека на лаги нет. Изменено 21 июня, 2017 пользователем Just074 Цитата Ссылка на сообщение Поделиться на другие сайты
Maksclub Опубликовано 21 июня, 2017 Жалоба Поделиться Опубликовано 21 июня, 2017 (изменено) В базе 60,000 товаров, в самой большой категории ~10,000 товаров, сортировка летает, даже намека на лаги нет. Ну и отлично Но проблема может вылезти, например при росте посещений Изменено 21 июня, 2017 пользователем Maksclub Цитата Ссылка на сообщение Поделиться на другие сайты
Just074 Опубликовано 21 июня, 2017 Автор Жалоба Поделиться Опубликовано 21 июня, 2017 Ну и отлично Еще пересесть на nginx и php7 и вообще круть... хотя не факт, но скорее всего еще и бекенд быстрее будет работать Nginx стоит, отдает статику, php7 не хочу ставить пока, хотя и заметно шустрее чем нынешний 5.4, но мне кажется многое придется переписывать, поэтому не готов пока)) Цитата Ссылка на сообщение Поделиться на другие сайты
Рекомендуемые сообщения
Присоединяйтесь к обсуждению
Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.