Замер производительности в админке Битрикса
Производительность: 8.191
далее на сервере
yum install php-pecl-zendopcache
httpd restart
Повтор замера производительности
Производительность: 38.54
вот такой коротки пост 🙂

PS
Вообще, конечно уже пора на 7ю виртуалку Битрикса переходить, там PHP7 с включенным Opcache по умолчанию…

PSS
Ещё 5 новых фарма-ломов нашел
http://gefestholding.ru/?see=sialis_dejstvuyushhee_veshhestvo.php
http://hl-labsural.ru/?see=analogi_viagry_kupit.php
http://inblu.ru/?see=analog_na_levitra.php
http://litsa-kulturi.ru/?see=55_levitra.php
http://krasula-promo.ru/?see=alkogol_i_levitra.php
Вывод — доры на пирогах ещё живы!

Итак, вчера я обнаружил, что почта с сайтов на моём сервере (виртуальная машина Битрикс) не доходит на почтовые сервера Google Mail — …@gmail.com
Скрипт проверки почты функцией PHP mail() проблем не выявил — функция отрабатывает корректно, но почта не уходит — видимо проблема уже на другом уровне.
В почтовых логах обнаруживаем ругательную запись

…… SMTP error from remote mail server after pipelined end of data: 550-5.7.1 [91.227.68.223 12] Our system has detected that this message is\n550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,\n550-5.7.1 this message has been blocked. Please visit\n550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError\n550 5.7.1 for more information. g191si2693352lfe.246 — gsmtp

Собственно, идём по рекомендованному адресу, где обнаруживаем рекомендации по настройке почты, а так же гугловский сервис postmaster для просмотра возможных почтовых проблем.
В постмастере я добавил домен от которого идёт отправка почты с моего сервера — пока идёт сбор данных, информации нет (как появится — добавлю информацию ниже).
А пока остановимся на рекомендациях по настройке почты: PTR, SPF, DKIM, DMARC
Что касается PTR и SPF — главные базовые настройки почты, о настройке которых я ранее уже писал — настройка почты
Если кратко PTR — DNS настройка соответствия IP адреса и домена — запрос по домену, должен возвращать IP и наоборот, запрос IP должен соответствовать домену.
SPF — DNS настройка правил откуда позволено отправлять почту.
Эти настройки я сделал ранее, но видимо этого недостаточно для гугловского почтовика, соответственно, для полноты картины настроим цифровую подпись DKIM и правил DMARC.
Для этого есть отличный мануал, которым я и воспользовался.
Если кратко: устанавливаем exim и переключаем MTA на него, генерируем ключи, прописываем публичный ключ в DNS, настраиваем exim на подпись писем приватным ключем.
Далее, смотрим оригинал письма (на Яндексе т.к. на гугл так и не принимает мои письма)

Всё хорошо — SPF и DKIM проверки пройдены!
Для включения политики DMARC добавляем TXT запись «v=DMARC1; p=none; rua=mailto:postmaster@gthack.ru» — говорящую о том, что никаких действий с подозрительными письмами не предпринимать, отчёт направлять на адрес домена postmaster@gthack.ru (предварительно обработку входящей почты с данного домена я делегировал почтовым серверам Яндекса, через привязку домена к Яндексу).

Итак, всё что можно было настроить я настроил, но почту Гугл всё равно не берёт! 🙁

Далее, решил я снова покопаться в логах и обнаружил, что почту не берёт не только Гугл, но и некоторые другие почтовые сервера, так же ссылаясь на странички для разъяснения ситуации.
Собственно, по характеру ссылок я понял, что айпишник «залетел» в публичные блэклисты по спаму.

Для поиска спамера, я воспользовался возможность логировать отправителя на уровне php — вредоносных скриптов не обнаружил, отправка шла штатным Джумловским скрпиптом phpmailer.php доменов которые я по дружбе захостил на своём сервере (наука на будущее — джумла — источник всех проблем) соответственно нужно запрещать рассылку в самой Джумле (об этом напишу позже).

Ну а для исключения из спам листов, следуем по ссылкам из логов и заполняем нужные формы:

http://postmaster.comcast.net/smtp-error-codes.php#BL000010
для исключения из листа заполняем форму
http://postmaster.comcast.net/block-removal-request.html

для исключения из блэклиста сервис Cloudmark Sender Intelligence (CSI)
заполняем форму
https://csi.cloudmark.com/en/reset/?ip=91.227.68.223

Уфф, ну вроде сделал всё что нужно, жду результат… (отпишу позже)

PS // добавлено спустя несколько дней
Так Гугла меня и не пускает 🙁
Только что обнаружил интересный сервис Наличие IP в СПАМ базах

Будем отписываться, далее отпишу

PS // добавлено спустя несколько дней
Через несколько дней после отписки в спам сервисах, гугл соблаговолил принимать мою почту.
«Просмотр оригинала» в интерфейсе GMail наглядно демонстрирует работу всех подключенных выше технологий.

