В статье будут рассмотрены темы: — Развитие синтаксиса PHP — Будет дан ответ на аксиому "почему только 5.3, не выше?" и что из нового синтаксиса можно. — Вопрос совместимости, "исторические хвосты"
Мы в данный момент работаем по версии 5.3. Ниже я описываю новые улучшения в 5.4 и 5.5. К сожалению, возможности из этих версий пока использовать НЕЛЬЗЯ. Можно использовать только возможности 5.3.
Важно! Пиши на PHP 5.3! Все вещи, которые доступны выше 5.3 необходимо решать путем создания промежуточных вспомогательных переменных!
Итак, чтобы рассмотреть эту аксиому подробнее, рассмотрим эволюцию синтаксиса PHP, что же появилось в новых версиях (будут рассмотрены не все улучшения, а только вопросы коротких разыменований, и важных в связи с выходом D7).
Сталкивались ли вы с тем, что клиенты используют обновления битрикс как манипулятивный рычаг давления, чтобы спихнуть ошибки предыдущих разработчиков на тех, кто произвел обновление ядра (ядро не модифицировалось предыдущим разработчиком)?
(доводы клиента: до обновления все работало и прочее, верните все как было)
или это классическая ментальная ошибка, когда произошедшие одновременно вещи считают связанными?
или все-таки есть риски и большие при обновлении ядра?
хотя обновления ядра объективно - это ресурс, причем платный.
Чебан Валерий, ну пусть сам нажмет, а если без шуток, то он платит за минимизацию рисков.
Сложно объяснять это только в тех случаях, когда сайт генерирует 10 заказов, когда на сайте 1000 заказов в сутки - все вопросы отпадают, так как ошибка, которая может масштабировать убытки или простой сайта в результате ошибки - это всегда дороже.
Всегда найдется тот, кто сделает дешевле и вообще не учитывает всяких особенностей по предыдущему опыту, так как у него его просто нет. Где-то общался на fb и обсуждали тему сроков запуска интернет-магазина. Все пишут что недели 2 надо, но тут же пишут, что никогда такого не было. 2 недели типа это в идеальном сценарии, которого на их памяти не было практически никогда. Ну и встречный вопрос им - зачем тогда вы вообще озвучиваете сроки в 2 недели если это неправда?
Белокрылов Виталий, мы с вами полностью совпадаем в понимании и рисков и ожиданий клиентов, а эту тему я тут поднял, чтобы кидать на нее ссылку и, возможно, сэкономить собственные силы и время. вам спасибо за развернутые ответы!
PHP Fatal error: ob_end_clean(): Cannot use output buffering in output buffering display handlers in /home/bitrix/ext_www/_____________/bitrix/modules/main/classes/general/main.php on line 3113
SEL ECT `ID`, `IBLOCK_ID`, `NAME` FR OM `b_iblock_element`
WHERE `ID` IN (115, 120, 117, 109, 128) AND `IBLOCK_ID` = 5
ORDER BY FIELD(`ID`, 115, 120, 117, 109, 128);
Успешно запустил свой домашний блог, написанный на bitrix, на версии php7. Версия bitrix – последняя beta. Замерил утилитой ab-тестирования (из комплекта с Апатчем) скорость работы в первом и втором случаях:
Методика тестирования: Меняем версию PHP в настройках апатча и прогоняем тесты ab-утилитой. Также смотрим на время генерации страницы модулем производительности. Ничего особенно, но для ответа на вопрос: а быстрее ли bitrix с php7? и примерно на сколько быстрее?
Usage: ab [options] [http://]hostname[:port]/path
Options are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make at a time
-s timeout Seconds to max. wait for each response
Default is 30 seconds
-k Use HTTP KeepAlive feature
…
Результаты следующие:
PHP 5.6 on Bitrix Vs.
PHP7 (Zend Engine v3.0.0) on Bitrix
Apache/2.4.20 (Win64) PHP/5.6.20
Document Length: 2987 bytes
Concurrency Level: 10
Time taken for tests: 134.852 seconds
Complete requests: 5000
Failed requests: 2
Requests per second: 37.08 [#/sec]
Time per request: 269.703 [ms]
Time per request: 26.970 [ms] (mean, across all concurrent requests)
Transfer rate: 130.68 [Kbytes/sec] received
Apache/2.4.20 (Win64) PHP/7.0.5
Document Length: 2987 bytes
Concurrency Level: 10
Time taken for tests: 130.592 seconds
Complete requests: 5000
Failed requests: 2
Requests per second: 38.29 [#/sec]
Time per request: 261.183 [ms]
Time per request: 26.118 [ms] (mean, across all concurrent requests)
Transfer rate: 133.86 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)
50% 98
66% 104
75% 108
80% 111
90% 120
95% 131
98% 151
99% 215
100% 42081 (longest request)
Percentage of the requests served within a certain time (ms)
50% 77
66% 83
75% 88
80% 91
90% 105
95% 123
98% 148
99% 187
100% 42048 (longest request)
Как видно, местами процентов на 40% быстрее. Что интересно, что и скорость отдачи контента сервером увеличилась (см. transfer rate). Как мне кажется, это хороший показатель.
PS\2 в момент запуска php7 столкнулся со следующей ошибкой компонента:
Лечится более четким указанием определяемого значения переменной через {}:
// \bitrix\components\bitrix\blog.blog\component.php
global ${$arParams["FILTER_NAME"]};
$arFilter = ${$arParams["FILTER_NAME"]}; // вот так мы явно указываем имя переменной
if(!is_array($arFilter))
$arFilter = array();
PS Выходит очень круто, что просто обновляя версию php, получаем прирост! Очень радует, что битрикс понимает важность перехода на php7, и что уже даже что-то работает
2/ Имеем еще одну защиту нашего апатча от DDoS-атак.
Интересно было бы, если кто-то еще поделился своим опытом использования модуля, в принципе, при наличии прямых рук легко прикручивается к апатчу на bitrix VM.
Либо может еще есть удобные какие-то способы у вас.
[для врезки вправо]
На последок для выявления перегруза слотов апатча, команды через SSH:
ddos в идеале отлавливать до хостера... в случае похуже – на хостере... в еще более худшем случае – до nginx/apache... Но отлавливать на апаче – это, извините, стыд... Хотя, если атака слабенькая, то пост имеет место быть.
Я думаю, что периодически многие сталкиваются с отладкой ошибки, возникающей при перекодировке ваших модулей в маркеплейсе в демо-режим. Некоторый функционал по сперва непонятным причинам отваливается.
Делюсь найденными наблюдениями, а также как это можно избежать и учесть.
Оказывается, нельзя использовать одноименные параметры функций и переменные-члены классов внутри. вот пример обработчика из файла include.php реального модуля :
public function OnBuildGlobalMenu(&$aGlobalMenu, &$aModuleMenu)
{
/* @var $adminMenu \CAdminMenu */
global $adminMenu;
if (! is_array($adminMenu->aGlobalMenu)) {
return;
}
битрикс кодировщик превращает данный код в файле include.php для демо-версии в подобное:
public function OnBuildGlobalMenu(&$_319480480, &$_678570816)
{
global $adminMenu;
if (!is_array($adminMenu->_319480480)) {
return;
}
естественно, поля класса $adminMenu->_319480480 просто нет, и событие не работает.
поэтому следует избегать совпадение имен параметров и используемых полей объектов внутри методов, дабы избежать подобной коллизии (по крайней мере в кодируемых для демо-режима файлах include.php и install.php).
PS возможно, это пофиксят в кодировщике, это было бы предпочтительнее.
С версии 7.2.2 битрикс-машины появилась возможность подключать бесплатные валидные SSl-сертификаты от Lets Encrypt прямо из меню виртуальной машины.
Let’s Encrypt — центр сертификации, начавший работу в бета-режиме с 3 декабря 2015 года, предоставляющий бесплатные криптографические сертификаты для HTTPS. Процесс выдачи сертификатов полностью автоматизирован. Сертификаты выдаются только на 3 месяца для предотвращения инцидентов безопасности.
Первая попытка установить сертификат прошла с отладкой и выяснениями.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».