Привет коллеги. Кто-то сталкивался со странным поведением своих AJAX-запросов к компоненту, при которых некоторые запросы отрабатываются менее чем за 100мс, а другие в 3-4 дольше, хотя в первом случаи отправлено в 10-20-30 раз больше данных чем во втором и при этом в компоненте с этими данными ничего не делается, не пишется в инфоблоки, не читается, нет циклов и обработок. Для теста просто идет проверка на HTTP_X_REQUESTED_WITH, чтобы убедиться, что это AJAX, а потом сразу return;
С другой стороны, ведь при отправке AJAX отправляется все одно и тоже и по одному и тому же адресу, разве что разница только в длине отправляемых данных.
запросы уникальные по урлу? кеширования нет браузерного?
Проверяли в сети компании, когда никого не было, трафик у всех порезан кроме меня. Смотрели и с кэшем и без него.
При проверке запросы всегда идентичные, в том плане что, там где медленный запрос отправляется всегда одна и та же пачка данных, там где быстро своя пачка, но тоже одна и та же. Как только я сделаю, так что с обеих страниц отправляется то, что с быстрой, то на медленной тоже становится все моментально)
В любом случаи, мне в ТП Битрикса написали так:
Добрый день!
Со строковыми функциями всё в порядке, библиотека mbsting настроена корректно.
В данном случае единственным способом найти причину зависания будет использование профилировщика xdebug (расширение PHP):
Для этого в php.ini включите отладку:
xdebug.collect_params=3
xdebug.trace_output_name=trace.%s.%R.%r.xt
xdebug.trace_output_dir=/path/to/the/folder/webserver/can/write
xdebug.auto_trace = 1
Перезапустите сервер. Начнётся логирование выполнение PHP скриптов.
После того, как появится подвисание, появятся файлы (последних хитов) в папки /path/to/the/folder/webserver/can/write/. По ним можно понять, что тормозит.
Они тоже сказали что у них наблюдается разница во времени ответа в 3-4 раза. Магия какая-то... Лично я думаю, что битриксоидные прологи что-то проверяют в отправленных данных, и в медленном случаи они там что-то долго копаются.
Аналогичное поведение, если отправлять запросы не в компонент, где они обрабатываются, а на фиктивную страницу.
Сейчас провел эксперимент. Отправил запросы на страницу 1.php, на которой ничего нет, просто пустой файл, и! Результат такой же. Быстрый запрос исполнился за 11мс, медленный за 250+мс. В чем прикол не понимаю...
xdebug показал что запросы исполняются одинаковое количество времени, получается что проблема где-то на уровне офисного прокси или офисной инфраструктуры...
Практически каждый разработчик, который начинает работать с 1С-Битрикс, рано или поздно сталкивается с переносом сайта с другой CMS или с созданием интернет-магазина с огромным прайсом и когда это происходит, приходиться придумывать варианты загрузки большого количества данных в инфоблоки. Ну, как придумывать, есть конечно способы импорта данных, которые Битрикс предлагает из коробки, но к сожалению, они не всем нравятся из-за своей прожорливости и скорости.
Наверное, всем знакомо чувство недоумения, когда начинаешь пользоваться бесспорно лучшей коммерческой системой и практически сразу натыкаешься на ряд нелепых недоработок, недоделок, а может быть и специально урезанный функционал, чтобы мы с Вами имели возможность писать и читать подобные посты и совместными усилиями исправлять некоторые из таких ошибок.
Самый распространенный способ импорта данных в инфоблоки в 1С-Битрикс – это конечно CSV файлы. Но как показывает практика (а тем, кто еще с этим не столкнулся, она точно покажет), в ряде случаем работать с этим форматом практически не реально. Проблемы встречаются только в том случаи, если мы попытаемся экспортировать или импортировать из инфоблока элементы, у которых есть свойства с множественным выбором и эти свойства у элемента заполнены.
Все мы знаем, что при импорте и экспорте из CSV Битрикс не понимает того, что у одного элемента может быть свойство, например, типа «Список» с множественным выбором и выбрано там 10 значений, так как за один проход импорта и экспорта, он может извлечь и записать только по одному выбранному значению у таких свойств, от сюда мы получаем, что если бы у нас был один элемент в инфоблоке с одним множественным свойством типа «Список», то при экспорте такого инфоблока у нас бы создалось 11 строк для всего одного элемента с одним свойством. Почему 11? 1 строка для шапки и 10 для всех проставленных галочек в нашем списке. При импорте, Битрикс так же бы построчно проставлял галочки обратно, т.е. для импорта элемента с таким же свойством нам понадобился бы тот же файл с 11 строками.
А вот уже более-менее реальный пример из жизни Если создать инфоблок и добавить в него все существующие свойства, а их 20 (Привязка к товарам (SKU) не может быть множественным) и указать, что они множественные, после чего создать всего один элемент этого инфоблока и в каждое свойство внести по 2 значения, допустим просто цифру 1 и 2, а потом попробовать экспортировать данный инфоблок с одним элементом штатным экспортом, то мы получим CSV файл в котором будет 220 = 1 048 576 строк и будет такой файл весить около 57 МБ! Совсем не дурно для одного элемента, да? А если у нас интернет-магазин с прайсом на 10000 товаров? Я думаю тут без подсчета понятно, что загружать такой файл или выгружать просто не реально.
Мы, как и любая другая компания столкнулись с такими трудностями, когда создавали крупный интернет-магазин. Но мы легких путей искать не стали и изменили штатный импорт/экспорт в CSV, добавив в него возможность указать разделитель для множественных свойств, а также транслитерацию символьных кодов. Интересна математика с данным модулем? Если за расчеты взять вариант с одним элементом у которого 20 свойств и по 2 значения в каждом, то при использовании нашего модуля получится CSV файл, имеющий 2 строки и весом 400 байт. Ощутимая разница… И импортироваться такой файл конечно же будет намного быстрее.
Есть, пожалуй, в модуле один недостаток, он не работает с торговым каталогом. Но я уверен, что в будущем мы доработаем его и он сможет полноценно стать must have любого проекта. Воспользоваться данным модулем можно абсолютно бесплатно, просто скачайте его через
Евгений Микулич, коммерческий - разумеется. Но мы пытались немного облегчить жизнь именно на начальной работе, тем кто не знаком с обменом через XML или это не требовалось в проекте. Надеемся нам это удалось.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
А если у нас интернет-магазин с прайсом на 10000 товаров? Я думаю тут без подсчета понятно, что загружать такой файл или выгружать просто не реально.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
