OkayCMS писал(а):Создавать один модуль для всего как раз таки и не нужно, так как у клиентов наоборот другие запросы. Они хотят выгружать одни товары в хотлайн, другие в Яндекс, а третьи на Розетку.
OkayCMS писал(а):По документации к модулям - не совсем понял даже, что именно вы хотите там увидеть?
korshunov писал(а):В версии 3.5.0 появился новый модуль выгрузки OkayCMS/HotLine.
документацию ... с упором на отличия между ними.
korshunov писал(а):OkayCMS писал(а):Создавать один модуль для всего как раз таки и не нужно, так как у клиентов наоборот другие запросы. Они хотят выгружать одни товары в хотлайн, другие в Яндекс, а третьи на Розетку.
У клиентов вряд ли будут запросы на то, сколько модулей. Если один модуль им будет выгружать и в Hotline, и в Rozetka, они возражать не будут. Речь именно о специалистах, которые сейчас нерациональным образом дублируют большие количества кода...OkayCMS писал(а):По документации к модулям - не совсем понял даже, что именно вы хотите там увидеть?
Ранее сказано:korshunov писал(а):В версии 3.5.0 появился новый модуль выгрузки OkayCMS/HotLine.
документацию ... с упором на отличия между ними.
OkayCMS писал(а):Модуль Хотлайн создан для того чтобы выгружать товары в том формате, в котором требует хотлайн, а модуль Розетка в том формате в котором требует розетка и в этом между ними разница?
korshunov писал(а):Провожу некоторые эксперименты по реальных объемам требуемой пямяти, которые требуются модулю:
227 товаров, описание 10000 байт, memory peak usage: 20 599 720
227 товаров, описание 20000 байт, memory peak usage: 26 186 664
227 товаров, описание 30000 байт, memory peak usage: 34 513 832
227 товаров, описание 40000 байт, memory peak usage: 40 092 584
227 товаров, описание 50000 байт, memory peak usage: 48 460 200
227 товаров, описание 60000 байт, memory peak usage: 54 039 464
227 товаров, описание 70000 байт, memory peak usage: 61 526 952
Вторая серия:
0 товаров, описание 10000 байт, memory peak usage: 10 566 152
1 товар, описание 10000 байт, memory peak usage: 10 566 088
227 товаров, описание 10000 байт, memory peak usage: 20 599 720
300 товаров, описание 10000 байт, memory peak usage: 23 846 936
325 товаров, описание 10000 байт, memory peak usage: 24 940 112
350 товаров, описание 10000 байт, memory peak usage: 26 037 320
375 товаров, описание 10000 байт, memory peak usage: 27 150 912
400 товаров, описание 10000 байт, memory peak usage: 28 252 248
Выходит примерно 40К памяти на каждый товар.
Если в выгрузке 10000 товаров, то надо 400M памяти - уже тяжко будет хостингу такое тянуть, если вообще потянет.
А если по полной программе (в требованиях Hotlint разрешается до 150 тыс товаров на один файл), то памяти надо уже 6G - это уж ни в какие ворота....
Для сравнения выгрузка yandex.php в Simpla в перечисленных аналогичных случях требует memory peak usage в пределах 2M...
Вышеприведенные цифры относятся к случаю, если в настройках модуля задать краткое описание.
Если же в настройках задать полное описание, то цифры существенно выше.
По ходу обнаружилась еще такая ошибочка - если в настройках задать краткое описание, то запрос к базе все равно вытягивает бесполезные большие объемы полного описания...
Насколько я понимаю, подобные нерациональности относятся и к прочих аналогичным выгрузкам.
Интересно, работает ли это реально у кого-то при большом числе товаров?
OkayCMS писал(а):Сравнивать с файлом симплы, как мне кажется не совсем корректно, ведь в нем не передаются доп. фото товара, характиристики товара и прочие моменты, которые можно настроить индивидуально для выгрузки.
Код: Выделить всё
$products = $productsHelper->attachImages($products);
$products = $this->sliceImagesByProduct($products, 10);
$products = $productsHelper->attachFeatures($products);
$countryOfOrigin = $this->settings->get('okaycms__hotline__country_of_origin');
if (!empty($countryOfOrigin)) {
$products = $this->attachCountryOfOriginParameter($products);
}
$products = $this->attachGuaranteeParameter($products);
Нет конечно. В симпле другой подход для вывода товаров, это когда из кортежа результатов php всегда считывает только один результат (что кстати говорит о не совсем корректном замере расходов памяти). Такой подход возможен только если для товаров не нужно доставать дополнительные данные (изображения, свойства etc). Если же хотите сравнить с симплой (убрав свойства, изображения...), тогда сделайте этот кусок как в симпле. А вы подошли к вопросу очень легковесно замерив какие-то параметры для абсолютно разных скриптов, и ваши замеры в данном случае очень ошибочны.korshunov писал(а):Такое сравнение с Simpla, надеюсь, для Вас более корректно?
Но и тем не менее, некоторые ваши замечания по посту выше учтены, и уже внесены соответствующие фиксы, в будущей версии выйдут.korshunov писал(а):Эх-мм, ожидался от Вас более серьезный ответ по существу, а не легковесная реакция на самое малозначительное замечание.
zyxer писал(а):В симпле другой подход для вывода товаров, это когда из кортежа результатов php всегда считывает только один результат (что кстати говорит о не совсем корректном замере расходов памяти).
zyxer писал(а):Такой подход возможен только если для товаров не нужно доставать дополнительные данные (изображения, свойства etc).
zyxer писал(а):Если же хотите сравнить с симплой (убрав свойства, изображения...), тогда сделайте этот кусок как в симпле. А вы подошли к вопросу очень легковесно замерив какие-то параметры для абсолютно разных скриптов, и ваши замеры в данном случае очень ошибочны.
zyxer писал(а):P.S. Мне как-то сказали: "если кто-то считает что может написать web-апликуху, которая может на 10-15МБ памяти работать, быстрее пишите резюмеху в гугл))" Это я к тому, что ваши замеры (когда вы в данном случае сравниваете эти две выгрузки) не совсем корректны.
zyxer писал(а):Еще, если вас не затруднит, провести такой же анализ на примере модуля YandexXML, было бы интересно увидеть ваши результаты )
zyxer писал(а):Проанализировав всё вышесказанное, перепробовав много различных вариантов работы модуля, получилась принципиально другая версия модуля.
zyxer писал(а):По своим замерам памяти, вижу такие результаты, при выводе чуть более 100К товаров (но товары я не выводил, а печатал в файл, иначе браузер на машине создаёт большую нагрузку и точность измерения вообще никакая).
zyxer писал(а):...там, где печатаются товары, нельзя делать никаких sql запросов, т.к. там используются небуферизированные запросы, и любой запров в БД в это время сломает вывод.
Запустил выгрузку, но там где вывод, я его убирал и делал запись в файл http://prntscr.com/rsc9ir. Итоговый файл получился около 400+ МБ.korshunov писал(а):Хорошо было бы, если б Вы показали свои методы тестирования, хотя бы по минимуму. Ибо тестирование часто есть процесс весьма тонкий и его можно делать очень по-разному и соответственно получать разные результаты...
11 МБ это объем ОЗУ (по идее это то же что и memory_get_peak_usage(), но не уверен что прям одно и тоже). И эти БМ некорректно делить на кол-во товаров, т.к. в памяти в данном случае мы храним один товар.korshunov писал(а):В частности, сейчас выглядит по меньшей мере странно, что у Вас 100К товаров дают в результате файл 11M. Это значит, что в результирующем файле на запись одного товара приходится в среднем лишь 110 байт. Даже одни XML-теги с пустыми значениями заняли бы намного больше...
разрабатываю на локальной машине, поэтому если ловить xml в браузер (которая 400+ МБ) браузер начинает создавать на этой же машине нагрузку и точность изменений начинает "плавать"korshunov писал(а):Опять же, обычно при тестировании стоит вопрос о работе СЕРВЕРА, ибо разработчикам сайтов тестировать пользовательские компьютеры и браузеры из-за их разнообразия никакого смысла нет. И почему у Вас это смешивается в одну кучу и почему у Вас проблемы с точностью, можно только гадать...
просто интересно, это было на одном коннекте к БД?korshunov писал(а):Вопрос не принципиальный, но при некоторой смекалке это все можно. Когда-то довольно давно приходилось делать в экзотической ситуации для Simpla параллельную обработку двух небуфферизованных запросов. В Okay не пробовал, но скорее всего пойдет тоже...
zyxer писал(а):просто интересно, это было на одном коннекте к БД?
zyxer писал(а):разрабатываю на локальной машине, поэтому если ловить xml в браузер (которая 400+ МБ) браузер начинает создавать на этой же машине нагрузку и точность изменений начинает "плавать"
zyxer писал(а):11 МБ это объем ОЗУ (по идее это то же что и memory_get_peak_usage(), но не уверен что прям одно и тоже).
korshunov писал(а):Еще выплыли недостатки модуля Hotline.
Модуль создает в таблице ok_products два поля to__okaycms__hotline, not_to__okaycms__hotline.
Первое: если отмечено (значение 1), то выводить товар в выгрузку.
Второе: если отмечено (значение 1), то не выводить товар в выгрузку.
Вроде бы все просто и понятно, но лишь на первый взгляд.
А если чуть задуматься, то сразу видно, что изначально заложены в логику нерациональность и противоречивость. Которые добавляют неудобства в пользовании. И в некоторых случаях возможен даже отказ в работе в админке...
1. Противоречивость.
А если ОБА поля отмечены? Это можно сделать просто и легко, в админке контроля за этим нет. Получаем противоречивость. Легко проверить методом испытаний, что в этой ситуации приоритет за вторым полем. Но, конечно, путаница у админа очень вероятна при многочисленных применениях этих полей.
2. Нерациональность.
Эти два поля легко заменить на одно, и все противоречивости уйдут (разве что в админке как-то надо разрешить вопрос одновременной установки обоих полей). И именно так - одним полем - делается давно-давно как в Simpla, так и в Okay в других подобных ситуациях, когда надо использовать параметр ДА-НЕТ.
3. Неудобство.
3.1. Неудобство маленькое. Если надо отметить нужное поле хотя бы у десятка-другого товаров, то начинается мучение: каждому товару надо ввести текст для поиска, потом найти товар, кликнуть.
3.2. Неудобство побольше. Если в списках для обоих полей много пунктов, а Вы пытаетесь добавить в первый список новый товар, то надо еще проверять, не содержится ли он во втором списке - ведь иначе не сработает, так как при коллизиях приоритет за вторым списком. А определять каждый раз, есть ли он там, довольно утомительно, если список большой...
3.3. Неудобство совсем большое, критичное. Если в списках очень много товаров, то они все выводятся на страницу редактирования модуля. А это может приводить к тому, что страница долго грузится или даже просто зависает. У меня зависания начинаются при 5 тыс товаров в списке. А это ведь далеко до предела, если разработчик нам тут рассказывает, что он тестирует на базе в 100К товаров...
3.4. В то же время перед глазами в админке на странице списка товаров образец удобной организации, пришедший из Simpla - легко и просто - смотришь список и кликаешь.
Зачем разработчики Okay на пустом месте придумали кривой велосипед, для меня загадка...
korshunov писал(а):Вы зачем-то считаете нужным подробно объяснять СВОЙ СОБСТВЕННЫЙ подход, забывая о том, что пользователи разные, их много, у всех свои потребности и запросы. А задачей разработчика должна быть максимально возможная гибкость функционала под разные потребности
Вернуться в «Вопросы по работе с OkayCMS»
Сейчас этот раздел просматривают: 58 гостей