Александр Кулеша написал: Была такая же ситуация, только конечно не 4к свойство но около 1,5к. Вопрос решился просто. Разбили на несколько инфоблоков по соответствующим категориям, Телевизоры, ноуты, телефоны и т.д.
Обычно у товаров есть свойства, которые присущи всем типам товаров. Например, бренд, артикул, доп.фото и т.д. Как вы их разместили, просто повторили все эти свойства во всех инфоблоках?
У php-fpm еще могут быть свои конфиги в /etc/php-fpm.d/ или /etc/opt/remi/ (если из репы Remi) У меня, например, в /etc/opt/remi/php70/php-fpm.d/www.conf задано еще:
Код
php_admin_value[memory_limit] = 1024M
и много чего еще. Наверняка и почту можно туда прописать.
Это однозначно проблема кеша. Кеш не обязательно в компонентах на страницах, кеш может быть и на других функциях, которые выполняются на каждом хите, например, в /bitrix/php_interface/init.php . Если под авторизованным и неавторизованным пользователем одинаково высокое время загрузки, значит кеш компонентов учитывает группы пользователей - эта опция должна использоваться только если у вас разный контент (цены, например) для разных групп пользователей. Полистал несколько страниц на вашем сайте, у вас почему-то очень нестабильное время генерации страниц. При одних запросах 0.15 с, при последующих было 1.5 с и даже 4.5 с. Может быть у вас на хостинге проблемы или на хитах агенты выполняются?
Вы чем замеряете скорость и не путаете ли кеш битрикса и кеш браузера? Может быть вы в браузере смотрите и у вас долго страницы грузятся из-за картинок? Картинки могут быть тяжелые, несколько мб весить и при первом запросе они скачиваются и сохраняются в кеш браузера. При последующих запросах они уже не скачиваются с сайта, а берутся из кеша браузера.
Плохой вариант. Рано или поздно он сделает что-то не так, сайт ляжет, а поиск проблемы займет часы. Зачем работать с незаконченной версткой? Это же вы переделываете свою работу по несколько раз. Или у них такой проект, что верстка все время нуждается в доработке?
Тут скорее не настройки, а использование системных компонентов для каталога, в частности bitrix:catalog со смарт-фильтром. В админке указать свойства инфоблока, участвующие в фильтрации, пересчитать фасетный индекс. Вот, например, на демо-сайте: https://prnt.sc/ha7qks - первичное состояние фильтра https://prnt.sc/ha7r0h - состояние фильтра после изменения цен
А если у вас кастомный компонент для каталога, фильтров и списка товаров, то вам их придется дорабатывать. Без индексов фильтр считается достаточно тяжело, если у вас тысячи товаров и десятки свойств инфоблока для фильтрации. Именно для ускорения этого пересчета и нужны индексы - все возможны пересечения по сути уже рассчитаны в отдельной таблице в БД.
Валентин Семенов написал: это эпичный фейл проектирования битрикс особенно в плане написания кода по работе со свойствами в "неприкасаемом" для адептов ядре
Я пока еще не встречал ни одной задачи, когда требовалось бы изменять ядро. Всегда можно сделать копию компонента или модуля в /local/ или вообще свой модуль написать, который бы реализовывал нужный функционал, в том числе со свойствами инфоблока.
vitaly_keng написал: Нормальный рейт работы программиста по 1С-Битрикс от 500. За 700 р/час - это уже адекватный. За 1000 - хороший профессионал. 1500 - это уже жир, фрилансеры редко такие цены заламывают. Студии от 700 до 2000 р/час, но никто вам не гарантирует, что взяв проект за 2000 р/час они не отдадут его тем же фрилансерам за 500 р/час.
Не стоит забывать, что студия в себестоимость обычно закладывает часы работы менеджеров всех уровней.
Как показывает практика, наличие менеджеров в производственной цепочке не гарантирует ни качество ни соблюдение сроков.
Ну а зачем вы запихнули 4000 свойств в инфоблок? Сотню свойств еще нормально, но тысячи - это всё. Редактировать инфоблок становится нереально. Как вариант часть свойств можно выносить в отдельные сущности, например, в HL. Более продвинутый вариант - писать отдельный модуль с отдельным хранением данных. И хранить можно не в БД, в какой-нибудь NoSQL. А для нормальной работы прикрутить свое управление связанными элементами в инфоблок. Когда вы залезли в ядро - вы убили поддержку системы, как теперь обновления накатывать, они же затрут ваши изменения. Сервак помощнее не поможет.
15 тр - это ну максимум 2-3 дня работы специалиста. Если даже это регион, очень далеко за МКАДом. Скорее всего вам прикрутят какое-то готовое решение, за которое, кстати, вам наверняка придется еще сверху оплатить. Ну или потом еще денег попросят и окажется, что вы 15 тр заплатили только за установку битрикса. В общем, нереальная сумма.
Нормальный рейт работы программиста по 1С-Битрикс от 500. За 700 р/час - это уже адекватный. За 1000 - хороший профессионал. 1500 - это уже жир, фрилансеры редко такие цены заламывают. Студии от 700 до 2000 р/час, но никто вам не гарантирует, что взяв проект за 2000 р/час они не отдадут его тем же фрилансерам за 500 р/час.
Объемы по реализации сайта - опять же смотря что вы хотите. Просто всё установить и запустить - это 1 день обычно. Но вряд ли вам нужен такой результат. Обычно 30 человеко-дней на запуск нормального сайта и потом еще поддержка, развитие, вылавливание и решение проблем. Интернет-магазины с оборотами в несколько миллионов уже вполне могут себе позволить держать своего программиста в штате - это дешевле и быстрее, чем студии.
Как получить больше битрикс попугаев производительности?, Столкнулся с тем что на разных хостингах и VDS скорость сайта не велика и по производительности я получаю лишь 30 - 40 , хотя по параметрам сервера должен бы видеть больше
Железо у вас нормальное, скорее всего проблема в скриптах и скорее всего каких-то кастомных. Особенно учитывая жалобы хостера на нагрузку в БД. Если у вас криво реализованы алгоритмы, то никакое железо вас не спасет. Даже если сайт будет жить, то при пиковых нагрузках может умирать. В первую очередь посмотрите init.php, наверняка на каждом хите подключается куча ненужной ерунды. Также могут быть кастомные модули, в том числе из маркетплейса, они могут создавать лишнюю нагрузку. Если у вас в init.php куча всякого непонятного кода, попробуйте замерить попугаев сначала, потом в init.php в начале пропишите return; чтобы код в нем не выполнялся вообще, потом замерьте попугаев снова. Если разница в попугаях существенная, значит проблема действительно в кастомных кодах. Часто проблемы бывают еще в компонентах и прямо прописаны на страницах сайта - смотря на сколько непрофессиональны были разработчики.
Если вам сайт делали всякие "студии", "интеграторы" или "агентства", то скорее всего они делали по принципу "лишь бы работало" и никто не задумывался о производительности, особенно на больших нагрузках. Не удивлюсь, если у вас встречаются страницы с тысячами некешированных запросов к БД.