Dios__deactivated (Все сообщения пользователя)

Дело не в нагрузке базы, таблицы для 100к товаров с 10к свойств это копейки. Разбивай по отдельным таблицам или нет, толком нечего не даст. Для MySQL это не те цифры.

Проблема чисто в админской оснаске и типовых компонентов вывода. Формы редактирования элемента или списка элементов. Редактирование настроек.

На таких цифрах должна быть ajax с отдельным редактирования каждого поля, а не как щяс в редактировании инфоблока вываливаться стандартная форма с 100к+ полей, ведь на каждое свойство десяток input. Это все равно что бы если свойств не было и мы редактировали бы абсолютно все товары каталога на одной единственной странице. Нужна оптимизация и переделка всех форм инфоблока. Плюс нужно оптимизировать выборки в компонентах, не выхватывать все 10к свойств на каждый товар, а только нужные. В АПИ скорее всего надо еще оптимизировать некоторые выборки, например в индексации поиском.

И тогда будет все летать на одном инфоблоке. База, а точнее её схема, к данной проблеме не имеет отношения. Можно и нужно схему/архитектуру улучшить, но это не связанная задача.

Привязка свойств к разделу есть и это нечего не дает и не теряет в скорости текущих таблиц. Лиш уменьшает выборки в определенных сценариях и некоторые формы.

---

Да, архитектура "кривая", но это в наше время, хоть проблема напрямую не в ней. Когда её задумывали и реализовали все летало и таких проблем не было. Новые реалии требуют новую архитектуру.

---

Отдельное замечание:
Добавление новых инфоблоков одного каталога не требует редактирования кода. А если требует то это бага от разраба. Не каких "мы подписываемся на вечную доработку" и не каких "пляски с бубном". Я даю гарантию два года на свои разработки/интеграции и мне не выгодно что бы постоянно дергали по таким пустякам.
Добавление разделов в выгрузку, ну это уж очень элементарно, хоть пару кнопок то клацнуть то можно же. Или вы как то не так настраиваете структуру разделов.

---

"Почему тогда 99% решений из маркетплейса", ну тут я боюсь обидеть других разработчиков, и схватить бан, Но почти все вопросы/проблемы такого типа один ответ: "Потому, что 99% решений в маркетплейса откровенный гов**код" и задуманны чисто зарабатывать с продажи, а не работы/поддержки. Продал и забыл.

Эти "решения" крайне плохо тестируються, установка может убить сайт, крайне узкоспециализированы, крайне конфликты между собой, крайне неудобны для дороботок, крайне криво обновляються, зарание крайне устарели, почти никакой документации, крайне ленивый суппорт. Любой тикет начинаеться с "Дайте админские доступы в битрикс, в хостинг, в билинг/банкинг или в связанные с решением сервисы", и без доступов вообще отказывают в поддержке. Может для кого-то это нормально, а я считаю это дно, от которого нужно со временем избавляться. Возможности зделать возврата нету. Штрафов или каких то санкций недобросовесным разрабам нету. Вот и сформировался такой бардак. Есть конечно же реально адекватные и афигенные модули(значительная часть сделана бескорыстными людьми бесплатно), но их по штучно и можно перечислить. Постепенно будет развиваться рынок, введут средства тестирования, более строгую политику. А пока так.

И снова же "решения" не связанны с проблемой данной ветки и они не должны их решать.

Плюс, по идее большенство "решений" должны спокойно работать с каталогом на множетсве инфоблоков. Просто корявые "мастер настройки" не продуман или демо данные такие. А так думаю готовые решения спокойно и быстро дорабатываються для конкретно данной функции.

В админке штатные CSV и XML. Через маркетплейс ексель, может что-то еще.

https://dev.1c-bitrix.ru/user_help/content/iblock/import/import_xml.php
https://dev.1c-bitrix.ru/user_help/content/iblock/import/import_csv.php
https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=42&CHAPTER_ID=05222

http://marketplace.1c-bitrix.ru/search/?q=%C8%EC%EF%EE%F0%F2

http://lmgtfy.com/?q=%D0%91%D0%B8%D1%82%D1%80%D0%B8%D0%BA%D1%81+%D0%B8%D0%BC%D0­%BF%D0%BE%D1%80%D1%82