В продолжении предыдущего поста о всяческих обновлениях …
Итак, довольно прилично подзаебавшись с обновой на PHP 5.6 я решил не махать так шашкой — а реализовать задуманное более степенно.
То есть установить PHP 7.0.9 на дублирующий сокет и потихоньку тестировать и настраивать (как выяснилось позже это была очень правильная мысль).
За основу была взята статья но не всё пошло так гладко — пришлось допиливать.

PHP 5.6 у меня уже был установлен и в режиме php-fpm так же использовался.
Сам phpbrew я установил, так же под новым юзером, и чтобы не путаться все пути оставил такие же как в статье.
Скрипт запуска у меня никак не вставал, поэтому я переделал из запуска существующего php-fpm изменив настройки на конфиги, пид и лок файлы
В www.conf я поменял и файл сокет (было listen=/tmp/php-fpm.sock стало listen=/tmp/php7-fpm.sock)

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

По идее модули ставятся без проблем командой phpbrew ext install [module name]

НО тут нужно чётко понимать, что phpbrew использует при компиляции исходники — как оказалось у меня для необходимых модулей их небыло

Модуль для MYSQL ставим как в статье!

phpbrew ext install https://github.com/php/pecl-database-mysql.git

Подробности — как обычно ищем в логах установки (где логи пишется в процессе установки), например для курла у меня логи был тут
/opt/phpbrew/.phpbrew/build/php-7.0.9/ext/curl/build.log

вот список того, что мне пришлось доустановить для компиляции phpbrew некоторых модулей
yum install libxml2
yum install libxml2-devel
yum install libxslt-devel
yum install libmcrypt-devel

а вот с установкой curl пришлось поискать подходящий репозиторий, вот инструкция
1) create a new file /etc/yum.repos.d/city-fan.repo
2) Paste the following contents:
[CityFan]
name=City Fan Repo
baseurl=http://www.city-fan.org/ftp/contrib/yum-repo/rhel$releasever/$basearch/
enabled=1
gpgcheck=0
3) type:
yum clean all
yum install curl
4) And it’s done.
yum install curl-devel

phpbrew ext install curl

после всех инсталяций не забываем дёргать сервис
service php7-fpm restart (название — это имя вашего переделанного файла запуска в init.d)
так же для того чтобы сервис стартовал сам- нужно сделать симлинки в rc3.d

Ещё в www.conf для php-fpm необходимо прописать имя юзера и группы под кем запускается php7-fpm (без этого у меня не работало).
listen.owner=bitrix
listen.group=bitrix
listen.mode=666

Об одном баге (а точнее особенности) — напишу отдельно, т.к. меня она повергла в небольшой шок 🙂
После включения Zend Opcode Cache (у меня это был последний этап) — решил я затестировать работу на простых скриптах.
echo time(); — вывело время
echo «abc «.time(); — снова вывело время (причём в реалтайме), но без строки abc !!!
То есть динамический вывод работал, а то что поменялось практически в статике — нет (хотя этот тоже динамика, но без функций).
В общем немного потупив, дошло, что трабла в оптимизаторе, а точнее в настройке параметра opcache.revalidate_freq=60
Т.е. после изменения файла должно пройти 60 секунд, прежде чем интерпретатор его обновит в кэше (если конечно он был кэширован ранее).
На нужный домен (где идёт разработка) можно в php.ini секцией задать свои значения

[HOST=dev.site.com]
opcache.revalidate_freq = 0

Так же смотрим на удалённые функции из интерпретатора https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 заменяем их правильными аналогами

Вроде на этом вроде всё!

P.S.
Чуток я разочаровался по приросту быстродействию и потреблению ресурсов, но оно для моего проекта объяснимо — слишком он простой 🙂

Собственно, после того, как на Битриксовой виртуалке отказалась ставится Joomla 3 — понял, что тянуть с обновлениями уже дальше нельзя!
Тут большинство скажет, касательно обновлений — нужно делать всё перманентно и вовремя — согласен на все 100% !
Но как обычно — с временем туговато, а последствия обновлений как всегда непредсказуемы. Да и не забываем притчу «солнце всходит и заходит — не трогай, пусть работает» 🙂

Итак, имеем битриксовую виртуалку с довольно устаревшей CentOs 5.8 (со всеми пакетами) и PHP 5.3.3 на борту (bitrix.env 4.0.2)

Перелопатил много инфы, кратко решение вопроса: (как делал я)
* полный бэкап всей виртуалки
* внутри — полный бэкап /etc/ — при обновах старые конфиги переименовываются и т.п…
* обновляем систему (yum update или в меню битрикса system update — одно и тоже)
* добавляем remi репозиторий
Centos 6
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
После установки пакета нужной версии репозитория, у Вас появится соответствующий файл: /etc/yum.repos.d/remi.repo
Теперь необходимо включить нужную версию PHP. Для этого редактируем /etc/yum.repos.d/remi.repo.
Для обновления PHP до 5.6 достаточно установить enabled=1 в главной секции [remi].

После чего обновляем bitrix.env до 5й версии через меню битрикса (иначе этот пакет будет мешать обновиться PHP)
Далее yum update и вуаля имеем PHP 5.6.24

