Неплохо было бы объединять js файлы системы, а то грузятся по одному core_db.js и core_frame_cache.js и т.д.
Мне кажется, что было бы логично убрать принудительное подключение core.js и прочих файлов битриксового JS-фреймворка.
А так это более 200 кило чаще всего неиспользуемого кода.
А так это более 200 кило чаще всего неиспользуемого кода.
Появилась новая хорошая штука InheritedProperty для показа сео-свойств, но ее еще зачем-то добавили в компоненте bitrix:catalog.section.list, из за чего компонент работает непозволительно долго.
Например, вот выбираются 600 разделов (первые 3 уровня вложенности) на сервере для разработок с 512 МБ оперативки и одним процессором, веб-окружение, производиетльность 45.
bitrix:catalog.section.list: 7.402 с; Запросов: 1413 (0.1076 с)
а если в компоненте bitrix:catalog.section.list отключить вызов
то время выполнения значительно уменьшится (почти в 4 раза):
bitrix:catalog.section.list: 2.0896 с; Запросов: 1413 (0.109 с)
хотя число запросов по прежнему пугает, правда, выполняются они быстро, основное время забирает выполнение пхп-кода.
Причем, в подавляющем большинстве случаев наследуемые свойства в bitrix:catalog.section.list нам не понадобятся (достаточно выбрать их только для текущего раздела, а не для всех).
Например, вот выбираются 600 разделов (первые 3 уровня вложенности) на сервере для разработок с 512 МБ оперативки и одним процессором, веб-окружение, производиетльность 45.
bitrix:catalog.section.list: 7.402 с; Запросов: 1413 (0.1076 с)
а если в компоненте bitrix:catalog.section.list отключить вызов
$ipropValues = new \Bitrix\Iblock\InheritedProperty\SectionValues($arSection["IBLOCK_ID"], $arSection["ID"]); $arSection["IPROPERTY_VALUES"] = $ipropValues->getValues(); |
bitrix:catalog.section.list: 2.0896 с; Запросов: 1413 (0.109 с)
хотя число запросов по прежнему пугает, правда, выполняются они быстро, основное время забирает выполнение пхп-кода.
Причем, в подавляющем большинстве случаев наследуемые свойства в bitrix:catalog.section.list нам не понадобятся (достаточно выбрать их только для текущего раздела, а не для всех).
В попапе расширенного редактирования свойств
Нужно добавить такие параметры как тип значения притом именно MySql тип с описанием его, так же не нужно создавать столбец с описанием значения, если галка "Выводить поле для описания значения:" не установлена.
Во первых эти не значительные изменения избавят нас от части проблем которые возникают у людей имеющих большое количество свойств, примеры по ссылке:
А во вторых сами файлы таблиц будут меньше, индексы компактее, запросы будут работать шустрее и т.д.
Нужно добавить такие параметры как тип значения притом именно MySql тип с описанием его, так же не нужно создавать столбец с описанием значения, если галка "Выводить поле для описания значения:" не установлена.
Во первых эти не значительные изменения избавят нас от части проблем которые возникают у людей имеющих большое количество свойств, примеры по ссылке:
А во вторых сами файлы таблиц будут меньше, индексы компактее, запросы будут работать шустрее и т.д.
В поисковых системах говорят о повышении скорости индексации и снижении нагрузки на сервер путем формирования правильных заголовков Last-Modified и If-Modified-Since, цитирую:
Детальное описание проблемы -
Кратко:
При фильтрации по группе, в CUser::GetList сначала делается подзапрос, выбирающий (почти) все записи из таблицы `b_user_group`. В случае, когда пользователей много, запрос начинает очень сильно тормозить. Если добавить несложную проверку на ID пользователя (при его/их указании), то запрос можно сильно оптимизировать.
Соответственно, предлагаю эту оптимизацию провести.
В ТП мне ответили, что это редкий случай и на все такие случаи оптимизаций не напасешься, но эти изменения затронут именно эту конкретную ситуацию - я не вижу у них побочных эффектов, соответственно и причин их не внести не вижу.
Кратко:
При фильтрации по группе, в CUser::GetList сначала делается подзапрос, выбирающий (почти) все записи из таблицы `b_user_group`. В случае, когда пользователей много, запрос начинает очень сильно тормозить. Если добавить несложную проверку на ID пользователя (при его/их указании), то запрос можно сильно оптимизировать.
Соответственно, предлагаю эту оптимизацию провести.
В ТП мне ответили, что это редкий случай и на все такие случаи оптимизаций не напасешься, но эти изменения затронут именно эту конкретную ситуацию - я не вижу у них побочных эффектов, соответственно и причин их не внести не вижу.
Добрый день,
К моему сожалению, пришлось начать работать с битриксом в настоящее время и, после его изучения и ознакомления с ним, хочу сказать некоторые выводы:
1. Разработка системы зашла в тупик
2. Очень нелогичные решения банальных задач, вводящие в заблуждение разработчиков (чего одно меню только стоит)
3. Напрочь отсутствуют стандарты форматирования кода
4. Совершенно отсутствуют общепринятые в мире стандарты написания кода (свой огород, ага?)
5. Много маркетинга - ноль практической части
6. Абсолютное отсутствие какой-либо оптимизации. В коде видно, что написано абы-как лишь бы быстрее и максимально глупым способом (Например для меня было удивлением, что разработчики понятия не имею что такое тип Boolean).
7. Безосновательные утверждения что "в битрикс работают специалисты", вводящие в заблуждение пользователей (на основе пунктов выше)
8. Про системы контроля не искал, но уверен что если и есть, то что-то типа svn с горой костылей
9. Неправильный html вообще - валидация отсутствует, наслушались Лебедева?
В России так плохо с программистами? Некому совсем работать?
Ощущение что разработкой занимаются студенты (что подтверждает обилие кэпс-лока) без опыта работы, знающие исключительно теоретическую часть, которая далека от реальности
Почему любая OpenSource CMS лучше в разы? Не за 2 копейки ж продаются услуги, можно было бы толковых разрабочиков нанять на пару месяцев, да привести в порядок все...
Предложение:
1. Найти людей
2. Переписать с нуля используя php 5 (да-да, php 4 не актуален, уже давно php 5.4 вышел; про отличия 5.3 от 5.2 и 5.2 от 5, тут, думаю, бессмысленно писать, все-равно не услышат)
3. Позиционировать как Bitrix 2.0
4. Написать нормальную документацию на английском языке. При этом все ввести стандарты форматирования исходного кода
6. Познать ООП, MVC (это страшные слова на первый взгляд, после изучения что это такое, становится понятно)
7. Познать принцип "не повторяй!", код повторяется миллион раз
К моему сожалению, пришлось начать работать с битриксом в настоящее время и, после его изучения и ознакомления с ним, хочу сказать некоторые выводы:
1. Разработка системы зашла в тупик
2. Очень нелогичные решения банальных задач, вводящие в заблуждение разработчиков (чего одно меню только стоит)
3. Напрочь отсутствуют стандарты форматирования кода
4. Совершенно отсутствуют общепринятые в мире стандарты написания кода (свой огород, ага?)
5. Много маркетинга - ноль практической части
6. Абсолютное отсутствие какой-либо оптимизации. В коде видно, что написано абы-как лишь бы быстрее и максимально глупым способом (Например для меня было удивлением, что разработчики понятия не имею что такое тип Boolean).
7. Безосновательные утверждения что "в битрикс работают специалисты", вводящие в заблуждение пользователей (на основе пунктов выше)
8. Про системы контроля не искал, но уверен что если и есть, то что-то типа svn с горой костылей
9. Неправильный html вообще - валидация отсутствует, наслушались Лебедева?
В России так плохо с программистами? Некому совсем работать?
Ощущение что разработкой занимаются студенты (что подтверждает обилие кэпс-лока) без опыта работы, знающие исключительно теоретическую часть, которая далека от реальности
Почему любая OpenSource CMS лучше в разы? Не за 2 копейки ж продаются услуги, можно было бы толковых разрабочиков нанять на пару месяцев, да привести в порядок все...
Предложение:
1. Найти людей
2. Переписать с нуля используя php 5 (да-да, php 4 не актуален, уже давно php 5.4 вышел; про отличия 5.3 от 5.2 и 5.2 от 5, тут, думаю, бессмысленно писать, все-равно не услышат)
3. Позиционировать как Bitrix 2.0
4. Написать нормальную документацию на английском языке. При этом все ввести стандарты форматирования исходного кода
6. Познать ООП, MVC (это страшные слова на первый взгляд, после изучения что это такое, становится понятно)
7. Познать принцип "не повторяй!", код повторяется миллион раз
Решение походу трудное получится, но все таки
При нажатии кнопки старт, происходит сканирование системы
Второй шаг список всех компонентов, локализаций, прочих файлов пригодных для удаления
Сканирование подключенных компонентов и по завершению рекомендация какие компаненты из системы можно удалить ибо не используются включая стандартные
Когда выбраны компоненты, предложение по удалению локализаций, когда выбраны для удаления, предложение по удалению прочих неиспользуемых файлов.
Каковы тут алгоритмы фиг его знает нужны, но хорошо бы сделать возможность резервного копирования из коробки перед чисткой и показатели того что было и что получится типа было занято 200 мб останется 150 мб
При нажатии кнопки старт, происходит сканирование системы
Второй шаг список всех компонентов, локализаций, прочих файлов пригодных для удаления
Сканирование подключенных компонентов и по завершению рекомендация какие компаненты из системы можно удалить ибо не используются включая стандартные
Когда выбраны компоненты, предложение по удалению локализаций, когда выбраны для удаления, предложение по удалению прочих неиспользуемых файлов.
Каковы тут алгоритмы фиг его знает нужны, но хорошо бы сделать возможность резервного копирования из коробки перед чисткой и показатели того что было и что получится типа было занято 200 мб останется 150 мб
Чтоб при удаление модуля удалились данные связанные с этим модулем и из таблиц и из директорий сайта и не только модулей но и любых элементов системы, например убираешь поддержку английского с сайта и удаляются все ланг файлы из всех директорий или удаляешь форум и удаляются и все файлы и все таблицы.
Конечно не легко реализовать и идея не нова для битрикс, читал об этом на форуме за 2007 год, но она влияет на производительность сайта хорошо, все таки мы еще не дошли до уровня мгновенного появления любой страницы не взависимости от содержания и размеров и даже достаточно крупные проекты при наличии огромного количества файлов не всегда справляются с некоторыми нагрузками.
Конечно не легко реализовать и идея не нова для битрикс, читал об этом на форуме за 2007 год, но она влияет на производительность сайта хорошо, все таки мы еще не дошли до уровня мгновенного появления любой страницы не взависимости от содержания и размеров и даже достаточно крупные проекты при наличии огромного количества файлов не всегда справляются с некоторыми нагрузками.
Когда открываешь исходники битрикс сайта, то в шапке зачастую можно увидеть вот такую картину
<li nk href="" type="text/css" rel="stylesheet" />
<li nk href="" type="text/css" rel="stylesheet" />
<li nk href="" type="text/css" rel="stylesheet" />
<li nk href="" type="text/css" rel="stylesheet" />
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
v10.0.11