alexeyymanikin: пс. по поводу ссылки - предлагаю сделать проще, на следующей недели постараюсь подробно описать на форуме как это работает у нас в системе.
Очень интересно, лично буду ждать, в сети информации толком не нашел.
globalmoney: И погубит работу части движков, которые не смогу работать без этих функций!
Я просто ответил, что защититься с помощью этого метода более-менее можно, автору темы это не предлагаю использовать, сам же использую такое только в отношении тех аккаунтов, от кого начинается спам или фиксируется зловредная активность / взлом сайта, чтобы не блокировать аккаунт целиком.
Стоит также заметить, что в большинстве случаев сайты дальше работают, проблемы при этом могут быть при обновлении плагинов, тем и самой CMS через панель администратора сайта (но и то, это по той причине, что список disable_functions в моем случае достаточно обширен).
Простая комбинация из open_basedir + disable_functions защищает плохо, так как есть лазейка через eval, а запретить eval без патчей нельзя. Как итог через eval можно использовать какой-нибудь system / exec, который прописан в disable_functions и дальше делать что угодно.
Вот open_basedir + disable_functions и запрет eval с помощью патча уже более менее спасает от зловредной активности.
adel92, рад, что скрипт направил на верный путь и оказался полезным. В том, чтобы он не давал ложных показаний я заинтересован также как и Вы, так как я тоже хостер и мне не нужны клиенты, которые будут тыкать в баллы, но на моей практике пока что таких проблем не было.
По личным наблюдениям Zend Opcache не влияет на число баллов в тестировании (специально сейчас запустил тест на Вашем сервере), уведомление о нем отображается только по той причине, что он действительно ускоряет работу сайтов.
Avalllon, спасибо за информацию, исходя из выполненного анализа с помощь 1.0.4 (в неё добавлен отладочный режим для отображения ошибок), у Вашего хостера установлен запрет на чтение каталога /proc из-за чего скрипт не мог собрать информацию и падал с ошибкой fatal error. В установщик я добавил проверку доступа к файлам /proc/cpuinfo, /proc/stat, /proc/meminfo, если доступа к ним нет, то теперь выводится сообщение о том, что тестирование невозможно.
---------- Добавлено 22.03.2017 в 02:04 ----------
adel92, взял у Вас аккаунт, попал на сервер serv3.well-web.net, там скрипт выдавал уверенно более 270 баллов, что для E3-1240 и PHP 7.0 вполне хороший и правильный результат. По моей информации 69 баллов на первом скриншоте было именно на этом же сервере, поэтому, либо что-то поправили, либо были какие-то иные факторы, которые влияли на результат.
suffix, без ioncube скрипт не отработает и результаты не отправит. Также, даже если ioncube стоит и не нажать на "Начать тестирование" (http://joxi.ru/Ra2Xa8vHXvo6Ag), скрипт ничего не собирает и не отправляет.
EvGenius: надо учитывать турбо режим еще.
без нагрузки и частота выше, на 3.6 не надо сильно смотреть.
в момент выполнения там наверное все 4.0 было :)
Разница от способа подключения PHP к веб серверу на мой взгляд есть (еще не считал, но при беглом осмотре, способ подключения CGI, дает результаты обычно ниже, чем иные способы подключения). Но этот момент возможно связан с акселераторами и повторным выполнением кода (обсуждали уже ранее в этой теме).
пс. по поводу ссылки - предлагаю сделать проще, на следующей недели постараюсь подробно описать на форуме как это работает у нас в системе.
Очень интересно, лично буду ждать, в сети информации толком не нашел.
И погубит работу части движков, которые не смогу работать без этих функций!
Я просто ответил, что защититься с помощью этого метода более-менее можно, автору темы это не предлагаю использовать, сам же использую такое только в отношении тех аккаунтов, от кого начинается спам или фиксируется зловредная активность / взлом сайта, чтобы не блокировать аккаунт целиком.
Стоит также заметить, что в большинстве случаев сайты дальше работают, проблемы при этом могут быть при обновлении плагинов, тем и самой CMS через панель администратора сайта (но и то, это по той причине, что список disable_functions в моем случае достаточно обширен).
Простая комбинация из open_basedir + disable_functions защищает плохо, так как есть лазейка через eval, а запретить eval без патчей нельзя. Как итог через eval можно использовать какой-нибудь system / exec, который прописан в disable_functions и дальше делать что угодно.
Вот open_basedir + disable_functions и запрет eval с помощью патча уже более менее спасает от зловредной активности.
adel92, рад, что скрипт направил на верный путь и оказался полезным. В том, чтобы он не давал ложных показаний я заинтересован также как и Вы, так как я тоже хостер и мне не нужны клиенты, которые будут тыкать в баллы, но на моей практике пока что таких проблем не было.
По личным наблюдениям Zend Opcache не влияет на число баллов в тестировании (специально сейчас запустил тест на Вашем сервере), уведомление о нем отображается только по той причине, что он действительно ускоряет работу сайтов.
Avalllon, спасибо за информацию, исходя из выполненного анализа с помощь 1.0.4 (в неё добавлен отладочный режим для отображения ошибок), у Вашего хостера установлен запрет на чтение каталога /proc из-за чего скрипт не мог собрать информацию и падал с ошибкой fatal error. В установщик я добавил проверку доступа к файлам /proc/cpuinfo, /proc/stat, /proc/meminfo, если доступа к ним нет, то теперь выводится сообщение о том, что тестирование невозможно.
---------- Добавлено 22.03.2017 в 02:04 ----------
adel92, взял у Вас аккаунт, попал на сервер serv3.well-web.net, там скрипт выдавал уверенно более 270 баллов, что для E3-1240 и PHP 7.0 вполне хороший и правильный результат. По моей информации 69 баллов на первом скриншоте было именно на этом же сервере, поэтому, либо что-то поправили, либо были какие-то иные факторы, которые влияли на результат.
Avalllon, могли бы в личные сообщения сообщить ссылку на файл с phpinfo?
suffix, без ioncube скрипт не отработает и результаты не отправит. Также, даже если ioncube стоит и не нажать на "Начать тестирование" (http://joxi.ru/Ra2Xa8vHXvo6Ag), скрипт ничего не собирает и не отправляет.
надо учитывать турбо режим еще.
без нагрузки и частота выше, на 3.6 не надо сильно смотреть.
в момент выполнения там наверное все 4.0 было :)
Турбо-режим из PHP проблематично учитывать :)
Разница от способа подключения PHP к веб серверу на мой взгляд есть (еще не считал, но при беглом осмотре, способ подключения CGI, дает результаты обычно ниже, чем иные способы подключения). Но этот момент возможно связан с акселераторами и повторным выполнением кода (обсуждали уже ранее в этой теме).
...
а 400 итоговых кто-нибудь перешагнул интересно? :)
Нет, таких результатов еще нет. Максимальный балл (395) получил:
Intel Xeon E3-1270 v5 (3.6 GHz)
Nginx 1.10.2 + Apache 2.4.6 / PHP 7.0.16 (в режиме FastCGI)
LA 0.09