Я, как разраб, пишу импорт любого формата, что есть элементарщина.

ТП вроде все ясно написало. Нужно отредактировать файл шаблона и перенести задание заголовков в некешируемую область. Придельно ясно обьяснили. Ясней только готовые файлы дать. Через галочки админке не поправить. "Самому", я бы не рекомендовал бы делать, можно сильно накосячить.

Для разраба это элементарный баг и вообще то чиниться в рамках гарантийного обслуживания.

Если все же лезете, то сделайте бекап и научитесь его разворачивать(на отдельном хосте). Это нужно в любом случае, даже вне контекста этой ошибки.

При успешном обновлении потеря данных не задумана Если что то потерялось, то это ошибка которую надо исправлять и повторить обновление.

Зарание проблему вижу только в отдельном этапе "конвертация магазина". Могут побиться скидки, свойства заказов и почти наверника адреса доставки. С 1с обменом могут быть засады.

Плюс возможно ваш проект еще нужно конвертировать в УТФ8. Это не обязательно, но я бы сделал.

Вы можете купить продление, даже если обновление сайта невозможно или нецелесообразно. Просто используйте тот жей ключ при новой установке. Сначала продлили, потом установили.

Обновить сайт можно, но не без проблем. Зарание сложно сказать что имеено, тем более не зная что за сайт.
На вскидку нужно будет "конвертировать" магазин, обновить пхп на хостинге. Возможно в шаблонах или доработках есть код не работающий в новых версиях битрикса/пхп.

Можете скопировать сайт на отдельный хостинг/домен и там заниматься обновлением/отладкой. Потом просто заменить старый сайт на обновленный.

Техподдержка битрикса может поставить обновление, если дадите доступ, но не станет глобально исправлять все баги шаблонов и дороботок. Зависет от обьема таковых.

Типового веб/битрикс инструмента для визуализации занимаемого места пока не втречал. Разве что файловый менеджер в панели хостинга.

Утечка свободного места может быть по самым разным причинам.

Во-первых посмотрите занимаемое место на диске для самих файлов. Бывает что файлы занимают мало, а база много. Обычно это гиганский журнал или мусор, который по какой то причине не зачистился агентами. Если это ваш случай, то смотрите какая именно таблица растет и гуглите ей название. Как правило это типовые ошибки которые уже давно все решили.

Подход к отладке занимаемого места довольно элементарный. Берете файловый менеджер или консоль/терминал (что Вам удобней) и смотрете какие именно файлы и папки сколько занимают. Например, нашли кучу пдфников, которые у вас на сайте не где не используються, дальше выясняете кто и зачем туда их залил и нужны ли они там. Как я за вас это определю?

Бывает что стороние модули или просто скрипты дороботок генерят логи и не умеют их чистить. Запросто может быть один тесктовый файл логов на пять гигов.

Возможно делали вручную экспорт и не почистили.

Если утечка в "/upload/medialibrary/" или "/upload/iblock/" или "/upload/uf/", то чистите через админку, в соотвествующих разделах. Напрямую эти файлы трогать нельзя.

"/upload/resize_cache" и "/upload/tmp" в резервную копию не идут. Но если утечка в "/upload/resize_cache/", то это шаблоны компонентов надо проверять/оптимизировать.
Впринципе можно напрямую удалить содержимое "/upload/resize_cache/" и сбросить кеш в админке. Но это временное решение, на час, на день, на месяц, а может на год. Зависет от вашего проекта.

Да, грохает если удалять через апи, но вот если поменялись параметры генерации миниатюр, или водянка другая, то старье не чиститься, так как оригинал на месте. Но в таком случае это уже этап разработки/внедрение и делаеться разрабом, а не юзером. Плюс стороние модули могут что то этакое генерить, что не почиститься автоматом..

Силами програмистов битрикса вопрос решен заочно, в upload не создаеться лишних файлов/мусора, кроме может быть папки "tmp" и "resize_cache".
Все что создано в upload битриксом завязано на админку и удаляеться связанными обьектами(инфоблоки, галереи, юзеры, заказы, тд). Напрямую из папки Вам удалять нечего не нужно. То есть например у вас кончилось место на хостинге, так как Ваш фотограф залил фотки по 20 метров, тогда Вы в админке можете найти эти фотки, удалить и залить вместо них фотки поменьше. Не трогая папку upload.

