Уже 3й пост за сегодня 🙂 Долго не писал — был занят над проектом, да и в офлайне дела какие то всё появлялись
сейчас чуток освободился — и так сказать «всё что накопилось» …

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

Итак — правим init.php
Публикую чистый код, т.к. всё предельно понято


AddEventHandler('main', 'OnBeforeEventSend', Array('myClass', 'OnBeforeEventSendHander'));
class myClass {
function OnBeforeEventSendHander(&$arFields, &$arTemplate) {
//получим сообщение
$mess = $arTemplate["MESSAGE"];
if(strpos($mess,'#MY_VARIABLE')) {
$arFields['MY_VARIABLE'] = "значение своей переменной, собственно при доступном массиве arFields - можно вытащить, что угодно";
}
}
}


Случай конечно можно сказать уникальный!
Но тем не менее решил я поделиться и таким опытом.

Обращаются ко мне с определённым ТЗ (не имеет отношение к сабжу) … и я в процессе ознакомления с сайтом, замечаю приличные тормоза (до 10 сек) при открытии страниц.
А конктретно — страничка с компонентом видео потока ютуба. Посмотрел код — вызывается компонент step2use:youtube.subscribe.
Поковырял — смысл простой — тащит канал с ютуба, парсит, результат кэширует и выводит.
Ладно, 10 секунд для запроса канала с ютуба я ещё понимаю, но почему при повторномо открытии такие тормоза?
Проверил — кэш компонента включен! Чудеса!
Тут к бабке не ходи — кэш глючит!
Накинул самый простой скрипт для проверки кэша

InitCache(3600, '12356356gt' , '/' )) {
echo "cache";
$res = $cache->GetVars();
$arResult = $res['arResult'];
} elseif ($cache->StartDataCache()) {
echo "no cache";
$arResult = array(1,2,3,4,5);
$cache->EndDataCache(array("arResult"=>$arResult));
}
?>

и тот хоть ты тресни выводит «no cache» — что говорит о том, что кэш не работает!

Далее посмотрел в dbconn.php и .setting.php — кэш настроен на memcashed (кэширование в памяти)
Перенастроил на файловый кеш — скрипт отработал и всё залетало!
Страничка стала генерироваться за 0.2 секунды ! ускорение в 50 раз!

Но всё же решил кэш настроить как и задумано на memcached!
дал рутом
#service restart memcashed
а самого сервиса то и нет! 🙂

Ну далее, всё как в книжке
# yum -y install memcached

настройки я сделал как в статье (чуть увеличил)
в файле /etc/sysconfig/memcached

MAXCONN = «1024» — количество одновременных подключений (по умолчанию 1024) — больше думаю не понадобится
CACHESIZE=»2048″ — объем выделяемой памяти для кеша (по умолчанию 64MB) — я дал 2 гига
USER=»bitrix» — пользователь, от которого будет запущен memcache
OPTIONS=»-t 16 -s /tmp/memcached.sock» — количество потоков и путь к сокету — у меня один домен на сервер, можно и через сокет — быстрее вроде

# /etc/init.d/memcached start
# chkconfig memcached on

ВСЕ залетало!
Страничка с компонентом место 10 секунд стала открываться за 0.1 секунду — т.е. прирост в скорости в 100 раз! 🙂

После экспериментов с кэшами я подумал, что не помешало бы сделаать полную очистку кэша (чтоб все с нуля и в память! и лишнее место на диске почистить)
Запустил чистку и … сервер встал наглухо!
Смотрю top — 99% на mysqld
Поставил mytop — смотрю там удаление из таблицы b_cache_tag с параметром каким то (уже не помню)
Зашел в phpmyadmin — и охренел, таблица b_cache_tag — почти 30 миллионов записей и под 4 гигабайта размером!
Что это за наследие «прошлого» я разбираться не стал — очистил всю табличку
TRUNCATE TABLE b_cache_tag (таблица для управляемого кэша, а я все равно весь кэш чистить собрался)
и далее уже ещё раз из панели «очистить весь кэш» — на этот раз кэш нормально очистился, и теперь сайт живёт совсем другой жизнью 🙂

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

Во первых конечно же необходимо настроить в принципе саму почтовую систему на сервере — я обычно использую MTA Sendmail или Exim
(непосредственно почтовый сервер на виртуальной машине не поднимаю)

PTR проверка

Далее необходимо настроить соответствие IP адреса сервера-отправителя почты, с обратной доменной записью — так называемая PTR проверка.
Для отладки я создаю простенький php скрипт отправляющий почту средствами штатной фукнции mail() себе же на почтовый ящик gmail и смотрю полученное письмо в исходных кодах («Показать оригинал»)
Received: from srv.mydomain.ru (srv.mydomain.ru. [123.123.123.123])

То есть доменное имя сервера отправителя и обратная запись должны совпадать!
Проверяется с консоли windows
nslookup srv.mydomain.ru
получаем IP адрес 123.123.123.123
далее делаем обратный запрос
nslookup 123.123.123.123
должны получить srv.mydomain.ru

Если несоответствие — необходимо настроить прямую и обратную зону DNS!

Чтобы не ждать пока обновится зона (часа 3-4) рекомендую проверить обратную запись linux командой
dig -x 123.123.123.123 @ns.server.ru
Предварительно узнав какие именно NS сервера обслуживают наш домен командой
whois mydomain.ru

SPF проверка
приведу пример из исходных кодов тестового письма отправленного на гугл
Received-SPF: pass (google.com: domain of info@srv.mydomain.ru designates 123.123.123.123 as permitted sender) client-ip=123.123.12.123;

В переводе на русский — SPF проверка пройдена, IP адрес отправителя считается разрешенным.
Для того, чтобы сервер проходил SPF проверку необходимо IP адрес сервера (или домен) внести в SPF запись зоны (это текстовая DNS запись определенного формата)
Например такой записи «v=spf1 +mx +ip4:123.123.123.123» вполне будет достаточно, чтобы пройти SPF проверку

Далее при настройке почты и изучении оригинала письма мне не понравилась сточка генерируемая моим же sendmail
X-Authentication-Warning: srv.mydomain.ru : bitrix set sender to info@mydomain.ru using -f

видите ли пользователь bitrix не является отправителем для домена srv.mydomain.ru!
Добавляю пользователя bitrix в доверенных пользователей для отправки почты в файл /etc/mail/trusted-users и перезапускаю sendmail — всё, ошибка ушла!

Ну и чтобы не было путаницы с доменными именами, hostname серверу я так же присваиваю srv.mydomain.ru
Правим /etc/sysconfig/network на предмет HOSTNAME=srv.mydomain.ru
и чтоб не ребутить для текущей сессии даём команду
hostname srv.mydomain.ru

Всё!
Обычно этого «набора» хватает для того, чтоб письма нормально доходили и не попадали в спам

P.S.
Бывает нужно ещё и цифровую подпись DKIM настроить для верности — мне не приходилось, но могу порекомендовать хорошую статью по настройке почты (в т.ч. dkim)