Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Yoda

Users
  
All author extensions
 View Profile  See their activity All author extensions

  • Posts

    3,180

  • Joined

  • Last visited

 Content Type 

Everything posted by Yoda

  1. Yoda
    Вооот. А я говорил. Сейчас будет рекламная акция волшебной мази. Как обычно сплошное введение в заблуждение. Попробую на пальцах открыть фокусы фокуснкиков: 2-3-4к товаров в категории - это не нагрузка, так как все запросы в таблицы товаров сегментированы по id категории и представляют из себя небольшой набор. Тем более у @SooR для версии 2.3 отличный фильтр который отлично переваривает за счет использования сводных таблиц подобные задачи. Это же так просто тыкнуть носом пользователя. С текстом - делай разделение. Почему то все упускают из виду, что каждый дополнительный уровень вложенности катастрофически уменьшает конверсию и ухудшает навигацию. Но как я выше писал, даже 20к товаров в категории никто не показывает, на общем количестве товаров хотя бы овер 100 к, при том что в таких сегментах, как плитка, обои, сантхеника, люстры нормальная навигация - мастхев. Что касается ддоса. Что же это за такой супер-быстрый магазин, оптимизированный, который ложится просто от нажатия f5 в браузере. Как он может держать како-то разумное минимальное количество посетителей. И самое потрясающее передергивание - это рассказывать про то что летает на "шареде". Как известно у beget под базы данных как раз на шареде стоят отдельные оооооочень мощные сервера, судя по всему с огромным количеством памяти. Это позволяет показывать одномоментные очень быстрые результаты. Но шаред он и в африке шаред. И балансировщики ресурсов не спят. Поэтому ни на одном шареде невозможно построить стабильную быструю нагруженную систему. Вобщем друзья мои, не все то золото, что блестит.
  2. Yoda
    На самом деле, судя по всему, вас так же как и многих ввели в заблуждение волшебными способностями чудо-модулей. Вы показываете не реальную работу магазина, а скорость отдачи сервером готовых html-страниц. Если у вас дай бог, когда нибудь появится 20-30 посетитилей онлайн, у вас все ляжет, так как скорость генерации страниц без кеша у вас далеко не фонтан. Сколько ресурсов вы тратите на прогрев, и есть ли у вас возможность оперативно актуализировать каталог - это тоже открытый вопрос, о котором вы умалчиваете. И к этому ко всему у вас только на четвертом уровне появляются где-то там, очень узенько сегментированные товары. Вместо того чтобы дать возможность покупателям иметь нормальную навигацию в общих категориях (плитка, ламинат), вы заставляете его делать несколько лишних действий и теряете до половины посетителей. Ну и с такой мелкой сегментацией, ваш магазин ни чем не отличается от магазина на 3000 товаров.
  3. Yoda
    Круто летает! Научите меня?
  4. Yoda
    Загляну. 1. От 100к товаров по хорошему нужен дедик. Так как ВПСы не справляются ни с io операциями диска, ни с быстрой обработкой mysql-запросов, которая упирается и в io и в скорость ядер. А тут даже не ВПС а опять же облако с непонятной системой виртуализации, с диким оверселингом с HyperThreadingом и так далее. Вобщем это первая печаль. И не говорите мне, что нет трафика. БОТЫ ВЕЗДЕСУЩИ. 2. 2 гб памяти... Ну ок. Скорее всего там стоит 512мб а то и гиг на поток-php (ведь товары откуда то взялись, их парсили, а парсеры прожорливые до памяти). Даже если 512мб, куда то надо еще деть системные ресурсы. В итоге у нас есть ресурсов на 3 паралельных http-потока для клиентов. А от ботов запросов я думаю больше (см п.1) 3. Ладно, допустим, нет проблем с io, есть ресурс процессора, и есть в достатке память. Скорее всего есть большие категории, овер 10к товаров, в которых getProducts и getProductTotal выполняются 2-3-5 сек каждый. А если еще открыта пагинация для индексирования, то на крайних лимитах, на порядок дольше, так как чем больше лимит с сортировкой, тем больше базе приходится сканить данных из таблицы. И у нас уже даже не 3 потока в секунду может отработать система, а 1. Когда на web-сервер приходит очередь запросов, они в нее стали и выели все реусрсы процессора. А еще у нас же есть всякие update в таблицу product. Продолжать могу бесконечно... Хочется конечно поглумиться, и посоветовать поставить один супер-пупер "авторский" "уникальный" кеширующий модуль, либо же обратиться к специалистам оптимизаторам. В какую нить очень честную студию. Но чет я ни у кого из этих специалистов не видел живого магазина с фильтром, который тащит от 100 к товаров в принципе, не то что в одной категории. Так что если вдруг никто не поможет, стучите, полечим беду.
  5. Yoda
    А что там разбираться то... Посмотрите в htaccess, что происходит здесь? RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] По моему ясно же, что весь "хвост" запроса уходит в обработчик php с ключом _route_. Т.е. это внешний набор данных, который пришел "из мира" в котором содержится полная информация о запрашиваемых данных, который потом разбирается на части сео-классом: // Decode URL if (isset($this->request->get['_route_'])) { $parts = explode('/', $this->request->get['_route_']); а "route" - это системный указатель, который определяет какой контроллер системы должен обрабатывать ваш запрос. // Router if (isset($request->get['route'])) { $action = new Action($request->get['route']); } else { $action = new Action('common/home'); } В случае использования ЧПУ, у нас в строке запроса нет явно указанных параметров, какой контоллер должен обрабатывать ту или иную ссылку, а есть только что-то вида site.com/product_url. Для того чтобы движок понял, чему этот product_url соответствует ему надо из _route_ разобрать данные, постучаться в базу получить соответствия, типа product_id = 234234, определить по типу сущности, что это товар, выставить соответствующий системный route = product/poduct и отработать при помощи нужного контроллера ваши данные. Ничего военного и тайного в этом нет. Но все таки я поддержу чукчу, если данный механизм непонятен "как есть", а он достаточно логичен и интуитивен, лучше не лезть, потому что можно нахомутать.
  6. Yoda
    Хм, а чего ж вы самого автора не спросите?
  7. Yoda
    Я сделаю тесты. Покажу. Как раз есть набор данных подходящий.
  8. Yoda
    Это плохое решение для нашей ситуации. Во первых у меня уже получилось быстрее ну и сфинкс по сути своего механизма формирует такой же бинарный индекс и реализация внутренней механики очень похожа. Во вторых - самое главное, то, что у меня целиком и полностью весь каталог крутится в индексе сфинкса. Цены, порядок сортировки, бренды, категории, абсолютно вся выборка на страницы каталога идет из того же самого индекса, в котором хранятся и атрибуты. Кроме этого, не нужно мудрить велосипед, и писать сложную логику для преобразования-извлечения данных. Все на sql, единственное стоит сервер 8 версии, там очень пригодилась поддержка JSON. Опять же не нужно было делать какие то прокладки, я прямо из базы новыми операторами mysql забираю готовую json-коллекцию. И в третьих. Я не знаю есть ли возможность в redis распаралелить индексы и делать обработку в несколько потоков. В нашем случае, при использовании сфинкса, можно полноценно использовать из коробки сразу любое количество ядер процессора а также разные части индекса разместить на любом количестве серверов, и в какой-то момент возможно физическое горизонтальное масштабирование станет единственным оставшимся методом оптимизации. Пока что после всех консультаций, если говорить о программных способах дать пинка этому монстру, я вижу два метода. Это хеширование значений атрибутов и отказ от json-коллекций в пользу mva-аттрибутов. Это потребует формированя дополнительных справочников, но сократит размер обрабатываемых данных раз в 50.
  9. Yoda
    Какие коллизии? На наборе уникальных значений атрибутов в 300 штук, Вы ща серьезно? Опять какой то текст, я не совсем понял к чему. Но уточню суть проблемы. В структуре базы Opencart, самое узкое место - это таблица с атрибутами и поле типа text на значениях. Так как mysql плохо приспособлен для поиска-обработки-группировки по текстовым данным, и это все-таки реляционная база, которая по своей природе предполагает первичную типизацию, реализовать в лоб, какой либо вменяемый механизм невозможно. Есть несколько вариантов решения, но они все требуют денормализации таблиц и влекут за собой проблемы с совместимостью остального функционала. И в любом случае это будет костыль. Даже если использовать выборки match against и full-text индексы, мы все равно упремся в ограничении длины минимального слова в четыре символа, а все остальное заигнорится. Самый трезвый способ использовать для обработки больших текстовых массивов инструменты для этого предназначенные Solr, Elastic, Manticore либо Сфинкс. Так как изначально эти платформы разрабатывались для обработки больших текстовых массивов. Эластик и Солр - мне не нравятся, в силу тех или иных причин - это тема для отдельного поста, мантикора - это сфинкс 2.6 от тех кто убежал от Аксенова. А Sphinx 3.1 показывает прирост по скорости по сравнению с 2.6 и даже 3.0.3 процентов на 30. Очень имеет! MD5-хеш содержит 128 бит, а crc 32 - в четыре раза меньше. Для большого набора, который надо отсортировать в нашем случае, те самые 10M решает.
  10. Yoda
    Я немного повангую. Модуль мультивалюта стоит? В каком режиме работает сервер? Apache, или php-fpm ? Судя по симптомам у вас проблема не в заказах.
  11. Yoda
    В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет.
  12. Yoda
    Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать.
  13. Yoda
    Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis.
  14. Yoda
    Вот это здравая мысль. Ioncube ...
  15. Yoda
    1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться.
  16. Yoda
    500 мс - это с прогретым родным кешем мегафильтра. При жмакании на любой параметр фильтра. Получается от 500 мс до 1.2 сек время ответа ajax запроса. Я выше уже написал, во первых магазин будет расшиться, и возможно в одну категорию будет налито еще столько же товаров. Во вторых достаточно конкурентная ниша и борьба идет за каждый сантиметр.
  17. Yoda
    Третий. Партиций 8 штук добавлено по количеству ядер. Без партиций вот так: MySQL [(none)]> SELECT COUNT(txt).............................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.13 sec) C партициями вот так: MySQL [(none)]> SELECT COUNT(txt) ..........................................................................; +-------+-------------------------------------+ | qty | txt | +-------+-------------------------------------+ | 21440 | txt1 | | 21440 | txt2 | | 21440 | txt3 | | 21440 | txt3 | | 21440 | txt4 | | 21440 | Itxt5 | | 21440 | txt6 | | 21440 | txt7 | | 18480 | txt8 | | 18640 | txt9 | | 18640 | txt10 | | 18640 | txt11 | | 18640 | txt12 | | 18640 | txt13 | | 7640 | txt14 | | 27040 | txt15 | | 7640 | txt16 | | 7640 | txt17 | | 7640 | txt18 | | 7640 | txt19 | | 27040 | txt20 | | 27040 | txt21 | | 35200 | txt22 | | 35200 | txt23 | +-------+-------------------------------------+ 24 rows in set, 1 warning (0.03 sec) Также при использовании партиций возникла проблема с работой QSuggest запросов - но она решилась, формированием дополнительного индекса для подсказок.
  18. Yoda
    Умрет mysql от таких вот запросов даже на на паре миллионов записей. SELECT COUNT(txt) as qty, attr_data.text as txt FROM main WHERE category_id = 20 GROUP BY txt LIMIT 100; Так что не выход.
  19. Yoda
    Про категории - владелец сам расскажет, если захочет. Скорость работы как сайта так и фильтра. Так как в магазин скорее всего приедет еще столько же товаров, владелец опасается подобных писем счастья:
  20. Yoda
    Очень смешно!! Ага. Я только что сам перечитал, что написал, звучит как жесткий троллинг, однозначно. Но это не троллинг. С момента написания поста, мне пришли в голову еще кое-какие мысли, которые мы когда-то обсуждали с маэстро @SooR, можно ведь подсчет значений атрибутов делать не по текстовому полю, а по crc32 хешу. И теоретически это может дать прирост на какие-то 20-30%. Также в целом можно отказаться от JSON-атрибутов в индексе и преобразовать все в MVA. Но мало ли, может кто сталкивался с подобным и есть еще какие умные мысли, как ускорить подсчет по 10 миллионам значений атрибутов.
  21. Yoda
    Бесценно. Леонардо, я думаю тоже цену на Мона-Лизу сложить не мог. Но реально тупит же, а у меня уже фантазия закончилась что можно еще сделать.
  22. Yoda
    Подскажите пожалуйста, есть магазин, 470 000 товаров в одной категории. На выделенном сервере Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz (8 cores) 16ГБ . У товара 20 атрибутов, - суммарно выходит порядка 10М значений атрибутов (которые надо считать на-лету). Весь каталог работает через промежуточную прокладку в виде Sphinx-демона. Файлы индекса сфинкса лежат в RAM диске в оперативной памяти. (выборка товаров в категории, подсчет количества значений атрибутов в фильтре, все все все, что можно крутится на сфинксе) После партицирования индекса на 8 частей и перенастройки конфигурации демона для использования всех 8 ядер процессора, удалось снизить время реакции фильтра с 5 до 1-1.2сек. Среднее время генерации страниц в районе 600мс. При переходе на php7.2 - будет порядка 400-450. Владелец магазина возмущается, ему не достаточно скорости. Подскажите, что можно сделать для ускорения магазина?
  23. Yoda
    Если честно, да. В двух словах. Под мобайл девайсы нет необходимости брать и резать все кардинально. Достаточно перенастроить размеры изображений, уменьшить количество элементов или сделать ajax загрузку и перенастроить вывод стилей скриптов. Практически все можно сохранить, отказавшись от блым блым.
  24. Yoda
    Друзья, а что Правда отключить половину функционала ради попугаев зау 500 рублей это круто?
  25. Yoda
    Мне тоже интересно. Но с какой целью интересуетесь?

Покупцям

Розробникам

Корисна інформація

Останні розширення

×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.

  I accept