Все "лишнии файлы" созданы доработками или вручную. Их автоматика не почистит, так как нету четкого критерия для определения подобных файлов. Если лишние файлы созданы доработками, то обращайтесь к ТП разработчика этих доработок. Если лишнии файлы созданы вручную, то это ваша отвественность за ними следить и чистить в случае необходимости.

Я бы только для разрабов битрикса предложил бы добавить средства аналитики и отчеты для хранилища. Плюс тесты для проверки наличия файлов и потерянных/незадействованных записей из за кривого кода сторонних разрабов.

100-200 инфоблоков тоже перебор, я скорей говорил о 10, ну максимум 20. 100+ инфоблоков тоже ошибка.

Оптимизация выборки в catalog.section это мелочь, еще нужно страницу товар переделать, плюс фильтра, плюс сравнение. Плюс админка, редактирование товара на 8к свойств тоже надо переделывать, плюс редактирование в таблице. Производительность публички хорошо, но об админке то не надо забывать.
Плюс обмен с 1с. Плюс возможные экспорты во внешнии базы, маркет и мерчант например.

Делать свои компоненты это точно не хороший тон, тупо делать ради того что бы было "свое" бессмысленно. После здачи проекта код не обновляеться и менее надежен чем типовой обновляймый и проверенный тестерами команды битрикса. Максимум что вы можете получить так это только придельную оптимизацию для узко-специализированного решения. На типовых компонентах для разделов новости/статьи/каталог/контакты/справка/тд заметного прироста не будет. А код может сдохнуть после обновления ядра или хостинга.
Свой компонент и/или свой модуль нужен на не типовых задачах, типа генерации медиа файлов (jpg, pdf, mp3, тд), выборки не типовых сущностей, формы и виджеты, различные конструкторы/интерактивы и тд. А новости и каталог это самое типовое решение, практически все можно дописать в шаблоне.

Да, битрикс не расчитан на такие цифры в таких сценариях. Да, это можно исправить поправив ядро. Можете предложить свои правки разрабам. Но уверен, что они сами прекрасно все знают. Пока что имеем, то что имеем, и 8к свойств в одном инфоблоке это не решение. Когда то может доработают ядро и можно будет смело столько забивать, но не сейчас.

Модерацию перечня свойств контенщик полюбому делает как минимум для умного фильтра.
Для сценария с одним инфоблоком, я завожу белый список свойств, с интерфейсом в админке. В нем указываються перечень свойств для фильтрации и редактирования, только они и импортируються в инфоблок. все остальное у меня храниться в отдельной таблице и подгружаеться в шаблоне. За одно тут же расширенный функционал по валидации/нормализации/обьединения/подмены/парсинга/тд значений свойств. Если нужно редактируемое свойство, то оно вноситься контенщиком в белый список и следующей синхронизацией автоматом создаеться и заполняеться с сответсвующих баз(1с, яндекс маркет, прайсы, апи дестрибьютеров).

Ну не нужны 8к свойств в инфоблоке. Минимум 90% таких свойств, просто справка и дубликаты с путаницей написания, и их можно хранить более дешевыми методами.

Так выходит минимальное количество правок, максимальная производительность публички и админки, масштабируемость базы, целое ядро.

Кеш может быть сброшен автоматом, но не понятно кеш чего у вас не сбрасываеться.

Если кеш шаблонов компонентов, то проверьте параметры кеширования, кеш автоматом сбрасываеться при изменениях в инфоблоке или тех данных что у вас закешированы.
Если вы редактируете шаблоны и хотите увидеть результат правок, то кеш автоматом не сброситься, нужно сбрасывать вручную в панели для текущей странице или весь.
Были жалобы на кеш собранной статики css/js. Но у меня не воиспроизводиться ошибка.

Удалять именно эти файлы можно, но обычно это делаеться только в случае аварии. И желательно настроить memcached.

Не делал, но

1) Думаю это можно сделать написав небольшую проверку перед вызовом компонента и меняя параметры компонента с чпу и без в зависемости от запроса.

