yop3bik Опубліковано: 15 серпня 2017 Share Опубліковано: 15 серпня 2017 Необходима реализация подгрузки описания и фото товаров по API со стороннего источника. Документация по api http://rlsaurora10.azurewebsites.net Все необходимы доступы предоставлю. Надіслати Поділитися на інших сайтах More sharing options...
MaDMaxX111 Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 Готов реализовать Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 @designer выборка будет производится по штрихкоду http://rlsaurora10.azurewebsites.net/api/inventory_brief?ean=4607009582412 У каждого товара есть штрих код Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 17 серпня 2017 Автор Share Опубліковано: 17 серпня 2017 В 16.08.2017 в 09:41, Designer сказал: @yop3bik А есть демо доступы к API? По идее, нужно не подгружать описание и фото, а реализовать в таком формате: Нет описания - обращаемся к API и заполняем описание в БД у этого товара Нет фото - загружаем фото на сервер и закремляем его к указанному товару Если делать постоянное обращение к API, то это будет тормозить Демо доступы есть. База - более 20 тыс позиций. Мне кажется при полном заполнении базы будет тормозить. Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 17 серпня 2017 Автор Share Опубліковано: 17 серпня 2017 Возможно ли решение, при котором все данные будут запрашиваться на стороннем сервере? Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 17 серпня 2017 Автор Share Опубліковано: 17 серпня 2017 40 минут назад, Designer сказал: @yop3bik что тормозить? 20 000 позиций, это не много. Возможно, только смысл? Данные и так на стороннем сервере у API поставщика не совсем понял ответа. Мне кажется, что перераспределение - правильный подход, чем хранить все у себя. Надіслати Поділитися на інших сайтах More sharing options... kvr66 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 4 часа назад, yop3bik сказал: Возможно ли решение, при котором все данные будут запрашиваться на стороннем сервере? возможно, только дорого, не думаю что вы готовы платить за такое решение ) Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 В 16.08.2017 в 06:15, MaDMaxX111 сказал: Готов реализовать не рекомендую связываться с человеком с рейтингом 1 в реализации сложной задачи! 12 часов назад, yop3bik сказал: Демо доступы есть. База - более 20 тыс позиций. Мне кажется при полном заполнении базы будет тормозить. При полном заполнении не тормозит и миллион! 5 часов назад, Designer сказал: @yop3bik Перераспределение чего? Вообще, можно потратить пару часов времени и спарсить в БД все ночью один раз. При этом нагрузка на сервер будет нулевая. Я не знаю, что Вы хотите перераспределять с мизерным количеством товаров в 20 000. Это не то количество, чтобы загружать на второй сервер, потом дергать с него на основной. Время затраты обработки данных будет даже дольше со второго сервера, чем получать данные от поставщика. Не создавайте себе головную боль с дурными мыслями. Если сайт тормозит от 20 000 позиций, вложите средства в оптимизацию как клиентской части, так и серверной А вы спросите, прежде чем такое пишите! от 20 000 товаров - это не сайт - это сложный проект! Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 21 минуту назад, Designer сказал: Первым делом я и сделал, что задал вопрос! Вы считаете, что от кол-во товаров на сайте, можно проект назвать сложным? Я абсолютно в этом уверен. Так как после 20 000 товаров. Возникают технологические сложности не связанные с движком, а связанные с технологическими особенностями PHP и MYSQL. Из которых, чтобы вам понятно было, конкретно явные - это : а) быстрый контексный поиск, который слабо реализуем на php+mysql, даже через match against б) резервирование нагрузки системы под всплески посещений ботов в) если мы говорим о конкретном случае. И регулярном парсинге остатков, наличия, цен. Необходимы механизмы обхода блокирования таблиц в базе данных при постоянном обновлении данных и перестроении индексов. мог бы дальше продолжить, но мне кажется этого достаточно. приведите аргументы, если не прав хотя бы по этим пунктам. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 12 минут назад, Designer сказал: @Yoda 1. С поиском понятно, тут сложно не согласиться. 2. Чтобы снизить нагрузку от ботов, можно задать им Crawl-delay и на серверном уровне, запрещать индексацию сайта залетным ботам. 2.1 Query Cache 2.2 Memcache 3. Регулярный парсинг в 4 утра, когда посещение сайта снижается к нулевой отметке, можно не беспокоиться об блокировке и обновлении данных. После парсинга, можно так же можно выполнить оптимизацию и анализ таблиц для перестроении индексов. Но создав сайт и загрузив туда 20к + товаров, я не могу называть это сложным проектом. Помимо Выше указанных Вами пунктов, нужно смотреть и в корень проекта. Так как нагрузить сайт можно и 100 товарами, если у части кода будет утечка памяти, кривой запрос, отсутствие индексов и т.д. 2 - нет нет и еще раз нет. Во первых это возможно только для Яндекса, гугл в упор не видит эту директиву. Во вторых. Снижать частоту посещения ботов - это равнозначно грызть себе руку. 2.1 - так же в корне неправильно, читаем мануал к mysql. Она отлично сама кеширует запросы, но в формает постоянно обновляемых данных и данных о просмотре товаров, данная техника неактуальна от слова совсем. 2.2 - в нынешних реалиях от memcache есть прирост только при обращении к повторяющимся данным, как-то например в сео про с кешем от фрилансера. Но на 50 к товаров в сео про кеш вреден больше чем полезен. А в остальных ситуациях, когда происходит одинарное чтение данных из кеша, прирост от memcache по сравнению с файловым кешем ssd - минимален. А при небольшом тюнинге библиотеки файлового кеша и вовсе нивелируется в рамках статистической погрешности. 3. У ботов нет дня и ночи, они не спят. Получить от яндекса пессимизацию с его новым оценочным алгоритмом, который требует ttfb < 3 сек - можно автоматически при такой технике. Топик стартер совершенно верно формулировал мысль но не довел ее до конца. Если мы говорим о идеальном парсинге. Нам обязательно нужен промежуточный контейнер. В виде какого-то хранилища. Либо мы можем использовать технику перевода front-end выдачи каталога на индекс sphinx целиком, а не только поиска, и парсинга товара в базу данных с периодической переиндексацией сфинкса. Для регулярного real-time обновления данных о товарах opencart в коробке и существующие парсеры к сожалению, не сильно подходят. Я обсуждал концепции порционного обновления боевых таблиц как с @usergio так и с @MaxD несколько лет назад. Дядя Сережа покивал головой, сказал круто и забыл. А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает. Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 10 минут назад, Yoda сказал: А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает. Немного оффтоп для этой темы, но видимо надо отозваться. Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр. А без цифр получается, что твои фантазии против моих. Мои фантазии такие: Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все). В худшем случае паралельные запросы задержатся на эти 10 мс. Абсолютно не критично, если один новый товар вставляется раз в несколько секунд. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 13 минут назад, MaxD сказал: Немного оффтоп для этой темы, но видимо надо отозваться. Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр. А без цифр получается, что твои фантазии против моих. Мои фантазии такие: Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все). В худшем случае паралельные запросы задержатся на эти 10 мс. Абсолютно не критично, если один новый товар вставляется раз в несколько секунд. Какие цифры... О чем вы сейчас. Я говорю о базовых принципах работы msysql. Когда мы пишем в таблицу, если она в Myisam - она лочится на чтение. В принципе... Если лочится таблица oc_product и у нас есть хоть какой-то трафик даже от ботов, этот лок вызывает лавинообразный поток наслоения процессов apache, потому что php стоит и ждет. Поэтому если происходит нон-стоп парсинг, то у нас постоянно заперта то одна то вторая то третья таблица, а таблиц с товарами допустим пусть будет 10... Соответсвенно 10 мс превращаются в 100. А в это время нас все время ждет очередь запросов на чтение... В итоге нагинается целиком весь проект. Что мешает сделать промежуточные клоны таблиц p2c p2s ps pd и так далее. Загонять в них 500-1000 наборов данных и одним большим запросом мерджить это с боевыми таблицами - я не знаю. Это достаточно просто. Но видимо все очень уверены в своем скиле. Кроме этого. При изменении данных в любой таблице, сбрасывается внутренний кеш mysql, который мог бы работать на тех запросах которые не используют NOW(). К сожалению, вам лень читать мануал. Давайте все таки начнем с того, что вы внимательно изучите принцип работы MySql с таблицами MYISAM, изучите механизм блокировки и работы кеша. А потом мы начнем говорить дальше.... 13 минут назад, Designer сказал: 2.1. о каких частых обновлениях данных, раз в сутки? 2.2. кешировние на то и нужно, чтобы кешировать повторяющие данные. Если сайт не посещаем, толку от кеширования вообще нет. Встроенный файловое кеширование ос даст только прирост нагрузки. Тюнинг и SEO pro это отдельная тема. Разработка парсера + свинкс для клиентов будет дорогим удовольствием. В 99% клиенты ужасаются от стоимости разработки парсера. От этого и подходы к разработке соответствующие. По поводу промежуточного контейнера, с него придется тоже обновлять данные в реал-тайм иначе, возвращаемся к началу всей проблемы. 2.1 ЕЩЕ РАЗ!!! КЕШИРОВАТЬ нативно ЗАПРОСЫ Mysql средствами PHP, это как мыть голову шампунем, одевая резиновую шапочку. Можно - но сродни идиотизму. 2.2 Если сайт непосещаем. Это не значит что он не будет посещаем в будущем. Если мы говорим о проекте даже на 20 000 товаров. То раз в три дня его должны обойти два бота гугл и яндекс. А это 40 000 посещений за 72 часа... А это 555 заходов в час и 9 заходов в минуту. Это при идеальном роботсе и настроенном сео, а так умножайте на 4, и получаем 36 pageview в час. А кроме этого есть другие боты. А кроме этого есть какие-никакие посетители и так далее... Любой проект, должен быть живым "на холодную". Кеширование - это приятный бонус для повышенной нагрузки на повторяющийся контент. Разработка парсера не так страшна, если у вас есть готовая бизнес-логика обновления товаров и вам достаточно поменять драйвер API поставщика контента. По сути ничем не будет отличаться от смены классов используемого хранилища для кеша в в 2.3 opencart. Обновлять реал-тайм данные в контейнере - да легко. Вот тут подробнее: http://sphinxsearch.com/docs/current/rt-overview.html Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 3 минуты назад, Yoda сказал: К сожалению, вам лень читать мануал. Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 10 минут назад, MaxD сказал: Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Да при чем тут пафос. Таблица на 200-300 000 записей умирает при частых операциях чтения не только из-за локов а из-за перестроения индексов. И о чем мы ща спорим? А мы спорим, о том что долбить в нее по одной записи абослютно неэффективно, когда можно пихнуть 1000 записей за один запрос, и закрыть в принципе все проблемы с локами. Что касается ботов и задержки. Ну не ходят они равномерно и по графику. У пассивной нагрузки всегда есть рапределенные стохастические всплески, которые при постоянном обновлении легко валят голые проекты. На InnoDB мешает перейти full-text индексы, который поддерживает только mariadb10, которая недоступна в большинстве хостинг-платформ. И опять же я не понимаю в чем суть спора. Я долблю про технологию партицированного парсинга уже четвертый год. Какая сложность это реализовать ? У меня есть пример магазина, в котором 500 000 товаров. В нем весь каталог товаров подвешен в Sphinx, при этом база постоянно обновляется - ни единого разрыва. Разнесенные хранилища в разные контейнеры - это абсолютно минус головная боль... Да вы сейчас скажете, что сфинкс надо еще поставить настроить. Ок не вопрос. Кто мешает вам сделать два контейнера в рамках Mysql ? Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 4 минуты назад, Yoda сказал: из-за перестроения индексов Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 20 минут назад, MaxD сказал: Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Мне очень давно не попадались магазины с parseMX. Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. А цифры и выкладки - это не ко мне в данной ситуации. Потому что такими темпами, придется делать собственный парсер, а мне это не интересно. Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 36 минут назад, Yoda сказал: Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. Может у него там с архитектурой что-то не то, тем более его модуль чаще используют для импорта прайсов из файла, там естественно темпы вставки намного выше, чем при обходе внешних сайтов. Из того, что я знаю - ни с ParseMX, ни с LiveImport (который тоже импортирует прайсы) магазины не ложились ни у кого ни на каких хостингах (кроме случаев, когда товаров становилось больше, чем магазин мог тянуть). В любом случае, буду наблюдать за этим ньюансом у клиентов. И да, делать свой парсер - удовольствие такое себе ) Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 21 серпня 2017 Автор Share Опубліковано: 21 серпня 2017 (змінено) О сколько я всего пропустил. Резюмируя: 1. У меня большое сомнение, что если я спарсю весь контент по аптечным товарам себе в базу, сайт не начнет тормозить 2. У поставщика API под это дело выделенная площадка, и я так понимаю, что их основной сайт справочника не хранит данные у себя, а берез их через этот же API. Речь идет о справочнике РЛС. Какое же решение вопроса верное? Хранить все у себя и настраивать свой софт и железо, либо дергать по запросу у поставщика API? Змінено 21 серпня 2017 користувачем yop3bik Надіслати Поділитися на інших сайтах More sharing options... MaDMaxX111 Опубліковано: 21 серпня 2017 Share Опубліковано: 21 серпня 2017 Мое мнение вносить справочник в свою систему, вот что написано на РЛС - " РЛС® Аврора – система публикации данных о лекарствах для интеграции в медицинские информационные системы (МИС), медицинские системы помощи принятия решений, товарные учетные системы дистрибьютеров, аптечных сетей и аптек. Эта система предназначена для разработчиков. Т.е. разработчики должны научиться встраивать публикуемые данные в свои информационные системы, реализовать процедуры периодического обновления." Если сайт будет сильно тормозить то уже применят определенные методы оптимизации нагрузки Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Послуги Програмування, створення модулів, зміна функціональності Нужна реализация подгрузки описания и фото товара по API Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення UpStore – адаптивний універсальний шаблон + Швидкий Старт Автор: 29aleksey SP WAREZ CHECKER - перевірка на піратські та шкідливі модулі (with warez.rip) Автор: spectre Деталі замовлення на сторінці подяки Автор: kJlukOo Вивантаження замовлень у XML Автор: DobriyEvgeniy Octostore - адаптивний, універтальний та продуманий шаблон для Opencart/OcStore Автор: MonstroDesign × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
yop3bik Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 @designer выборка будет производится по штрихкоду http://rlsaurora10.azurewebsites.net/api/inventory_brief?ean=4607009582412 У каждого товара есть штрих код Надіслати Поділитися на інших сайтах More sharing options...
yop3bik Опубліковано: 17 серпня 2017 Автор Share Опубліковано: 17 серпня 2017 В 16.08.2017 в 09:41, Designer сказал: @yop3bik А есть демо доступы к API? По идее, нужно не подгружать описание и фото, а реализовать в таком формате: Нет описания - обращаемся к API и заполняем описание в БД у этого товара Нет фото - загружаем фото на сервер и закремляем его к указанному товару Если делать постоянное обращение к API, то это будет тормозить Демо доступы есть. База - более 20 тыс позиций. Мне кажется при полном заполнении базы будет тормозить. Надіслати Поділитися на інших сайтах More sharing options...
yop3bik Опубліковано: 17 серпня 2017 Автор Share Опубліковано: 17 серпня 2017 Возможно ли решение, при котором все данные будут запрашиваться на стороннем сервере? Надіслати Поділитися на інших сайтах More sharing options...
yop3bik Опубліковано: 17 серпня 2017 Автор Share Опубліковано: 17 серпня 2017 40 минут назад, Designer сказал: @yop3bik что тормозить? 20 000 позиций, это не много. Возможно, только смысл? Данные и так на стороннем сервере у API поставщика не совсем понял ответа. Мне кажется, что перераспределение - правильный подход, чем хранить все у себя. Надіслати Поділитися на інших сайтах More sharing options...
kvr66 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 4 часа назад, yop3bik сказал: Возможно ли решение, при котором все данные будут запрашиваться на стороннем сервере? возможно, только дорого, не думаю что вы готовы платить за такое решение ) Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 В 16.08.2017 в 06:15, MaDMaxX111 сказал: Готов реализовать не рекомендую связываться с человеком с рейтингом 1 в реализации сложной задачи! 12 часов назад, yop3bik сказал: Демо доступы есть. База - более 20 тыс позиций. Мне кажется при полном заполнении базы будет тормозить. При полном заполнении не тормозит и миллион! 5 часов назад, Designer сказал: @yop3bik Перераспределение чего? Вообще, можно потратить пару часов времени и спарсить в БД все ночью один раз. При этом нагрузка на сервер будет нулевая. Я не знаю, что Вы хотите перераспределять с мизерным количеством товаров в 20 000. Это не то количество, чтобы загружать на второй сервер, потом дергать с него на основной. Время затраты обработки данных будет даже дольше со второго сервера, чем получать данные от поставщика. Не создавайте себе головную боль с дурными мыслями. Если сайт тормозит от 20 000 позиций, вложите средства в оптимизацию как клиентской части, так и серверной А вы спросите, прежде чем такое пишите! от 20 000 товаров - это не сайт - это сложный проект! Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 21 минуту назад, Designer сказал: Первым делом я и сделал, что задал вопрос! Вы считаете, что от кол-во товаров на сайте, можно проект назвать сложным? Я абсолютно в этом уверен. Так как после 20 000 товаров. Возникают технологические сложности не связанные с движком, а связанные с технологическими особенностями PHP и MYSQL. Из которых, чтобы вам понятно было, конкретно явные - это : а) быстрый контексный поиск, который слабо реализуем на php+mysql, даже через match against б) резервирование нагрузки системы под всплески посещений ботов в) если мы говорим о конкретном случае. И регулярном парсинге остатков, наличия, цен. Необходимы механизмы обхода блокирования таблиц в базе данных при постоянном обновлении данных и перестроении индексов. мог бы дальше продолжить, но мне кажется этого достаточно. приведите аргументы, если не прав хотя бы по этим пунктам. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 12 минут назад, Designer сказал: @Yoda 1. С поиском понятно, тут сложно не согласиться. 2. Чтобы снизить нагрузку от ботов, можно задать им Crawl-delay и на серверном уровне, запрещать индексацию сайта залетным ботам. 2.1 Query Cache 2.2 Memcache 3. Регулярный парсинг в 4 утра, когда посещение сайта снижается к нулевой отметке, можно не беспокоиться об блокировке и обновлении данных. После парсинга, можно так же можно выполнить оптимизацию и анализ таблиц для перестроении индексов. Но создав сайт и загрузив туда 20к + товаров, я не могу называть это сложным проектом. Помимо Выше указанных Вами пунктов, нужно смотреть и в корень проекта. Так как нагрузить сайт можно и 100 товарами, если у части кода будет утечка памяти, кривой запрос, отсутствие индексов и т.д. 2 - нет нет и еще раз нет. Во первых это возможно только для Яндекса, гугл в упор не видит эту директиву. Во вторых. Снижать частоту посещения ботов - это равнозначно грызть себе руку. 2.1 - так же в корне неправильно, читаем мануал к mysql. Она отлично сама кеширует запросы, но в формает постоянно обновляемых данных и данных о просмотре товаров, данная техника неактуальна от слова совсем. 2.2 - в нынешних реалиях от memcache есть прирост только при обращении к повторяющимся данным, как-то например в сео про с кешем от фрилансера. Но на 50 к товаров в сео про кеш вреден больше чем полезен. А в остальных ситуациях, когда происходит одинарное чтение данных из кеша, прирост от memcache по сравнению с файловым кешем ssd - минимален. А при небольшом тюнинге библиотеки файлового кеша и вовсе нивелируется в рамках статистической погрешности. 3. У ботов нет дня и ночи, они не спят. Получить от яндекса пессимизацию с его новым оценочным алгоритмом, который требует ttfb < 3 сек - можно автоматически при такой технике. Топик стартер совершенно верно формулировал мысль но не довел ее до конца. Если мы говорим о идеальном парсинге. Нам обязательно нужен промежуточный контейнер. В виде какого-то хранилища. Либо мы можем использовать технику перевода front-end выдачи каталога на индекс sphinx целиком, а не только поиска, и парсинга товара в базу данных с периодической переиндексацией сфинкса. Для регулярного real-time обновления данных о товарах opencart в коробке и существующие парсеры к сожалению, не сильно подходят. Я обсуждал концепции порционного обновления боевых таблиц как с @usergio так и с @MaxD несколько лет назад. Дядя Сережа покивал головой, сказал круто и забыл. А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает. Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 10 минут назад, Yoda сказал: А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает. Немного оффтоп для этой темы, но видимо надо отозваться. Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр. А без цифр получается, что твои фантазии против моих. Мои фантазии такие: Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все). В худшем случае паралельные запросы задержатся на эти 10 мс. Абсолютно не критично, если один новый товар вставляется раз в несколько секунд. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 13 минут назад, MaxD сказал: Немного оффтоп для этой темы, но видимо надо отозваться. Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр. А без цифр получается, что твои фантазии против моих. Мои фантазии такие: Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все). В худшем случае паралельные запросы задержатся на эти 10 мс. Абсолютно не критично, если один новый товар вставляется раз в несколько секунд. Какие цифры... О чем вы сейчас. Я говорю о базовых принципах работы msysql. Когда мы пишем в таблицу, если она в Myisam - она лочится на чтение. В принципе... Если лочится таблица oc_product и у нас есть хоть какой-то трафик даже от ботов, этот лок вызывает лавинообразный поток наслоения процессов apache, потому что php стоит и ждет. Поэтому если происходит нон-стоп парсинг, то у нас постоянно заперта то одна то вторая то третья таблица, а таблиц с товарами допустим пусть будет 10... Соответсвенно 10 мс превращаются в 100. А в это время нас все время ждет очередь запросов на чтение... В итоге нагинается целиком весь проект. Что мешает сделать промежуточные клоны таблиц p2c p2s ps pd и так далее. Загонять в них 500-1000 наборов данных и одним большим запросом мерджить это с боевыми таблицами - я не знаю. Это достаточно просто. Но видимо все очень уверены в своем скиле. Кроме этого. При изменении данных в любой таблице, сбрасывается внутренний кеш mysql, который мог бы работать на тех запросах которые не используют NOW(). К сожалению, вам лень читать мануал. Давайте все таки начнем с того, что вы внимательно изучите принцип работы MySql с таблицами MYISAM, изучите механизм блокировки и работы кеша. А потом мы начнем говорить дальше.... 13 минут назад, Designer сказал: 2.1. о каких частых обновлениях данных, раз в сутки? 2.2. кешировние на то и нужно, чтобы кешировать повторяющие данные. Если сайт не посещаем, толку от кеширования вообще нет. Встроенный файловое кеширование ос даст только прирост нагрузки. Тюнинг и SEO pro это отдельная тема. Разработка парсера + свинкс для клиентов будет дорогим удовольствием. В 99% клиенты ужасаются от стоимости разработки парсера. От этого и подходы к разработке соответствующие. По поводу промежуточного контейнера, с него придется тоже обновлять данные в реал-тайм иначе, возвращаемся к началу всей проблемы. 2.1 ЕЩЕ РАЗ!!! КЕШИРОВАТЬ нативно ЗАПРОСЫ Mysql средствами PHP, это как мыть голову шампунем, одевая резиновую шапочку. Можно - но сродни идиотизму. 2.2 Если сайт непосещаем. Это не значит что он не будет посещаем в будущем. Если мы говорим о проекте даже на 20 000 товаров. То раз в три дня его должны обойти два бота гугл и яндекс. А это 40 000 посещений за 72 часа... А это 555 заходов в час и 9 заходов в минуту. Это при идеальном роботсе и настроенном сео, а так умножайте на 4, и получаем 36 pageview в час. А кроме этого есть другие боты. А кроме этого есть какие-никакие посетители и так далее... Любой проект, должен быть живым "на холодную". Кеширование - это приятный бонус для повышенной нагрузки на повторяющийся контент. Разработка парсера не так страшна, если у вас есть готовая бизнес-логика обновления товаров и вам достаточно поменять драйвер API поставщика контента. По сути ничем не будет отличаться от смены классов используемого хранилища для кеша в в 2.3 opencart. Обновлять реал-тайм данные в контейнере - да легко. Вот тут подробнее: http://sphinxsearch.com/docs/current/rt-overview.html Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 3 минуты назад, Yoda сказал: К сожалению, вам лень читать мануал. Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 10 минут назад, MaxD сказал: Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Да при чем тут пафос. Таблица на 200-300 000 записей умирает при частых операциях чтения не только из-за локов а из-за перестроения индексов. И о чем мы ща спорим? А мы спорим, о том что долбить в нее по одной записи абослютно неэффективно, когда можно пихнуть 1000 записей за один запрос, и закрыть в принципе все проблемы с локами. Что касается ботов и задержки. Ну не ходят они равномерно и по графику. У пассивной нагрузки всегда есть рапределенные стохастические всплески, которые при постоянном обновлении легко валят голые проекты. На InnoDB мешает перейти full-text индексы, который поддерживает только mariadb10, которая недоступна в большинстве хостинг-платформ. И опять же я не понимаю в чем суть спора. Я долблю про технологию партицированного парсинга уже четвертый год. Какая сложность это реализовать ? У меня есть пример магазина, в котором 500 000 товаров. В нем весь каталог товаров подвешен в Sphinx, при этом база постоянно обновляется - ни единого разрыва. Разнесенные хранилища в разные контейнеры - это абсолютно минус головная боль... Да вы сейчас скажете, что сфинкс надо еще поставить настроить. Ок не вопрос. Кто мешает вам сделать два контейнера в рамках Mysql ? Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 4 минуты назад, Yoda сказал: из-за перестроения индексов Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 20 минут назад, MaxD сказал: Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Мне очень давно не попадались магазины с parseMX. Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. А цифры и выкладки - это не ко мне в данной ситуации. Потому что такими темпами, придется делать собственный парсер, а мне это не интересно. Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 36 минут назад, Yoda сказал: Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. Может у него там с архитектурой что-то не то, тем более его модуль чаще используют для импорта прайсов из файла, там естественно темпы вставки намного выше, чем при обходе внешних сайтов. Из того, что я знаю - ни с ParseMX, ни с LiveImport (который тоже импортирует прайсы) магазины не ложились ни у кого ни на каких хостингах (кроме случаев, когда товаров становилось больше, чем магазин мог тянуть). В любом случае, буду наблюдать за этим ньюансом у клиентов. И да, делать свой парсер - удовольствие такое себе ) Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 21 серпня 2017 Автор Share Опубліковано: 21 серпня 2017 (змінено) О сколько я всего пропустил. Резюмируя: 1. У меня большое сомнение, что если я спарсю весь контент по аптечным товарам себе в базу, сайт не начнет тормозить 2. У поставщика API под это дело выделенная площадка, и я так понимаю, что их основной сайт справочника не хранит данные у себя, а берез их через этот же API. Речь идет о справочнике РЛС. Какое же решение вопроса верное? Хранить все у себя и настраивать свой софт и железо, либо дергать по запросу у поставщика API? Змінено 21 серпня 2017 користувачем yop3bik Надіслати Поділитися на інших сайтах More sharing options... MaDMaxX111 Опубліковано: 21 серпня 2017 Share Опубліковано: 21 серпня 2017 Мое мнение вносить справочник в свою систему, вот что написано на РЛС - " РЛС® Аврора – система публикации данных о лекарствах для интеграции в медицинские информационные системы (МИС), медицинские системы помощи принятия решений, товарные учетные системы дистрибьютеров, аптечных сетей и аптек. Эта система предназначена для разработчиков. Т.е. разработчики должны научиться встраивать публикуемые данные в свои информационные системы, реализовать процедуры периодического обновления." Если сайт будет сильно тормозить то уже применят определенные методы оптимизации нагрузки Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Послуги Програмування, створення модулів, зміна функціональності Нужна реализация подгрузки описания и фото товара по API Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення UpStore – адаптивний універсальний шаблон + Швидкий Старт Автор: 29aleksey SP WAREZ CHECKER - перевірка на піратські та шкідливі модулі (with warez.rip) Автор: spectre Деталі замовлення на сторінці подяки Автор: kJlukOo Вивантаження замовлень у XML Автор: DobriyEvgeniy Octostore - адаптивний, універтальний та продуманий шаблон для Opencart/OcStore Автор: MonstroDesign × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 В 16.08.2017 в 06:15, MaDMaxX111 сказал: Готов реализовать не рекомендую связываться с человеком с рейтингом 1 в реализации сложной задачи! 12 часов назад, yop3bik сказал: Демо доступы есть. База - более 20 тыс позиций. Мне кажется при полном заполнении базы будет тормозить. При полном заполнении не тормозит и миллион! 5 часов назад, Designer сказал: @yop3bik Перераспределение чего? Вообще, можно потратить пару часов времени и спарсить в БД все ночью один раз. При этом нагрузка на сервер будет нулевая. Я не знаю, что Вы хотите перераспределять с мизерным количеством товаров в 20 000. Это не то количество, чтобы загружать на второй сервер, потом дергать с него на основной. Время затраты обработки данных будет даже дольше со второго сервера, чем получать данные от поставщика. Не создавайте себе головную боль с дурными мыслями. Если сайт тормозит от 20 000 позиций, вложите средства в оптимизацию как клиентской части, так и серверной А вы спросите, прежде чем такое пишите! от 20 000 товаров - это не сайт - это сложный проект! Надіслати Поділитися на інших сайтах More sharing options...
Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 21 минуту назад, Designer сказал: Первым делом я и сделал, что задал вопрос! Вы считаете, что от кол-во товаров на сайте, можно проект назвать сложным? Я абсолютно в этом уверен. Так как после 20 000 товаров. Возникают технологические сложности не связанные с движком, а связанные с технологическими особенностями PHP и MYSQL. Из которых, чтобы вам понятно было, конкретно явные - это : а) быстрый контексный поиск, который слабо реализуем на php+mysql, даже через match against б) резервирование нагрузки системы под всплески посещений ботов в) если мы говорим о конкретном случае. И регулярном парсинге остатков, наличия, цен. Необходимы механизмы обхода блокирования таблиц в базе данных при постоянном обновлении данных и перестроении индексов. мог бы дальше продолжить, но мне кажется этого достаточно. приведите аргументы, если не прав хотя бы по этим пунктам. Надіслати Поділитися на інших сайтах More sharing options...
Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 12 минут назад, Designer сказал: @Yoda 1. С поиском понятно, тут сложно не согласиться. 2. Чтобы снизить нагрузку от ботов, можно задать им Crawl-delay и на серверном уровне, запрещать индексацию сайта залетным ботам. 2.1 Query Cache 2.2 Memcache 3. Регулярный парсинг в 4 утра, когда посещение сайта снижается к нулевой отметке, можно не беспокоиться об блокировке и обновлении данных. После парсинга, можно так же можно выполнить оптимизацию и анализ таблиц для перестроении индексов. Но создав сайт и загрузив туда 20к + товаров, я не могу называть это сложным проектом. Помимо Выше указанных Вами пунктов, нужно смотреть и в корень проекта. Так как нагрузить сайт можно и 100 товарами, если у части кода будет утечка памяти, кривой запрос, отсутствие индексов и т.д. 2 - нет нет и еще раз нет. Во первых это возможно только для Яндекса, гугл в упор не видит эту директиву. Во вторых. Снижать частоту посещения ботов - это равнозначно грызть себе руку. 2.1 - так же в корне неправильно, читаем мануал к mysql. Она отлично сама кеширует запросы, но в формает постоянно обновляемых данных и данных о просмотре товаров, данная техника неактуальна от слова совсем. 2.2 - в нынешних реалиях от memcache есть прирост только при обращении к повторяющимся данным, как-то например в сео про с кешем от фрилансера. Но на 50 к товаров в сео про кеш вреден больше чем полезен. А в остальных ситуациях, когда происходит одинарное чтение данных из кеша, прирост от memcache по сравнению с файловым кешем ssd - минимален. А при небольшом тюнинге библиотеки файлового кеша и вовсе нивелируется в рамках статистической погрешности. 3. У ботов нет дня и ночи, они не спят. Получить от яндекса пессимизацию с его новым оценочным алгоритмом, который требует ttfb < 3 сек - можно автоматически при такой технике. Топик стартер совершенно верно формулировал мысль но не довел ее до конца. Если мы говорим о идеальном парсинге. Нам обязательно нужен промежуточный контейнер. В виде какого-то хранилища. Либо мы можем использовать технику перевода front-end выдачи каталога на индекс sphinx целиком, а не только поиска, и парсинга товара в базу данных с периодической переиндексацией сфинкса. Для регулярного real-time обновления данных о товарах opencart в коробке и существующие парсеры к сожалению, не сильно подходят. Я обсуждал концепции порционного обновления боевых таблиц как с @usergio так и с @MaxD несколько лет назад. Дядя Сережа покивал головой, сказал круто и забыл. А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает. Надіслати Поділитися на інших сайтах More sharing options...
MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 10 минут назад, Yoda сказал: А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает. Немного оффтоп для этой темы, но видимо надо отозваться. Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр. А без цифр получается, что твои фантазии против моих. Мои фантазии такие: Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все). В худшем случае паралельные запросы задержатся на эти 10 мс. Абсолютно не критично, если один новый товар вставляется раз в несколько секунд. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 13 минут назад, MaxD сказал: Немного оффтоп для этой темы, но видимо надо отозваться. Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр. А без цифр получается, что твои фантазии против моих. Мои фантазии такие: Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все). В худшем случае паралельные запросы задержатся на эти 10 мс. Абсолютно не критично, если один новый товар вставляется раз в несколько секунд. Какие цифры... О чем вы сейчас. Я говорю о базовых принципах работы msysql. Когда мы пишем в таблицу, если она в Myisam - она лочится на чтение. В принципе... Если лочится таблица oc_product и у нас есть хоть какой-то трафик даже от ботов, этот лок вызывает лавинообразный поток наслоения процессов apache, потому что php стоит и ждет. Поэтому если происходит нон-стоп парсинг, то у нас постоянно заперта то одна то вторая то третья таблица, а таблиц с товарами допустим пусть будет 10... Соответсвенно 10 мс превращаются в 100. А в это время нас все время ждет очередь запросов на чтение... В итоге нагинается целиком весь проект. Что мешает сделать промежуточные клоны таблиц p2c p2s ps pd и так далее. Загонять в них 500-1000 наборов данных и одним большим запросом мерджить это с боевыми таблицами - я не знаю. Это достаточно просто. Но видимо все очень уверены в своем скиле. Кроме этого. При изменении данных в любой таблице, сбрасывается внутренний кеш mysql, который мог бы работать на тех запросах которые не используют NOW(). К сожалению, вам лень читать мануал. Давайте все таки начнем с того, что вы внимательно изучите принцип работы MySql с таблицами MYISAM, изучите механизм блокировки и работы кеша. А потом мы начнем говорить дальше.... 13 минут назад, Designer сказал: 2.1. о каких частых обновлениях данных, раз в сутки? 2.2. кешировние на то и нужно, чтобы кешировать повторяющие данные. Если сайт не посещаем, толку от кеширования вообще нет. Встроенный файловое кеширование ос даст только прирост нагрузки. Тюнинг и SEO pro это отдельная тема. Разработка парсера + свинкс для клиентов будет дорогим удовольствием. В 99% клиенты ужасаются от стоимости разработки парсера. От этого и подходы к разработке соответствующие. По поводу промежуточного контейнера, с него придется тоже обновлять данные в реал-тайм иначе, возвращаемся к началу всей проблемы. 2.1 ЕЩЕ РАЗ!!! КЕШИРОВАТЬ нативно ЗАПРОСЫ Mysql средствами PHP, это как мыть голову шампунем, одевая резиновую шапочку. Можно - но сродни идиотизму. 2.2 Если сайт непосещаем. Это не значит что он не будет посещаем в будущем. Если мы говорим о проекте даже на 20 000 товаров. То раз в три дня его должны обойти два бота гугл и яндекс. А это 40 000 посещений за 72 часа... А это 555 заходов в час и 9 заходов в минуту. Это при идеальном роботсе и настроенном сео, а так умножайте на 4, и получаем 36 pageview в час. А кроме этого есть другие боты. А кроме этого есть какие-никакие посетители и так далее... Любой проект, должен быть живым "на холодную". Кеширование - это приятный бонус для повышенной нагрузки на повторяющийся контент. Разработка парсера не так страшна, если у вас есть готовая бизнес-логика обновления товаров и вам достаточно поменять драйвер API поставщика контента. По сути ничем не будет отличаться от смены классов используемого хранилища для кеша в в 2.3 opencart. Обновлять реал-тайм данные в контейнере - да легко. Вот тут подробнее: http://sphinxsearch.com/docs/current/rt-overview.html Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 3 минуты назад, Yoda сказал: К сожалению, вам лень читать мануал. Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 10 минут назад, MaxD сказал: Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Да при чем тут пафос. Таблица на 200-300 000 записей умирает при частых операциях чтения не только из-за локов а из-за перестроения индексов. И о чем мы ща спорим? А мы спорим, о том что долбить в нее по одной записи абослютно неэффективно, когда можно пихнуть 1000 записей за один запрос, и закрыть в принципе все проблемы с локами. Что касается ботов и задержки. Ну не ходят они равномерно и по графику. У пассивной нагрузки всегда есть рапределенные стохастические всплески, которые при постоянном обновлении легко валят голые проекты. На InnoDB мешает перейти full-text индексы, который поддерживает только mariadb10, которая недоступна в большинстве хостинг-платформ. И опять же я не понимаю в чем суть спора. Я долблю про технологию партицированного парсинга уже четвертый год. Какая сложность это реализовать ? У меня есть пример магазина, в котором 500 000 товаров. В нем весь каталог товаров подвешен в Sphinx, при этом база постоянно обновляется - ни единого разрыва. Разнесенные хранилища в разные контейнеры - это абсолютно минус головная боль... Да вы сейчас скажете, что сфинкс надо еще поставить настроить. Ок не вопрос. Кто мешает вам сделать два контейнера в рамках Mysql ? Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 4 минуты назад, Yoda сказал: из-за перестроения индексов Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 20 минут назад, MaxD сказал: Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Мне очень давно не попадались магазины с parseMX. Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. А цифры и выкладки - это не ко мне в данной ситуации. Потому что такими темпами, придется делать собственный парсер, а мне это не интересно. Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 36 минут назад, Yoda сказал: Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. Может у него там с архитектурой что-то не то, тем более его модуль чаще используют для импорта прайсов из файла, там естественно темпы вставки намного выше, чем при обходе внешних сайтов. Из того, что я знаю - ни с ParseMX, ни с LiveImport (который тоже импортирует прайсы) магазины не ложились ни у кого ни на каких хостингах (кроме случаев, когда товаров становилось больше, чем магазин мог тянуть). В любом случае, буду наблюдать за этим ньюансом у клиентов. И да, делать свой парсер - удовольствие такое себе ) Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 21 серпня 2017 Автор Share Опубліковано: 21 серпня 2017 (змінено) О сколько я всего пропустил. Резюмируя: 1. У меня большое сомнение, что если я спарсю весь контент по аптечным товарам себе в базу, сайт не начнет тормозить 2. У поставщика API под это дело выделенная площадка, и я так понимаю, что их основной сайт справочника не хранит данные у себя, а берез их через этот же API. Речь идет о справочнике РЛС. Какое же решение вопроса верное? Хранить все у себя и настраивать свой софт и железо, либо дергать по запросу у поставщика API? Змінено 21 серпня 2017 користувачем yop3bik Надіслати Поділитися на інших сайтах More sharing options... MaDMaxX111 Опубліковано: 21 серпня 2017 Share Опубліковано: 21 серпня 2017 Мое мнение вносить справочник в свою систему, вот что написано на РЛС - " РЛС® Аврора – система публикации данных о лекарствах для интеграции в медицинские информационные системы (МИС), медицинские системы помощи принятия решений, товарные учетные системы дистрибьютеров, аптечных сетей и аптек. Эта система предназначена для разработчиков. Т.е. разработчики должны научиться встраивать публикуемые данные в свои информационные системы, реализовать процедуры периодического обновления." Если сайт будет сильно тормозить то уже применят определенные методы оптимизации нагрузки Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Послуги Програмування, створення модулів, зміна функціональності Нужна реализация подгрузки описания и фото товара по API Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення UpStore – адаптивний універсальний шаблон + Швидкий Старт Автор: 29aleksey SP WAREZ CHECKER - перевірка на піратські та шкідливі модулі (with warez.rip) Автор: spectre Деталі замовлення на сторінці подяки Автор: kJlukOo Вивантаження замовлень у XML Автор: DobriyEvgeniy Octostore - адаптивний, універтальний та продуманий шаблон для Opencart/OcStore Автор: MonstroDesign × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 13 минут назад, MaxD сказал: Немного оффтоп для этой темы, но видимо надо отозваться. Yoda, у тебя нет никаких цифр, как и у меня. Если я ошибаюсь - поделись, будь добр. А без цифр получается, что твои фантазии против моих. Мои фантазии такие: Кеш MySQL с товарами не работает, его не рассматриваем. Запросы для записи нового товара в базу относительно быстрые (меньше 10 мс на все). В худшем случае паралельные запросы задержатся на эти 10 мс. Абсолютно не критично, если один новый товар вставляется раз в несколько секунд. Какие цифры... О чем вы сейчас. Я говорю о базовых принципах работы msysql. Когда мы пишем в таблицу, если она в Myisam - она лочится на чтение. В принципе... Если лочится таблица oc_product и у нас есть хоть какой-то трафик даже от ботов, этот лок вызывает лавинообразный поток наслоения процессов apache, потому что php стоит и ждет. Поэтому если происходит нон-стоп парсинг, то у нас постоянно заперта то одна то вторая то третья таблица, а таблиц с товарами допустим пусть будет 10... Соответсвенно 10 мс превращаются в 100. А в это время нас все время ждет очередь запросов на чтение... В итоге нагинается целиком весь проект. Что мешает сделать промежуточные клоны таблиц p2c p2s ps pd и так далее. Загонять в них 500-1000 наборов данных и одним большим запросом мерджить это с боевыми таблицами - я не знаю. Это достаточно просто. Но видимо все очень уверены в своем скиле. Кроме этого. При изменении данных в любой таблице, сбрасывается внутренний кеш mysql, который мог бы работать на тех запросах которые не используют NOW(). К сожалению, вам лень читать мануал. Давайте все таки начнем с того, что вы внимательно изучите принцип работы MySql с таблицами MYISAM, изучите механизм блокировки и работы кеша. А потом мы начнем говорить дальше.... 13 минут назад, Designer сказал: 2.1. о каких частых обновлениях данных, раз в сутки? 2.2. кешировние на то и нужно, чтобы кешировать повторяющие данные. Если сайт не посещаем, толку от кеширования вообще нет. Встроенный файловое кеширование ос даст только прирост нагрузки. Тюнинг и SEO pro это отдельная тема. Разработка парсера + свинкс для клиентов будет дорогим удовольствием. В 99% клиенты ужасаются от стоимости разработки парсера. От этого и подходы к разработке соответствующие. По поводу промежуточного контейнера, с него придется тоже обновлять данные в реал-тайм иначе, возвращаемся к началу всей проблемы. 2.1 ЕЩЕ РАЗ!!! КЕШИРОВАТЬ нативно ЗАПРОСЫ Mysql средствами PHP, это как мыть голову шампунем, одевая резиновую шапочку. Можно - но сродни идиотизму. 2.2 Если сайт непосещаем. Это не значит что он не будет посещаем в будущем. Если мы говорим о проекте даже на 20 000 товаров. То раз в три дня его должны обойти два бота гугл и яндекс. А это 40 000 посещений за 72 часа... А это 555 заходов в час и 9 заходов в минуту. Это при идеальном роботсе и настроенном сео, а так умножайте на 4, и получаем 36 pageview в час. А кроме этого есть другие боты. А кроме этого есть какие-никакие посетители и так далее... Любой проект, должен быть живым "на холодную". Кеширование - это приятный бонус для повышенной нагрузки на повторяющийся контент. Разработка парсера не так страшна, если у вас есть готовая бизнес-логика обновления товаров и вам достаточно поменять драйвер API поставщика контента. По сути ничем не будет отличаться от смены классов используемого хранилища для кеша в в 2.3 opencart. Обновлять реал-тайм данные в контейнере - да легко. Вот тут подробнее: http://sphinxsearch.com/docs/current/rt-overview.html Надіслати Поділитися на інших сайтах More sharing options...
MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 3 минуты назад, Yoda сказал: К сожалению, вам лень читать мануал. Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 10 минут назад, MaxD сказал: Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Да при чем тут пафос. Таблица на 200-300 000 записей умирает при частых операциях чтения не только из-за локов а из-за перестроения индексов. И о чем мы ща спорим? А мы спорим, о том что долбить в нее по одной записи абослютно неэффективно, когда можно пихнуть 1000 записей за один запрос, и закрыть в принципе все проблемы с локами. Что касается ботов и задержки. Ну не ходят они равномерно и по графику. У пассивной нагрузки всегда есть рапределенные стохастические всплески, которые при постоянном обновлении легко валят голые проекты. На InnoDB мешает перейти full-text индексы, который поддерживает только mariadb10, которая недоступна в большинстве хостинг-платформ. И опять же я не понимаю в чем суть спора. Я долблю про технологию партицированного парсинга уже четвертый год. Какая сложность это реализовать ? У меня есть пример магазина, в котором 500 000 товаров. В нем весь каталог товаров подвешен в Sphinx, при этом база постоянно обновляется - ни единого разрыва. Разнесенные хранилища в разные контейнеры - это абсолютно минус головная боль... Да вы сейчас скажете, что сфинкс надо еще поставить настроить. Ок не вопрос. Кто мешает вам сделать два контейнера в рамках Mysql ? Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 4 минуты назад, Yoda сказал: из-за перестроения индексов Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 20 минут назад, MaxD сказал: Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Мне очень давно не попадались магазины с parseMX. Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. А цифры и выкладки - это не ко мне в данной ситуации. Потому что такими темпами, придется делать собственный парсер, а мне это не интересно. Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 36 минут назад, Yoda сказал: Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. Может у него там с архитектурой что-то не то, тем более его модуль чаще используют для импорта прайсов из файла, там естественно темпы вставки намного выше, чем при обходе внешних сайтов. Из того, что я знаю - ни с ParseMX, ни с LiveImport (который тоже импортирует прайсы) магазины не ложились ни у кого ни на каких хостингах (кроме случаев, когда товаров становилось больше, чем магазин мог тянуть). В любом случае, буду наблюдать за этим ньюансом у клиентов. И да, делать свой парсер - удовольствие такое себе ) Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 21 серпня 2017 Автор Share Опубліковано: 21 серпня 2017 (змінено) О сколько я всего пропустил. Резюмируя: 1. У меня большое сомнение, что если я спарсю весь контент по аптечным товарам себе в базу, сайт не начнет тормозить 2. У поставщика API под это дело выделенная площадка, и я так понимаю, что их основной сайт справочника не хранит данные у себя, а берез их через этот же API. Речь идет о справочнике РЛС. Какое же решение вопроса верное? Хранить все у себя и настраивать свой софт и железо, либо дергать по запросу у поставщика API? Змінено 21 серпня 2017 користувачем yop3bik Надіслати Поділитися на інших сайтах More sharing options... MaDMaxX111 Опубліковано: 21 серпня 2017 Share Опубліковано: 21 серпня 2017 Мое мнение вносить справочник в свою систему, вот что написано на РЛС - " РЛС® Аврора – система публикации данных о лекарствах для интеграции в медицинские информационные системы (МИС), медицинские системы помощи принятия решений, товарные учетные системы дистрибьютеров, аптечных сетей и аптек. Эта система предназначена для разработчиков. Т.е. разработчики должны научиться встраивать публикуемые данные в свои информационные системы, реализовать процедуры периодического обновления." Если сайт будет сильно тормозить то уже применят определенные методы оптимизации нагрузки Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Послуги Програмування, створення модулів, зміна функціональності Нужна реализация подгрузки описания и фото товара по API Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення UpStore – адаптивний універсальний шаблон + Швидкий Старт Автор: 29aleksey SP WAREZ CHECKER - перевірка на піратські та шкідливі модулі (with warez.rip) Автор: spectre Деталі замовлення на сторінці подяки Автор: kJlukOo Вивантаження замовлень у XML Автор: DobriyEvgeniy Octostore - адаптивний, універтальний та продуманий шаблон для Opencart/OcStore Автор: MonstroDesign
Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 10 минут назад, MaxD сказал: Ну уж мне хоть своего привычного пафоса не пиши. Для лавинообразного наслоения процессов апаче под "хоть каким-то трафиком от ботов" нужны задержки порядка 10+ секунд. Никаких дополнительных 100 мс к этому не приведут. Что мешает перейти на InnoDB, если так страшат локи? Одни плюсы. Yoda, ты лучше меня знаешь, что практически все запросы Opencart, которые стоит кешировать, используют таблицу product. Остальные и так быстрые. Ну ты сам в пункте 2.1 обьясняешь, как парадоксально. Да при чем тут пафос. Таблица на 200-300 000 записей умирает при частых операциях чтения не только из-за локов а из-за перестроения индексов. И о чем мы ща спорим? А мы спорим, о том что долбить в нее по одной записи абослютно неэффективно, когда можно пихнуть 1000 записей за один запрос, и закрыть в принципе все проблемы с локами. Что касается ботов и задержки. Ну не ходят они равномерно и по графику. У пассивной нагрузки всегда есть рапределенные стохастические всплески, которые при постоянном обновлении легко валят голые проекты. На InnoDB мешает перейти full-text индексы, который поддерживает только mariadb10, которая недоступна в большинстве хостинг-платформ. И опять же я не понимаю в чем суть спора. Я долблю про технологию партицированного парсинга уже четвертый год. Какая сложность это реализовать ? У меня есть пример магазина, в котором 500 000 товаров. В нем весь каталог товаров подвешен в Sphinx, при этом база постоянно обновляется - ни единого разрыва. Разнесенные хранилища в разные контейнеры - это абсолютно минус головная боль... Да вы сейчас скажете, что сфинкс надо еще поставить настроить. Ок не вопрос. Кто мешает вам сделать два контейнера в рамках Mysql ? Надіслати Поділитися на інших сайтах More sharing options...
MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 4 минуты назад, Yoda сказал: из-за перестроения индексов Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Надіслати Поділитися на інших сайтах More sharing options... Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 20 минут назад, MaxD сказал: Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Мне очень давно не попадались магазины с parseMX. Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. А цифры и выкладки - это не ко мне в данной ситуации. Потому что такими темпами, придется делать собственный парсер, а мне это не интересно. Надіслати Поділитися на інших сайтах More sharing options... MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 36 минут назад, Yoda сказал: Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. Может у него там с архитектурой что-то не то, тем более его модуль чаще используют для импорта прайсов из файла, там естественно темпы вставки намного выше, чем при обходе внешних сайтов. Из того, что я знаю - ни с ParseMX, ни с LiveImport (который тоже импортирует прайсы) магазины не ложились ни у кого ни на каких хостингах (кроме случаев, когда товаров становилось больше, чем магазин мог тянуть). В любом случае, буду наблюдать за этим ньюансом у клиентов. И да, делать свой парсер - удовольствие такое себе ) Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 21 серпня 2017 Автор Share Опубліковано: 21 серпня 2017 (змінено) О сколько я всего пропустил. Резюмируя: 1. У меня большое сомнение, что если я спарсю весь контент по аптечным товарам себе в базу, сайт не начнет тормозить 2. У поставщика API под это дело выделенная площадка, и я так понимаю, что их основной сайт справочника не хранит данные у себя, а берез их через этот же API. Речь идет о справочнике РЛС. Какое же решение вопроса верное? Хранить все у себя и настраивать свой софт и железо, либо дергать по запросу у поставщика API? Змінено 21 серпня 2017 користувачем yop3bik Надіслати Поділитися на інших сайтах More sharing options... MaDMaxX111 Опубліковано: 21 серпня 2017 Share Опубліковано: 21 серпня 2017 Мое мнение вносить справочник в свою систему, вот что написано на РЛС - " РЛС® Аврора – система публикации данных о лекарствах для интеграции в медицинские информационные системы (МИС), медицинские системы помощи принятия решений, товарные учетные системы дистрибьютеров, аптечных сетей и аптек. Эта система предназначена для разработчиков. Т.е. разработчики должны научиться встраивать публикуемые данные в свои информационные системы, реализовать процедуры периодического обновления." Если сайт будет сильно тормозить то уже применят определенные методы оптимизации нагрузки Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Послуги Програмування, створення модулів, зміна функціональності Нужна реализация подгрузки описания и фото товара по API
Yoda Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 20 минут назад, MaxD сказал: Да, ты и тогда про перестроение индексов говорил. Нету в MySQL перестроения индексов при изменении данных, в индексе меняется/вставляется/удаляется только одно нужное значение. Спорим мы вот о чем. Чтобы был смысл городить такой огород с промежуточным хранилищем (а городить там прилично), нужны веские реальные цифры вида "среднее время отклика сайта такое-то, запускаем парсинг - выростает вдвое". И чтобы еще было видно, что именно MySQL садится, и желательно на каких именно запросах. На той же shopica остановка парсинга как-то не особо ее оживляла. Мне очень давно не попадались магазины с parseMX. Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. А цифры и выкладки - это не ко мне в данной ситуации. Потому что такими темпами, придется делать собственный парсер, а мне это не интересно. Надіслати Поділитися на інших сайтах More sharing options...
MaxD Опубліковано: 18 серпня 2017 Share Опубліковано: 18 серпня 2017 36 минут назад, Yoda сказал: Но вот модуль @usergio, дай бог ему здоровья, стоит на каждом втором магазине. И я думаю, что каждый владелец его модуля подтвердит, что в момент работы парсера, магазин ложится на слабых хостингах, или начинает существенно подтормаживать на нормальных. Может у него там с архитектурой что-то не то, тем более его модуль чаще используют для импорта прайсов из файла, там естественно темпы вставки намного выше, чем при обходе внешних сайтов. Из того, что я знаю - ни с ParseMX, ни с LiveImport (который тоже импортирует прайсы) магазины не ложились ни у кого ни на каких хостингах (кроме случаев, когда товаров становилось больше, чем магазин мог тянуть). В любом случае, буду наблюдать за этим ньюансом у клиентов. И да, делать свой парсер - удовольствие такое себе ) Надіслати Поділитися на інших сайтах More sharing options... yop3bik Опубліковано: 21 серпня 2017 Автор Share Опубліковано: 21 серпня 2017 (змінено) О сколько я всего пропустил. Резюмируя: 1. У меня большое сомнение, что если я спарсю весь контент по аптечным товарам себе в базу, сайт не начнет тормозить 2. У поставщика API под это дело выделенная площадка, и я так понимаю, что их основной сайт справочника не хранит данные у себя, а берез их через этот же API. Речь идет о справочнике РЛС. Какое же решение вопроса верное? Хранить все у себя и настраивать свой софт и железо, либо дергать по запросу у поставщика API? Змінено 21 серпня 2017 користувачем yop3bik Надіслати Поділитися на інших сайтах More sharing options... MaDMaxX111 Опубліковано: 21 серпня 2017 Share Опубліковано: 21 серпня 2017 Мое мнение вносить справочник в свою систему, вот что написано на РЛС - " РЛС® Аврора – система публикации данных о лекарствах для интеграции в медицинские информационные системы (МИС), медицинские системы помощи принятия решений, товарные учетные системы дистрибьютеров, аптечных сетей и аптек. Эта система предназначена для разработчиков. Т.е. разработчики должны научиться встраивать публикуемые данные в свои информационные системы, реализовать процедуры периодического обновления." Если сайт будет сильно тормозить то уже применят определенные методы оптимизации нагрузки Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку
yop3bik Опубліковано: 21 серпня 2017 Автор Share Опубліковано: 21 серпня 2017 (змінено) О сколько я всего пропустил. Резюмируя: 1. У меня большое сомнение, что если я спарсю весь контент по аптечным товарам себе в базу, сайт не начнет тормозить 2. У поставщика API под это дело выделенная площадка, и я так понимаю, что их основной сайт справочника не хранит данные у себя, а берез их через этот же API. Речь идет о справочнике РЛС. Какое же решение вопроса верное? Хранить все у себя и настраивать свой софт и железо, либо дергать по запросу у поставщика API? Змінено 21 серпня 2017 користувачем yop3bik Надіслати Поділитися на інших сайтах More sharing options...
MaDMaxX111 Опубліковано: 21 серпня 2017 Share Опубліковано: 21 серпня 2017 Мое мнение вносить справочник в свою систему, вот что написано на РЛС - " РЛС® Аврора – система публикации данных о лекарствах для интеграции в медицинские информационные системы (МИС), медицинские системы помощи принятия решений, товарные учетные системы дистрибьютеров, аптечных сетей и аптек. Эта система предназначена для разработчиков. Т.е. разработчики должны научиться встраивать публикуемые данные в свои информационные системы, реализовать процедуры периодического обновления." Если сайт будет сильно тормозить то уже применят определенные методы оптимизации нагрузки Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0
Recommended Posts