Теперь к самому вкусному — грабли перехода
С повышением версии PHP куча фукнций стали устаревшими, кое какие вообще прекратили своё существование — куча сайтов у меня пришли в непотребный или полностью нерабочий вид.

Первое — старые версии Джумлы (и не только), портянка предупреждений — просто убираю вывод ошибок в .htaccess (либо как вариатн настроить error_reporting — убрать депрекатед и предупреждения)
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off

Второе — при апдейте слетели подключаемые модули, соответственно валят ошибки
Fatal error: Call to undefined function mysqli_init() in
Fatal error: Call to undefined function curl_init() in
и т.д. и т.п

Идём в /etc/php.d/ — переименовываем подключения (убираем .disabled в файлах) — подключаются *.ini файлы после чего рестартим аппач

Ещё фишка — передача амперсанта в функции. Во всех вызовах фукнций function(&$variable) — апмерсант убираем!

Вроде всё — всем успехов!

P.S. Почитал инфу о PHP7 — поставил на виртуалку одновременно с 5.6 в режиме php-fpm на другой сокет.
Пока эксперементирую тестирую (тут ещё жестче с переходом). Как будет результат — отпишу.

https://marketplace.1c-bitrix.ru/solutions/scrollup.bxd/

Для установки решения на демо сайт — сначала ставим его на сайт с лицензией, далее копируем модуль в демо сайт — после чего активируем в админке!
Папка модуля /bitrix/modules/scrollup.bxd/

Отличное бесплатное решение для отладки в Битрикс (далее текст с Маркета).

Описание решения
Решение позволяет выводить отладочную информацию в удобном виде.

1. Вывод в виде разворачивающегося дерева с подсветкой элементов, выводом типа и размера элемента.

Для этого достаточно в любом месте кода вызвать функцию __() и передать ей нужную переменную для вывода.
Например: __($arResult);

По-умолчанию, вывод будет происходить до вывода информации всего сайта.

Если второй параметр задать true, то вывод будет там, где вы вызывали: __($arResult, true);

2. Вывод в консоль браузера.

Для вывода в консоль нужно вызвать функцию _c() и передать ей нужные данные для вывода.
Например: _c($arResult);

3. Иногда нужно посмотреть какие-то данные, но вывести их на экран нельзя.
Для этого есть третий параметр у функции __()
Если вызвать функцию, например, вот так: __($arResult, false, true);, то результат сохранится в лог файл. За это отвечает третий параметр.
При вызове функции _l(); будет выводится результат из него в таком же удобном виде дерева. Сохраняется только один последний вызов.

Еще описание в моем блоге: http://olegorestov.ru/this/bitrix_debug_module/

Хотите что-то добавить, изменить или улучшить? https://github.com/ancorp/bitrix-debug
Жду ваших pull реквестов.

Хочу поделиться довольно интересным наблюдением на счёт кэширования в Битриксе!
Собственно, на одном из поддерживаемых мной проектов в менюшке должен появляться новый пункт в зависимости от … (от чего именно не особо важно)
Факт в том, что кэширование об этом не знает 🙂 и пункт не появлялся пока кэш не обновится.
Пришлось кэш вырубить и ради интереса померил я время формирования меню без кэша
bitrix:menu: 0.003 с; Запросов: 1 (0.0004 с)
Довольно быстро!
Иду назад — врубаю кэш, делаю замер — получаю
bitrix:menu: 0.0032 с
обновляю
bitrix:menu: 0.0028 с
со сбросом кэша доходило до
bitrix:menu: 0.0063 с; Запросов: 2 (0.0012 с)

Вывод — для простых компонент, не делающих запросы к БД проще обходиться вообще без кэша (т.к. сам механизм кэширования так же создает какую то минимальную нагрузку).

Ура, наконец-то проверили мой экзамен (почти 10 дней прошло) — жестоко конечно, но я был уверен в результатах!
Хотя сдал не идеально — косячки были … нужно было перепроверить раза на три, время было (я за 2.5 часа управился).
Собственно, сертификатик



Что позволило подтвердить партнерский статус «Сертифицированный партнер»



Ну и ещё один баннер «до кучи» 🙂

Уже 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 (таблица для управляемого кэша, а я все равно весь кэш чистить собрался)
и далее уже ещё раз из панели «очистить весь кэш» — на этот раз кэш нормально очистился, и теперь сайт живёт совсем другой жизнью 🙂

Пришло время подтверждать статус Сертифицированного партнёра 1С-Битрикс, и снова «новинки» от Битрикса.
Теперь нужно не просто онлайн курсы пройти, теперь нужно практически настоящий экзамен на проверку знаний сдать!
В билетах практические задания, на всё выделяется 4 часа
(по мне так это лучше чем подобный же экзамен, но на тестовые вопросы — это была бы полная жесть).
Для понятия «что-почём» в паблик предоставлены первые два билета.
Сдача ведётся «под камерами» 🙂 в виртуальной среде без доступа во всемирную сеть (погуглить не получится).
Ну и … экзамен платный 🙁
Тут всё подробно.
О виртуальной среде подробнее тут.

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