2) Можно было бы создать отдельный файл и настроить машрутизацию запросов на него. То есть /news/index.php без чпу, в /news/index_sef.php с чпу.

Оба варианта на мое усмотрение было бы глупостью. Правильно делать одну каноническую ссылку и переадресации на каноническую, если нужны рабочии другие шаблоны.

Чисто через виз редактор наверно нельзя.

Вы пробывали хранить часть свойств(не фильтруемых) одной строкой как текстовое описание ? У меня экономия на этом до 10к(95%) свойств.

В \Bitrix\Main\Entity\DataManager нету множественного добавления/обновления/удаления строк(да, очень хотелось бы). Предположу что это сделано, что бы могли отрабатывать обработчики событий на каждую строку. Похоже разрабы так и задумывали, помещать add в цикл.

Ну это конечно трэш, угар и содомия. Вместо того, что бы разбить каталог на раздельные инфоблоки Вы решили переписать двиг.
Вам понадобиться свои компоненты каталога, своя админка и свой обмен. Это жесть. И самое простое это обмен. При таком обьеме правок возможно Вам не следовало покупать битрикс. Если прям Вам так надо, что бы все было в одном инфоблоке, то просто вынесите свойства в свои таблицы. 60к товаров это небольшое количество, тут у Вас не будет проблем. Вы слишком усложняете элементарные вещи.

Сложно делать вывод не видя полной картины, но если "/Articles-network.html" правильная ссылка, то ваш пример должен вернуть 404 статус.

В примере указана дериктория "Articles-network.html%5burl%5d%5b" и в ней файл "no-text4709990402860230257". Такого явно у Вас нету, и если по такому запросу выдает 200 статус, то у Вас ошибка в обработке ссылок битриксом. Нужно смотреть и править код. Может достаточно правок настроек компонентов, но мне сложновато заочно что то утверждать.

Да, кстате, вот что это может быть. У меня, сколько вообще работал с битриксом, вечно сложности с штатным генератором карты сайта, то он кодировку путает, то забивает 8мб пробелов, то дохнет на пол пути, то еще что то. Думал я косячу с конфигами, а нет, у клиентов и других разрабов тоже самое.
Возможно у вас битая карта сайта, это могло проявиться в такой манере как у вас.

Это конечно можно, только какой из этого прок? Гет парметров довольно много, например utm метки надо учитывать, плюс админка, плюс ajax которые не Вы писали . Пока что не встречал, что бы кто то замарачивался. Сео студии сопровождающие мои проекты такой рекомендации не давали.

Повторюсь, эти ссылки где-то опубликованы, то есть где то есть вебстраницы, где эти ссылки выводяться и робот их увидел. В экзотических случаях это могла быть карта сайта или даже вердовские файлы или пдф. Главное что бы эти левые ссылки были не на вашем сайте.

Теоретически сайт не несет отвественности за публикции на чужих ресурсах и не может быть штрафных санкций в виде просадок позиций.

Гм, понятно. Но что бы подключать какой механизм фильтрации, он должен из чего то делать вывод, будь то проактивный фильтр или типа того. Кроме ссылки анализировать нечего. Готовые решения могут иметь только черный список с масками и регулярками для распространненых хаков.

Ну а как Вы вообще представляете отфильтровать рандомный запрос типа "?битри"  ?
Тут единственный критерий только то, что гет параметр без значения. Ну можно приплести еще кирилицу в ссылке. Но за глобальное единое решение не сойдет.

