была у меня в закладках хорошая статейка, а щас вот открыл - а ее нет:( хорошо, хоть у гугла есть сохраненная копия страницы. автор, простите за репост без подписи ...
В веб-окружении Битрикса по-умолчанию стоит msmtp для отправки писем. Если ваш домен привязан к Яндекс.Почте для домена, и вы хотите отправлять почту через реально существующий почтовый ящик с авторизацией, вам придётся внести в файл конфигурации некоторые изменения, чтобы всё работало хорошо.
Файл /home/bitrix/.msmtprc:
account default
logfile /var/log/msmtp.log
host smtp.yandex.ru #(smtp.gmail.com - для гугла) #
port 587 # именно этот порт! #lkz гугля рекомендуют ставить 465, хотя в просторах сети читал, что и 587 подходит ...#
from robot@domain.ru
keepbcc on
auth on
user robot@domain.ru
password <password>
tls on
tls_starttls on # обязательно для Яндекс.ПДД
tls_certcheck off
И не задавайте слишком длинных паролей.
P.S: при работе с GMail вторую строку (tls_starttls) наоборот включать не нужно.
UPDATE 2014-09-08
полный файлик с настройками для gmail:
account default
logfile /var/log/msmtp.log
host smtp.gmail.com
port 587
from user@gmail.com
auth on
user user@gmail.com
password password
tls on
tls_starttls on
tls_certcheck off
keepbcc on
для корректности настройки можно выполнить из сервера команду:
php -r "mail('test@email.com', 'Test', 'Test');"
UPDATE 2014-12-02
Для проверки из сайта, в командную строку можно ввести код:
if (mail("moe_mylo@gmail.com","test subject", "test body","From: otpravitel@bitrix.ru"))
echo "Сообщение передано функции mail, проверьте почту в ящике.";
else
echo "Функция mail не работает, свяжитесь с администрацией хостинга.";
Только email-адресы ставьте ваши
P.P.P.S Перенес инструкцию (вместе с дополнениями) себе на сайт
Настроил через сервер smtp.yandex.ru, почта уходит но почему то если приходит на gmail то попадает в спам, а отправителем стоит EMPTY-FROM конфиг такой
# smtp account configuration for default
account default
logfile /home/bitrix/msmtp_default.log
host smtp.yandex.ru
port 587
from simple@yandex.ru
keepbcc on
auth on
user simple@yandex.ru
password XXXXXXXXX
tls on
tls_starttls on
tls_certcheck off
Часто возникают вопросы производительности проектов на базе "1С-Битрикс", для решения которых нет необходимости прибегать к "экстремальным методам". Чтобы, помочь в решении таких проблем, особенно разработчикам только начинающим работать с "1С-Битрикс", рассмотрим пример оптимизации "некой" страницы информационного сайта. Для этого будем использовать только встроенный в продукт инструментарий.
И так, что мы имеем:
VMBitrix (512M памяти)
инфоблок новостей ~12600, в каждой новости заполнен анонс, детальная информация, название, теги и ряд свойств
страница с 2-мя компонентами news.list, которые выводят два блока новостей (топ 0 - 10 шт и обычные - 10 шт).
топ новости, не должны попадать в обычные
разделение на топ и обычные новости происходит при помощи числового свойства MAIN_NEWS
при выводе новостей проверяется период активности, ежедневно добавляется 5 - 10 новостей
Характерны следующие проблемы:
тяжёлая фильтрация по дате активности
кэширование в период максимальной нагрузки не может полностью закрыть проблему производительности. Так как, обычно в этот же момент происходит довольно частый сброс кэша, после добавления новостей, их изменения или при других событиях (добавление комментариев, оценок и.т.д.). Поэтому необходимо добиться быстрой генерации страницы без использования кэширования.
[spoiler] Фильтр топ новостей:
$arTop = array('PROPERTY_MAIN_NEWS' => 100);
Фильтр обычных новостей
$arNews = array('!PROPERTY_MAIN_NEWS' => 100);
Стартовое время выполнения страницы: топ новости php: 0,0285с. - sql: 0,0085с. новости php: 6,144с. - sql: 6,0927с.
Смотрим какой запрос генерирует основную нагрузку, копируем его в SQL консоль выполняя EXPLAIN.
Видим, что в выбоке из таблицы b_iblock_element задействованно очень много строк. При этом используемый индекс ix_iblock_element_code в данном случае не эффективен. Проанализировав запрос приходим к выводу что основная проблема в данном случае из за проверки периода активности у элемента
(((BE.ACTIVE_TO >= now() OR BE.ACTIVE_TO IS NULL) AND (BE.ACTIVE_FROM <= now() OR BE.ACTIVE_FROM IS NULL)))
В запросе же с выборкой топ новостей проблемы не возникает, из за высокой селективности выборки по свойству MAIN_NEWS. И индексу по числовому свойству в таблице b_iblock_element_property. Чтобы решить данную проблему делаем следующее:
добавляем в фильтр ограничение по времени начала активности '>DATE_ACTIVE_FROM' => ConvertTimeStamp(time() - 2592000), т.к. новости публикуются каждый день и у нас достаточно большой их объем, ограничиваем выборку неким периодом (неделя, месяц)
добавляем в таблицу b_iblock_element индекс
ALTER TABLE b_iblock_element ADD INDEX `ix_custom_iblock_news_date` (`ACTIVE_FROM`,`ACTIVE_TO`);
Время выполнения страницы: топ новости php: 0,0188с. - sql: 0,0029с. новости php: 0,0475с. - sql: 0,0243с. как видим мы достаточно легко получили хороший результат.
Предположим, что по ряду причин используются инфоблоки+, как же будут выглядеть время генерации страницы? Конвертируем инфоблок и смотрим время выполнения:
Также смотрим в SQL консоли explain для самого тяжелого запроса из топ новостей и видим аналогичную проблему, только теперь виной тому отсутствие индекса по свойству MAIN_NEWS. (В первых инфоблоках по числовым значениям строится индекс)
Добавляем индекс
ALTER TABLE b_iblock_element_prop_s33 ADD INDEX `ix_cust_prop155` (`PROPERTY_155`);
И смотрим результат
Как видим и в данном случае добились хорошей производительности.
В качестве итога
Добавлять индексы по дате активности в b_iblock_element надо осторожно. Может быть ситуация в которой данный индекс будет не желательно использовать. В этом случае можно дату начала и окончания активности в виде timestamp продублировать в виде числовых свойств инфоблока и фильтровать по ним.
При добавление своих индексов надо создавать заведомо уникальное имя, чтобы не возникла ситуация при которой может совпасть имя созданного вами индекса и индекса который может быть добавлен через систему обновлений.
В первых инфоблоках уже есть индекс на все числовые свойства, и ID значений свойств списков. Если же вы используете инфоблоки+ то вам надо в ручную проставить индексы на те свойства по которым у вас будет осуществляться выборка
В дальнейшем постараюсь затронуть и другие моменты оптимизации.
SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (7) AND UPPER(BP.CODE)=UPPER('PHONE')
таким образом если мы достаем 20 свойств то получаем 20 запросов к таблице b_iblock_property для одного компонента, а если на странице 5 компонентов то это уже 100 запросов.
Вопрос к разработчикам: Почему бы получение описания свойств внутри одного запроса GetList не объединить в один запрос который получает описание сразу всех нужных свойств?
В тикете 66176 подымался данный вопрос, но предлагалось только кешировать эти запросы что не оптимально.
Что значит "+" это какая-то устаревшая терминология? Обычные инфоблоки, которые в 14 версии не highload, которые как раз в таблицах b_iblock_property, b_iblock
Эта технология называется Инфоблоки 2.0. В документации к Bitrix Framework, в сообщениях форума на сайте компании и в других местах могут встречаться прежние названия технологии: инфоблоки +.
Вначале немного представлюсь. Меня зовут Рыжонин Николай, в "1С-Битрикс" я курирую направление производительности продуктов компании. Если у вас есть вопросы, предложения или пожелания, касающиеся производительности, обращайтесь e-mail: rns@bitrix.ru
Данная тема уже не раз подымалась (например тут), но тем не менее все таки решил опубликовать обобщенное решения для выполнения всех агентов из под cron.
Для начала полностью отключим выполнение агентов на хите. Для этого выполним следующую команду в php консоли.
После этого все агенты и отправка системных событий будут обрабатывается из под cron, раз в 5 минут. Чтобы не увеличивалась очередь отправки почтовых сообщений, советую изменить параметр отвечающий за количество почтовых событий обрабатываемых за раз. Для этого выполняем в php консоли следующую команду
Сделал по инструкции, при ручном запуске файла выдаёт ошибку: PHP Parse error: syntax error, unexpected 'class' (T_CLASS), expecting identifier (T_STRING) or variable (T_VARIABLE) or '{' or '$' in /bitrix/modules/main/lib/loader.php on line 578
Силуянов Александр, Да. Так и будет, потому что с 99% вероятностью Вам нужен не crontab root`а, crontab пользователя под которым установлена система. Чаще всего это bitrix, но может быть что угодно. В зависимости от того как установили. У меня это название сайта. Тогда команда должна выглядеть так: crontab -u <имя_пользователя> -e Где -u - это ключ вызывающий crontab конкретного пользователя -e - это ключ, который говорит о том, что Вы хотите его отредактировать. Если хотите через nano, то должно быть так EDITOR=nano crontab -u <имя_пользователя> -e
На одном своем проекте обнаружил следующую проблему. Время генерации страниц было от 1.3 до 2.4 (причем никаких тяжелых компонентов нет.) Что бы убедиться, что это не мои кривые руки не компоненты, - создал пустой шаблон.
Обнаружил, что даже на пустом шаблоне, 90% нагрузки идет на Эпилог-Ядро
Нагуглил на форумах битрикса подобные вопросы. В частности, эта тема мне помогла. В итоге, удалил я модуль bitrixcloud, и мои страницы теперь отдаются веселей - 0.085 сек.
Калашнов Антон написал: Для этих целей нужно заводить отдельную папку и все тестовые скрипты хранить только в ней.
Нет, для этих целей надо запретить отгрузку каких-либо тестовых скриптов в продуктивную среду. Тестовым скриптам место лишь в тестовой среде.
Если же речь идет о служебных механизмах, то те из них, которые могут быть запущены из терминала, следует располагать выше корневой директории сайта. Те же, что предназначены к запуску из браузера, следует размещать в административной части сайта с соответствующими проверками прав доступа.
Apache — это, по большому счёту, такой рудемент уже. И держится он только потому, что много в мире виртуальных хостингов, на которых .htaccess решает. Ну и всяких специфических расширений к нему куча (если уж случилась ситуация, что такое расширение нужно — тут да, тут без вариантов Apache).
Представим, что мы на собственном сервере, на котором имеются все возможности доступа к конфигурации. Тогда что нам мешает полностью избавиться от Apache в пользу nginx? Мне не помешало ничего
Далее я просто приведу пару подводных камней и путей из обхода, с которыми пришлось столкнуться при переходе.
Собственно, основная проблема только с ЧПУ, с тем, как его настроить. Решается просто:
server {
...
if (!-e $request_filename) {
rewrite ^(.*)$ /bitrix/urlrewrite.php last;
}
location ~ \.php$ {
if (!-f $request_filename) {
rewrite ^(.*)/index.php$ $1/ redirect;
}
...
}
...
}
Далее, наткнулся на ограничение максимального размера заголовка. Возможно, это я такой везучий, но так уж случилось у меня с настройками по умолчанию, поэтому, думаю, может и у других быть. Я решил проблему на уровне всего сервера:
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».