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,144

  • Joined

  • Last visited

 Content Type 

Everything posted by Yoda

  1. Yoda
    Я сделаю тесты. Покажу. Как раз есть набор данных подходящий.
  2. Yoda
    Это плохое решение для нашей ситуации. Во первых у меня уже получилось быстрее ну и сфинкс по сути своего механизма формирует такой же бинарный индекс и реализация внутренней механики очень похожа. Во вторых - самое главное, то, что у меня целиком и полностью весь каталог крутится в индексе сфинкса. Цены, порядок сортировки, бренды, категории, абсолютно вся выборка на страницы каталога идет из того же самого индекса, в котором хранятся и атрибуты. Кроме этого, не нужно мудрить велосипед, и писать сложную логику для преобразования-извлечения данных. Все на sql, единственное стоит сервер 8 версии, там очень пригодилась поддержка JSON. Опять же не нужно было делать какие то прокладки, я прямо из базы новыми операторами mysql забираю готовую json-коллекцию. И в третьих. Я не знаю есть ли возможность в redis распаралелить индексы и делать обработку в несколько потоков. В нашем случае, при использовании сфинкса, можно полноценно использовать из коробки сразу любое количество ядер процессора а также разные части индекса разместить на любом количестве серверов, и в какой-то момент возможно физическое горизонтальное масштабирование станет единственным оставшимся методом оптимизации. Пока что после всех консультаций, если говорить о программных способах дать пинка этому монстру, я вижу два метода. Это хеширование значений атрибутов и отказ от json-коллекций в пользу mva-аттрибутов. Это потребует формированя дополнительных справочников, но сократит размер обрабатываемых данных раз в 50.
  3. 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 решает.
  4. Yoda
    Я немного повангую. Модуль мультивалюта стоит? В каком режиме работает сервер? Apache, или php-fpm ? Судя по симптомам у вас проблема не в заказах.
  5. Yoda
    В данном случае 20 это минимальный набор. Не забывайте товаров же пол ляма. По ним как-то да надо ориентироваться. А оставить пять атрибутов. Это считайте что фильтра и нет.
  6. Yoda
    Не знаю кого) Я приблизительно о такой модели говорил в предудыщем ответе, ну и туда уже до кучи можно и group_id вставить и получим product_id => MVA{hash1, hash2, hash3....} Которые достаточно просто уже сгруппировать и рассчитать.
  7. Yoda
    Условно, именно так оно и преобразовано в json-коллекции, которые сфинкс отлично отрабатывает. Но я знаю общий алгоритм, с помощью которого к id можно нанизать коллекцию хешей и сделать выборку по плоскому набору, в целом это все не проблема. Проблема в нехватке времени на эксперименты. Так что уже после НГ заморочусь с crc32, о результатах доложу. Ну и надо посмотреть какое количество файлов мега укладывает своим кешем на одну стрницу и дальше понимать имеет ли смысл, или нет прогревать верхние значения. Можетбыть оно то и надо. Но если получим на выходе 200 * 200 файлов. То лучше уже без кеша. Либо опять садиться вскрывать мегу и перевешивать ее кеш в Redis.
  8. Yoda
    Вот это здравая мысль. Ioncube ...
  9. Yoda
    1 - не совсем понял 2 - серв тут едва ли загружен на 20% Смысла куда-то уносить фронт и базу никакого. 3 - от Mega фильтра у нас осталась админка и механизм отображения данных. Вся модель выборки собственная. Т.е. мы просто подменили все методы Mega. Но опять же я выше писал, что скорее всего приведение значений атрибутов к виду crc32(txt) и отказ от использования json модели в пользу плоского multi-value атрибута с набором bigint значений, по идее должен дать некий прирост. Вопрос только в том какой. Если это будет 50% от существующих цифр - видимо стоит и заморочиться.
  10. Yoda
    500 мс - это с прогретым родным кешем мегафильтра. При жмакании на любой параметр фильтра. Получается от 500 мс до 1.2 сек время ответа ajax запроса. Я выше уже написал, во первых магазин будет расшиться, и возможно в одну категорию будет налито еще столько же товаров. Во вторых достаточно конкурентная ниша и борьба идет за каждый сантиметр.
  11. 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 запросов - но она решилась, формированием дополнительного индекса для подсказок.
  12. Yoda
    Умрет mysql от таких вот запросов даже на на паре миллионов записей. SELECT COUNT(txt) as qty, attr_data.text as txt FROM main WHERE category_id = 20 GROUP BY txt LIMIT 100; Так что не выход.
  13. Yoda
    Про категории - владелец сам расскажет, если захочет. Скорость работы как сайта так и фильтра. Так как в магазин скорее всего приедет еще столько же товаров, владелец опасается подобных писем счастья:
  14. Yoda
    Очень смешно!! Ага. Я только что сам перечитал, что написал, звучит как жесткий троллинг, однозначно. Но это не троллинг. С момента написания поста, мне пришли в голову еще кое-какие мысли, которые мы когда-то обсуждали с маэстро @SooR, можно ведь подсчет значений атрибутов делать не по текстовому полю, а по crc32 хешу. И теоретически это может дать прирост на какие-то 20-30%. Также в целом можно отказаться от JSON-атрибутов в индексе и преобразовать все в MVA. Но мало ли, может кто сталкивался с подобным и есть еще какие умные мысли, как ускорить подсчет по 10 миллионам значений атрибутов.
  15. Yoda
    Бесценно. Леонардо, я думаю тоже цену на Мона-Лизу сложить не мог. Но реально тупит же, а у меня уже фантазия закончилась что можно еще сделать.
  16. 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. Владелец магазина возмущается, ему не достаточно скорости. Подскажите, что можно сделать для ускорения магазина?
  17. Yoda
    Если честно, да. В двух словах. Под мобайл девайсы нет необходимости брать и резать все кардинально. Достаточно перенастроить размеры изображений, уменьшить количество элементов или сделать ajax загрузку и перенастроить вывод стилей скриптов. Практически все можно сохранить, отказавшись от блым блым.
  18. Yoda
    Друзья, а что Правда отключить половину функционала ради попугаев зау 500 рублей это круто?
  19. Yoda
    Мне тоже интересно. Но с какой целью интересуетесь?
  20. Yoda
    Как говорит Йода, деньги есть? И с какой целью интересуетесь.
  21. Yoda
    Буквально несколько недель назад Hetzner, пытаясь остаться в тренде, запустил cloud сервис аналогичный Amazon W3 или Digital Ocean. Выглядит очень круто - от 3 евро за юнит(2 гига RAM 20 гиг диска), NVME-диски, и даже есть возможность купить не виртуально ядро в виде какого-то потока HyperThread, а полноценный кусок процессора, правда от 23 евро за 2 виртуальных ядра - но это тоже круто. И очень меня эти три евры за выделенный юнит заманили, взял я под новый проект себе на пробу, и был приятно удивлен, что оно работает быстрее подавляющего числа доступных VPS, да и деплой реально в три секунды. Почему же это зло? После некоторых тестов, выяснилось что на самом деле, не все так хорошо как на фасаде. Я взял сервер, для блога на Wordpress, поставил php 7.2, и он просто полетел. Но когда мы взяли 4 ядра 160 гигабайт юнит, при переносе и холодном старте все оказалось быстро (главная страница магазина на 160 000 товаров грузилась за 150мс), но вот через полчаса после переноса DNS и появления нагрузки, вдруг 150мс превратиилсь в 600, при том что нагрузка на процессоре была не больше 20-25% и памяти свободной вагон. После аудита, обнаружилась очень простая и достаточно логичная проблема. В силу использования модуля кеширования (не буду уточнять какого), в кеш набилось за 20 минут порядка 5000 файлов. В целом, если у вас просто кусок сервера, или обычный VPS - это немного и не повлечет таких проблем просадки в скорости. Но у нас же клауд. Соответственно данные на диске динамически реплицируются и синхронизируются на несколько узлов (и это ни фига не быстрый RAID). Вобщем оказалось что такой побочный эффект облачной виртуализации казалось бы напрочь убил возможность использования площадки под большой проект. Но выжигание кривого кеширования, правильная общая оптимизация системы и установка Redis спасла отцов русской демократиии от фиаско. Так что друзья, клауд - это хорошо но не очень, и не каждый модуль кеширования такой полезный как пишут в ваших этих интернетах, и если вы хотите оптимизировать большой магазин, возможно стоит изначально смотреть в сторону аренды выделенного сервера с производительной файловой системой, и использовать техники оптизимиации, отличные от кеширования.
  22. Yoda
    Когда я 20 минут назад получил это сообщение. Я ржал в голос. Потому что очень кучно пошло, и что же это все валится на мою голову? За что ? В общем текст следующий: ПриветПисьмо в почту пришло, по алгоритму сортировки в почтовике как от сайта: Проверили все. Пароли нигде не сменили. Судя по контексту, речь идет о пароле от электронной почты. Ну и это же как так, типа мне с моей же почты письмо отправили, ой ой, ай яй... Помогите, хулюганы девственности лишают. Но у нас в данном случае вааще почта на Яндексе. Вобщем такой вот красивый развод по аналогии с дедушкой-трупом африканским миллиардером, с вероятностью 1 на миллион, что кто-то заплатит. Просто робот через форму обратной связи шлет эту портянку. НЕ ВЕДИТЕСЬ!
  23. Yoda
    Почта это не только настройка магазина Mail-tester.com и Гугл вам а помощь. Ещё раз повторюсь. Магазин посто отправляет почту через какой либо шлюз либо через смтп либо из под mail а как у вас настроены ваши шлюзы, это не проблема магазина, а проблема нестроек окружения.
  24. Yoda
    Ну все. Боюсь! Это гениальная Хуцпа. Марк положил бекдор в модули. Марка поймали за руку. Марк побежал исправлять модуль а теперь распушил перья и пугает юристами. Я сам предоставлю свои данные - если мне хоть кто-то покажет мою цитату где я призывал взламывать и получать от этого выгоду, либо каким то образом как это "занимался недобросовестной конкуренцией". Это что получается. Каждый кто решил положить закладочку в модуль, чтобы получить доступ к данным пользователя, будет в случае, если его поймали на горячем угрожать судом. Ну круто че. Облико морале! Давай в том же духе.
  25. Yoda
    Дабы не превращать тему в срач резюмирую: 1. До администрации форума доведено и явно смоделирована уязвимость в действии - дальнейшие действия администрации на их совести 2. Автор явно признал существование уязвимости, фактом того, что начал латать эту дыру и вносить фикс в свои поделки 3. Я обстоятельно заявляю, что цель создания данной темы и исследования данной уязвимости, является исключительно информирования участников форума о том, что некий Марк, автор модуля, или любой кто имеет доступ к его серверу, может получить доступ к вашим данным. Просто донесения данного факта. 4. Попытки перевести стрелки, рассказывать жалобные басни, о том что бедную курочку обижают, рассказки про сборку PRO репутацию, со стороны выглядит как попытка отвести глаза от собственных подлых действий и сменить акценты. Глупо и мерзко. Но что еще можно ожидать от человека, который подложил всем личный бекдорчик и умолчал об этом? 5. Ну и вопрос ко всем, на каком основании, люди которые покупают модуль должны доверять непонятному постороннему человеку, который не несет никакой ответственности? Также, немножко поймаем автора на двуличии и лжи: Все мы помним тему про уязвимость addist Там по факту был такой же бекдор, только доступный не только автору модуля, но и всем: Напомню вам некоторые цитаты автора: То есть из фронта нельзя а из админки можно? Да еще и с неэкранированным выводом правда? Кошечка моя сладенькая... А вот автор советует что делать с подобными дополнениями: И еще один совет: Черт черт черт... как же так неловко вышло то?

Покупцям

Розробникам

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

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

×
×
  • 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