----
Как правило я фильтрую вообще все гет параметры и пхп скрипты
Disallow: /*?
Disallow: /*.php

и белым списком перечисляю что можно индексировать, паджинация, сортировка и тд
Allow: *?PAGEN_1=*
Disallow: *?PAGEN_1=*&

Потом указываю canonical для всех страниц.
Также, в htaccess переадресую не чпу запросы.
Так мусор в поиске не появиться, а то что ходит робот или народ так это роли не играет. не ддос все таки.

В robots.txt можно задавать шаблоны ссылок для исключения. Например
Disallow: /*no-text*
Если Вы хотите, что бы страницы по подобным запросам были не доступны, то можно в htaccess задать.
Если у Вас более сложный критерий отбора чем шаблон ссылок, то в init.php можно добавить код проверяющий Ваши критерии.

Если эти по этим ссылкам пришел робот, значит эти ссылки где то опубликованы, на вашем или на чужом сайте. Отследить где они опубликованы вы можете через обычный поиск и/или через кабинет вебмастера поискового робота.
Убрать левые ссылки(дубликаты) можно через robots.txt http://robotstxt.org.ru/ . Гуглите руководства, это элементарный инструмент. Главное после правок протестируйте что бы не отфильтровали, то чего не надо было.

Грузить свойства без нуменклатуры не выйдет. Мне даже в голову не приходило пытаться

С картинками есть такая беда что, полный обмен убивает все старые картинки и импортирует новые. Даже если они одинаковы.  То есть вы грузите 50к картинок, сначала 50к файлов удалят по штучно из базы и ФС, потом 50к по штучно внесут и скопируют. Разрабы обещали исправить баг, но не видел еще решения.
Ресайз рекомендую вообще вырубить на всех этапах обмена. Сам ресайз(кроп/водянка) должен быть в шаблоне каталога, что бы сбалансировать нагрузку и менять параметры в одном месте.

Раз у вас такой ресурс, то гараздо быстрей сделать свой xml/csv/json экспорт/импорт в своем формате с проверкой актуальности. Это даже в какой то степени элементарно

Ну да тут засада с документацией, она не очень то отображает жизнь.

У вас две проблемы. Как хранить контент для быстрого сайта и как настроить обмен для быстрого обмена.
Парсер обмена битрикса крайне медленный (мотивируеться разрабами как универсальный и под все виды хостинга или типа того).

Во первых на ваших обьемах я убираю из обмена все свойства и картинки, а это уже десятикратный прирост в скорости обмена.
На текущем проекте полный обмен 60к товаров идет где то час на хостинге за 1219. Мой скрипт импорта на 60к позиций со схожим обьемом инфы( с ценами и остатками ) импортировался из xml за 4 минуты, а json где то 40сек.
Весь контент у меня или забиваеться на сайте, или импортируеться с других баз или из 1с но уже отдельным профилем обмена.

Ваше железо реально дикое. На таком я выгружал где то 10к позиций примерно за минуту или две. Хотя с картинками там уже полчаса.

Отдельный вопрос как это дело хранить на сайте, 4к свойств в одном инфоблоке это ж*па. Техники решения уже перечислял. Снижайте хотя бы до 500 на один инфоблок.
Сейчас 60к товаров, 500свойств, умный фильтр, 100 мс(0.1 сек) выполнение любой страницы каталога, vps 1219руб.

Тормаза на сайте также могут быть не связаны со свойствами. Могут быть медленные шаблоны или плохо настроенны компоненты.

Что у Вас за проблема не определю. Но из опыта

Цент на разных хостингах, может серьезно отличаться пакетами, и сборка может не совпадать с дестрибутивами из официального репозитария. А в скрипте установки окружения нету проверки установленны ли нужные пакеты (по крайне мере не всех). По логам как правило видно чего не хватает.
Сборка с предустановленным окружением от хостинга, именуемая "Вебокружение" или "Битрикс окружение" или "CentOS 7 + BitrixEnv" у меня не когда не работает. На пяти разных хостингах пробывал такую "ОС" и не одна не рабочая. Вебокружение нужно ставить вручную на чистый цент.
Перед уставкой окружения делаю обновление и проверку/доустановку пропущенных пакетов.

В плане количества свойств в инфоблоках 2.0 все еще хуже. Там под каждое свойство выделяеться отдельная колонка таблицы и следственно количество колонок ограничено самим mysql https://dev.mysql.com/doc/refman/5.5/en/column-count-limit.html

К сожелению битрикс не может посчитать реальное ограничение на количество колонок(лимит количества свойств) для инфоблоков 2.0, и ошибка косвенно говорит что миграция свойств была не успешной. Думаю ваши 8000 свойств не как не влезят

У вас вопрос не производительности, а архитектуры хранения данных в целом. Хранение 8000 свойств в одном инфоблоке любой версии инфоблока это ошибка.