Красивый help report php. Снижение нагрузки на сервер. PHP в HTML с помощью short__tag

В статье описан функционал, который доступен в PHP (актуально для 5.3.х) для обработки ошибок всех типов, включая ошибки интерпретации кода (E_ERROR, E_PARSE, E_WARNING, etc). Эта обработка поможет вам для управляемого отображения страницы в случае возникновения таких проблем. В статье присутствует множество описаний и рабочих примеров(архитектуры) для того, что бы сразу воспользоваться в своем программном продукте. В конце концов, ну немного сломали сайт, ну надо же, об этом сообщить поисковику с заголовком 4хх или 5хх и повеселить пользователя, вместо возврата белого экрана (или что хуже экрана со священной информацией, для хакеров) с ответом 200 Ok.

Идея написать этот топик возникла, когда я на храбре задал 2 вопроса:

• Вопрос о
• Вопрос о

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

Если заинтересовались, то подробности под катом…

Причины использования

Пользователю/поисковику, требуется внятно ответить, что на сервере проблемы. Без использования определенного фен-шуя, этого добиться достаточно трудно, а порой невозможно. Тут я проливаю свет на все это, ну и себе заметочку оставляю, так как еще неделю назад я не знал за что взяться, и, наверное, многие новички тоже будут обескуражены.

Описания функций

Данный функционал доступен в PHP для того, что бы обрабатывать ошибки и контролировать вывод. Вот описание их вкусностей и недостатков. Документацию я приводить не буду, я только сошлюсь её страницы и опишу свое мнение. Все что будет приведено это только малая доля, ссылки на соответствующие разделы документации я приведу в конце статьи. Итак встречаем:

- Контроль некритических ошибок: замечания, предупреждения, пользовательские ошибки. В общем все то, что не завершает интерпретацию аварийно.
set_error_handler - Задает определенный пользователем обработчик ошибок.
Нужен для того, что бы писать в лог все такие ошибки. Если её не задать, то в лог это не пишется, а мне вот всегда хочется узнать при каких боевых ситуациях могут вызываться замечания и предупреждения. То есть позволяет автоматически тестировать продукт пользователем и он даже не будет замечать этого.
Если функция не задана, то PHP лишь пытается вывести данные на экран, а если ему и это не дают, то вообще никаких признаков жизни от этих типов ошибок не возникает.

- Контроль, исключений: является ошибкой типа E_ERROR.
set_exception_handler - Задает пользовательский обработчик исключений
Ну не знаю, зачем это вообще было придумано, когда есть то, что описано ниже и просто обработка ошибки типа Exception. Так что сообщаю что оно просто существует. Она перехватывает критическую ошибку «исключение» и позволяет что-то с ней делать. В любом случае скрипт завершается. Её работы по умолчанию лично для меня достаточно (пишет в логи, пытается вывести на экран). Я бы её вообще не переопределял, а то придется в логи о случившимся исключении самому писать.

- Функции контроля вывода: Тут я опишу 3 функции, которые следует знать по разным причинам. Например, для или для проблем вывода заголовков. В нашем случае требуется выводить заголовки ошибок.

Условия

Есть файл с кодом, который запускается первым или перед кодом в котоом может появиться ошибка и этот файл и все файлы до него 100% отлаженные с невозможностью появления ошибки. Вот такое вот условие, что бы было проще - без ошибок до того пока не пройдут все регистрации вышеизложенных функций. В данном файле описаны данные методики контроля ошибок в комплексе. Контролируется буфер, если ошибка, то сбросить буфер и вывести ошибку.

Код с комментариями

От себя добавлю, что код не тестировал, так как это упрощенная схема того, что у меня в коде, замечания принимаются

Наибольший функционал доступен при запуске сканера AI-BOLIT в режиме командной строки. Это можно делать как под Windows/Unix/Mac OS X, так и непосредственно на хостинге, если у вас есть доступ по SSH и хостинг не сильно ограничивает потребляемые ресурсы процессора.

Обращаем внимание, что для запуска сканера требуется консольная версия PHP 5.3 и выше. В версии 5.2 будет ошибка "Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or "}" in /home/ХХХ/ai-bolit.php on line...". Проверьте текущую версию командой php -v

Справка по параметрам командной строки сканера AI-BOLIT

Показать помощь

php ai-bolit.php --help

php ai-bolit.php --skip=jpg,png,gif,jpeg,JPG,PNG,GIF,bmp,xml,zip,rar,css,avi,mov

Просканировать только определенные расширения

php ai-bolit.php --scan=php,php5,pht,phtml,pl,cgi,htaccess,suspected,tpl

Подготовить файл карантина для отправки специалистам по безопасности. Будет создан архив AI-QUARANTINE-XXXX.zip с паролем.

php ai-bolit.php --quarantine

Запустить сканер в режиме "параноидальный" (рекомендуется для получения максимально-детализированного отчета)

php ai-bolit.php --mode=2

php ai-bolit.php --mode=1

Проверить один файл "pms.db" на вредоносный код

php ai-bolit.php -jpms.db

Запустить сканер с размером памяти 512Mb

php ai-bolit.php --memory=512M

Установить максимальный размер проверяемого файла 900Kb

php ai-bolit.php --size=900K

Делать паузу 500ms между файлами при сканировании (для снижения нагрузки)

php ai-bolit.php --delay=500

Отправить отчет о сканировании на email [email protected]

php ai-bolit.php [email protected]

Создать отчет в файле /home/scanned/report_site1.html

php ai-bolit.php --report=/home/scanned/report_site1.html

Просканировать директорию /home/s/site1/public_html/ (отчет по-умолчанию будет создан в ней же, если не задана опция --report=файл_отчета)

php ai-bolit.php --path=/home/s/site1/public_html/

Выполнить команду по завершении сканирования.

php ai-bolit.php --cmd="~/postprocess.sh"

Получить отчет в текстовом виде (plain-text) с именем site1.txt

php ai-bolit.php -lsite1.txt

Можно комбинировать вызовы, например,

php ai-bolit.php --size=300K --path=/home/s/site1/public_html/ --mode=2 --scan=php,phtml,pht,php5,pl,cgi,suspected

Комбинируя вызов сканера AI-BOLIT c другими командами unix, можно выполнять, например, пакетную проверку сайтов. Ниже приведем пример проверки нескольких сайтов, размещенных внутри аккаунта. Например, если сайты размещены внутри директории /var/www/user1/data/www, то команда на запуск сканера будет

find /var/www/user1/data/www -maxdepth 1 -type d -exec php ai-bolit.php --path={} --mode=2 \;

Добавив параметр --report можно управлять каталогом, в котором будут создаваться отчеты о сканировании.

php ai-bolit.php список параметров … --eng

Переключить интерфейс отчета на английский. Данный параметр должен идти последним.

Интеграция с другими сервисами и в панель хостинга

php ai-bolit.php --json_report=/path/file.json

Cформировать отчет в формате json

php ai-bolit.php --progress=/path/progress.json

Cохранять статус проверки в файл в формате json. Данный файл будет содержать структурированные данные в формате json: текущий файл проверки, сколько файлов проверено, сколько файлов осталось проверить, процент проверки, время до завершения сканирования. Данный механизм можно использовать, чтобы в панели показывать прогресс-бар и данные о проверяемых файлах. По завершении сканирования файл удаляется автоматически.

php ai-bolit.php --handler=/path/hander.php

Внешний обработчик событий. Вы можете добавить собственные обработчики начала/завершения сканирования/прогресса сканирования/ошибки сканирования. Пример файла можно посмотреть в архиве сканера, в каталоге tools/handler.php. Например, по завершении сканирования можно что-то сделать с файлом отчета (отправить по почте, запаковать в архив и пр).

В этом уроке мы научимся такой вещи как сокрытие ошибок PHP. Попутно мы также разберём, как не просто подавлять вывод этих ошибок, но и как записывать их в файл журнала, как защитить этот файл журнала, как настроить уровень сообщения об ошибках PHP (насколько серьёзные ошибки показывать, показывать ли предупреждения), научимся устанавливать максимальный размер строки ошибки и отключим запись повторяющихся ошибок.

Нужно ли прятать PHP ошибки

PHP ошибки выдают самую разнообразную информацию, которая позволяет нападающим собрать данные о вашем сайте и вашем сервере. Но если бы на этот вопрос был однозначный ответ «да», то всё решалось бы добавлением в каждый файл с программами PHP одной единственной строки

Error_reporting(0);

На самом деле, все ошибки, в том числе и предупреждения (некритические ошибки) нужно выводить на стадии тестирования. Вывод ошибок и предупреждения также поможет разобраться в имеющихся (или возможных) проблемах в рабочем окружении. Не стоит подавлять вывод ошибок и предупреждений в программах, предназначенных для свободного распространения, поскольку при возникновении проблем все репорты пользователей о проблемах будут одинаковыми: «там белый экран», что сильно затруднит попытки разобраться.

В общем, на серверах, предназначенных для разработки (например, на домашнем сервере), не нужно убирать ошибки и предупреждения PHP методами error_reporting(0) ; и @ – нужно изучить их причины и исправлять исходный код.

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

Как включить журналирование ошибок PHP посредством.htaccess

В этой части урока я покажу пользователям Apache как подавить вывод ошибок PHP и скрыть их от посетителей, при этом будет включена запись PHP ошибок для их дальнейшего анализа, вся эта настройка будет осуществлена через файл.htaccess.

Вообще, этот способ обладает ещё одним замечательным плюсом — вместо того, чтобы пытаться переловить все PHP ошибки и предупреждения, мы каждое из них будем записывать в наш личный лог, благодаря этому не ускользнёт ни одна возникшая ошибка, даже если она возникла не у вас, а у кого-то посетителя вашего сайта при условиях которые, может быть, вам бы даже и в голову не пришли для моделирования. Благодаря есть простой способ реализовать эту эффективную стратегию.

Прячем PHP ошибки от посетителей

Есть разные способы подавить ошибки PHP посредством.htaccess. Это можно сделать включением следующих директив.htaccess в файл вашего домена httpd.conf или в корневую (или любую другую целевую директорию) файла.htaccess со следующим содержимым:

# подавить ошибки php php_flag display_startup_errors off php_flag display_errors off php_flag html_errors off php_value docref_root 0 php_value docref_ext 0

Это приведёт к тому, что PHP ошибки больше не будут публичными на вашем сайте. Это исключает потенциальные риски безопасности, и не даёт этим уродским, непонятным PHP ошибках поломать вёрстку вашего сайта и дезориентировать ваших посетителей. Редактирования кода для этого не требуется.

Включение личного журнала PHP ошибок

Теперь, когда мы спрятали PHP ошибки от общественности, давайте включим их журналирование (запись), чтобы мы могли их отследить. Это делается добавлением следующих директив.htaccess к файлу вашего домена httpd.conf или в ваш файл.htaccess, который размещён в корневой (или любой целевой) директории.

# включение записи PHP ошибок php_flag log_errors on php_value error_log /home/path/public_html/domain/PHP_errors.log

Чтобы это заработало, вам нужно отредактировать путь в последней строчке в соответствии с действительным расположением вашего файла PHP_errors.log. Конечно, вместе с этим вам нужно создать этот файл и дать ему разрешения 755 или, если необходимо, 777. Наконец, вам нужно обезопасить этот файл журнала, добавив эти завершающие строки кода в ваш файл.htaccess:

# предотвращаем доступ к логу PHP ошибок

Теперь, когда всё на месте, проверьте, что всё работает как следует, вызовите несколько ошибок PHP. Вы также, возможно, захотите проверить защиту вашего файла журнала, попробовав получить к нему доступ через браузер.

Продвинутая обработка ошибок PHP с помощью.htaccess

Давайте теперь глубже окунёмся в эту тему, добавим дополнительной функциональности и исследуем различные реализации. В первую очередь мы исследуем работу с ошибками PHP для рабочего окружения (например, для веб-сайтов и приложений, которые находятся онлайн, активны и являются публичными), затем мы рассмотрим работу с ошибками для окружения разработчика (например, для проектов под разработкой, тестирования, частных, т. д.).

Контролирование уровня сообщения ошибок PHP

Используя.htaccess возможно настроить уровень сообщения ошибок, который подходит под ваши практические нужды. Общий форт для контролирования уровня ошибок PHP следующий:

# общий вид директивы для настройки уровня ошибок php php_value error_reporting цифра

Есть несколько распространённых значений, которые можно подставить вместо «цифра», в том числе:

• Самое полное сообщение об ошибках (соответствует E_ALL) — для этого используйте значение «32767».
• Полное сообщение об ошибках — для полной записи ошибок PHP используйте величину «8191», которая включит запись всего, кроме уведомлений времени выполнения об использовании устаревших конструкций (предупреждения о коде, который не будет работать в следующих версиях PHP).
• Сообщение об ошибках Zend — для записи как фатальных, так и не фатальных предупреждениях времени компиляции, генерируемых скриптовым движком Zend, используйте «192».
• Сообщение о базовых ошибках — записывать уведомления времени выполнения. Указывают на то, что во время выполнения скрипта произошло что-то, что может указывать на ошибку, хотя это может происходить и при обычном выполнении программы. Для этого используйте цифру «8».
• Минимальное сообщение об ошибках — записывать только фатальные ошибки времени выполнения. Это неустранимые средствами самого скрипта ошибки, такие как ошибка распределения памяти и т.п. Выполнение скрипта в таком случае прекращается. Для этого используйте цифру «1».

Конечно можно использовать и другие значения («цифры») для тонкой настройки того, какие именно ошибки вы хотите фиксировать. Некоторые разъяснения по данному вопросу в самом низу.

Настраиваем максимальный размер файла для записей ваших ошибок

Используя.htaccess вы можете определить максимальный размер для ваших ошибок PHP. Имеется ввиду контроль размера каждой записанной ошибки, а не всего файла в целом. Синтаксис имеет следующий вид:

# генеральная директива для настройки максимального размера ошибки log_errors_max_len целове_число

Здесь «целове_число» представляет максимальный размер каждой записанной строки ошибки в байтах. По умолчанию значение равно «1024» (т. е. 1 килобайт). Чтобы удалить этот лимит можно установить значение «0». Помните, .что это значение также применяется для отображаемых ошибок, когда они включены (например, во время разработки).

Отключение записи повторяющихся ошибок

Если вы уже успели поработать с журналом ошибок, вы могли обратить внимание, что в нём множество похожих записей, которые различаются только временем события. От этой избыточности можно избавиться, просто добавьте в файл htaccess эти строки:

# отключаем запись повторяющихся ошибок php_flag ignore_repeated_errors on php_flag ignore_repeated_source on

При таких настройках повторяющиеся ошибки не будут записываться в ружнал, даже если они случились в различных источниках или адресах. Если вы хотите отключить повторяющиеся ошибки только из одного источника или файла, просто закомментируйте или удалите последнюю строку. И наоборот, чтобы убедиться, что ваш файл журнала событий включает все повторяющиеся ошибки, измените обе величины с on на off .

Собираем всё вместе — рабочее окружение

Обсудив особенности настройки записи ошибок PHP, давайте соберём все наши записи в один файл.htaccess. Данные настройки оптимизированы для рабочего окружения.

# обработка ошибок PHP для рабочего сервера php_flag display_startup_errors off php_flag display_errors off php_flag html_errors off php_flag log_errors on php_flag ignore_repeated_errors off php_flag ignore_repeated_source off php_flag report_memleaks on php_flag track_errors on php_value docref_root 0 php_value docref_ext 0 php_value error_log /home/path/public_html/domain/PHP_errors.log php_value error_reporting -1 php_value log_errors_max_len 0 Order allow,deny Deny from all Satisfy All

Если вы считаете хорошим стилем код с пояснениями, то этот же код, но с комментариями:

# обработка ошибок PHP для рабочего сервера # отключение отображения ошибок запуска php_flag display_startup_errors off # отключить отображение всех других ошибок php_flag display_errors off # отключить ошибки html разметки php_flag html_errors off # включить запись ошибок php_flag log_errors on # включить игнорирование повторяющихся ошибок php_flag ignore_repeated_errors off # отключить игнорирование ошибок из уникальных источников php_flag ignore_repeated_source off # включить запись утечек памяти php php_flag report_memleaks on # сохранять большинство последних ошибок через php_errormsg php_flag track_errors on # отключить форматирование справочных ссылок на ошибки php_value docref_root 0 # отключить форматирование справочных ссылок на ошибки php_value docref_ext 0 # указание пути до файла лога ошибок php php_value error_log /home/path/public_html/domain/PHP_errors.log # указать запись всех ошибок php php_value error_reporting -1 # отключить максимальную длину строки ошибки php_value log_errors_max_len 0 # защитить файл журнала ошибок от публичного доступа Order allow,deny Deny from all Satisfy All

Приведённая стратегия идеальна для публичного сервера в рабочем окружении. Все ошибки скрыты от посторонних глаз, при этом они аккуратно собираются для администраторов и программистов. Конечно, вы можете настроить приведённые директивы под себя, чтобы они идеально подходили под ваши задачи. А теперь давайте рассмотрим стратегию работы с ошибками для окружения разработки.

Собираем всё вместе — окружение разработки

Разрабатывая или отлаживая программу, удобнее отслеживать возникающие PHP ошибки в режиме реального времени, прямо в браузере. Пример.htaccess с соответствующими настройками под окружение разработки приведён ниже:

# работа с ошибками PHP для серверов разработчиков php_flag display_startup_errors on php_flag display_errors on php_flag html_errors on php_flag log_errors on php_flag ignore_repeated_errors off php_flag ignore_repeated_source off php_flag report_memleaks on php_flag track_errors on php_value docref_root 0 php_value docref_ext 0 php_value error_log /home/path/public_html/domain/PHP_errors.log php_value error_reporting -1 php_value log_errors_max_len 0 Order allow,deny Deny from all Satisfy All

Не будем объяснять каждую строку — вы можете посмотреть соответствующие разъяснения чуть повыше.

Подсказки

Чтобы узнать абсолютный путь до лог файла на сервере методами PHP (для директивы php_value error_log)

echo dirname(__FILE__);

Пример.htaccess для .

php_flag display_startup_errors on php_flag display_errors on php_flag html_errors on php_flag log_errors on php_flag ignore_repeated_errors off php_flag ignore_repeated_source off php_flag report_memleaks on php_flag track_errors on php_value docref_root 0 php_value docref_ext 0 php_value error_log C:ServerdatahtdocsPHP_errors.log php_value error_reporting -1 php_value log_errors_max_len 0 Order allow,deny Deny from all Satisfy All

Не работает

Этот способ не применим на хостингах, где PHP работает как CGI (возможные пути решения будут показаны в следующей статье).

-1 и ~0 для отображения всех ошибок PHP

В директиве php_value error_reporting для отображения всех ошибок можно указать -1 или ~0 . Т.е. строки выглядят так:

Php_value error_reporting -1 php_value error_reporting ~0

Причём более правильным считается именно второй способ, т. е. с использованием ~0 .

Предопределенные константы и побитовые операции error_reporting

• Предопределенные константы
• Побитовые операторы

Например, если мы хотим записывать ТОЛЬКО следующие ошибки E_ERROR (значение 1), E_WARNING (значение 2), E_CORE_ERROR (значение 16), то для получения соответствующейо числовой величины следовало бы перевести эти величины в двоичные числа и произвести соответствующие побитовые операции, а потом полученное двоичное число перевести в десятеричное. Тем не менее, эту операцию можно упростить — достаточно сложить значения десятеричных чисел. Т.е. в нашем случае это 1+2+16=19

Php_value error_reporting 19

будет отображать ошибки E_ERROR, E_WARNING и E_CORE_ERROR.

Пример абсолютного пути до лог файла на хостинге Hostland (для директивы php_value error_log)

/home/host900456/сайт/blogs/htdocs/www/PHP_errors.log

Вместо host900456 нужно указать ваш аккаунт.

Вместо сайт нужно указать ваш домен.

Кстати, хороший хостинг , на котором работает этот самый сайт. Рекомендуем!

Коэффициент допустимой нагрузки на сервер - один из параметров SaaS-аккаунтов. Для каждого тарифного плана установлены свои параметры нагрузки. С текущей нагрузкой аккаунта Вы всегда можете ознакомиться в личном кабинете CRM системы.

Иногда может происходить такая ситуация, что используемый аккаунт выдает нагрузку, которая выше разрешенной на Вашем тарифном плане. Об этом Вы будете оповещены соответствующим письмом.

Основные параметры, влияющие на нагрузку:

• Количество пользователей в системе работающих одновременно;
• Количество записей в таблицах программы;
• Количество правил и групп доступа;
• Количество напоминаний, цветовых форматирований, фильтров и т.д.;
• Количество вычислений и их сложность;
• Количество заданий, выполняемых в фоновом режиме (через систему Cron);
• Количество запущенных рассылок (электронной почты и СМС);
• Количество отчетов;
• Объем лога программы.

Поэтому, если некоторые группы доступа, цветовые форматирования, фильтры и прочие элементы конфигурации не используются, то их желательно удалить. Также можно удалить ненужные записи из таблиц. Кроме удаления элементов конфигурации можно предпринять и другие меры по снижению нагрузки на сервер. О них подробнее речь пойдет ниже.

Все меры по снижению нагрузки можно разделить на две части: для администраторов и для разработчиков. Эти меры также могут снизить нагрузку на сервер при использовании web-версии программы.

Инструкции для администраторов

Начало оптимизации

Самое первое действие, которое Вы должны сделать - убедиться, что у Вас используется последняя версия программы. Убедиться в этом можно, перейдя в "Настройки" - "Дополнительно" - "Обновление ревизии". Если Вы используете самую последнюю версию и ревизию программы, Вы увидите соответствующее сообщение

Если же Вы используете старую версию или ревизию, то программа предложит Вам обновиться.

Далее следует запустить расширенную проверку системы. Для этого перейдите в "Настройки" - "Дополнительно" - "Проверка системы" и нажмите на кнопку "Расширенная проверка системы". В случае возникновения ошибок в программе, они будут автоматически исправлены.

Общие настройки программы

Перейдите в "Настройки" - "Дополнительно" - "Общие настройки". Здесь стоит обратить внимание на два пункта.

Интуитивный поиск - Вы можете отключить эту опцию, если Вам не нужен поиск по транслитерации значения.

Режим скролла окна - Подробнее о режимах скролла окна Вы можете прочитать в нашей документации . Желательно указать у данной настройки значение "Простой".

Настройки Cron

Перейдите в "Настройки" - "Дополнительно" - "Настройки Cron". В настройках Cron можно управлять задачами, выполняющимися автоматически в фоновом режиме. Например, синронизацией, отправкой писем и СМС. Снизить нагрузку за счет этой настройки можно двумя способами.

1. Запретить выполнение заданий, которые Вы в своей программе не используете. Сделать это можно, открыв нужное задание и поставив галочку "Запретить выполнение".

Например, если Вы не пользуетесь функцией синхронизации, то откройте соответствующее задание и поставьте галочку "Запретить выполнение" в его настройках. Если Вы не пользуетесь функцией отправки СМС - можно запретить выполнение заданий "Формирование СМС", "Отправка СМС", "Проверка статуса доставки СМС".

2. Изменить периодичность выполнения заданий. Сделать это можно, зайдя в настройки задания и изменив значение в поле "Период". Например, в задании "Отправка писем" можно указать вместо ежеминутного выполнения, выполнение задания раз в 5 минут.

Настройка условий выполнения вычислений

В CRM программе для автоматического заполнения некоторых полей используются вычисления. Но иногда условия их выполнения неоптимальны. Например, нагрузку вызывает условие "Отображения поля" в настройке вычисления. Следует избегать его использования.

Например, если у нас есть вычисление, по которому в поле А вносится сумма полей Б и В, то желательно использовать условия "Изменение поля Б" и "Изменение поля В". Если у нас есть вычисление, которое заносит в поле А значение из другой таблицы из поля Б, в зависимости от значения в поле связи В, то логично, что можно использовать только условие "Изменение поля В" и "Сохранение в таблице".

Настройка и архивирование логов

Перейдите в "Настройки" - "Логи" - "Настройка лога". В настройках лога, без необходимости не стоит включать логирование просмотра пользователем таблиц, представлений и записей. Это может как увеличить нагрузку на сервер, так и привезти к тому, что файл с логами будет слишком большим. Также здесь стоит включить опцию "Производить ежемесячное архивирование лога", что позволит ежемесячно автоматически уменьшать размер таблицы с логами

Также здесь можно автоматически заархивировать логи, если ранее не было включено автоматическое архивирование. Сделать это можно во вкладке "Архив".

Настройка фильтров

Если открыть настройки любого фильтра, то в них можно увидеть опцию "Отображать в скобках число записей". Желательно снять эту галочку, т.к. эта опцию может вызывать нагрузку при каждом открытии таблицы. И чем больше таких фильтров в таблице - тем больше нагрузка при открытии.

Инструкция для разработчиков

Работа с таблицей perfomance_stat

Важно: Внесение изменений в таблицы базы данных может привести к неработоспособности программы. Не стоит вносить изменения в таблицы базы данных без крайней необходимости.

Войдите в ваш аккаунт, и откройте адрес https://*адрес вашего аккаунта*/edit_sql.php (где вместо *адрес вашего аккаунта* укажите соответствующее значение). В открывшемся окне заходим в таблицу базы данных, содержащую название Вашего аккаунта (например, c_myaccount). В открывшемся перечне таблиц базы откройте таблицу f_performance_stat

В данной таблице ведется учет всех скриптов программы за последний час. Для начала, вам стоит отсортировать все скрипты в этой таблице по количеству sql-запросов (от большего к меньшему). Для этого, дважды нажмите на заголовок "sql_count".

После того, как данные отсортированы, можно начать проводить анализ данных. При проведении анализа Вам стоит обратить внимание на два столбика

1. script - указывает на название скрипта, выдающего нагрузку

2. get_data - дает более подробную информацию о скрипте, либо содержит ссылку на таблицу/задачу, в которой возникает нагрузка.

Для удобства анализа, используйте таблицу, приведенную ниже:

Значение в поле "script"	Пример значения в поле "get_data"	Описание	Действия для снижения нагрузки
cron.php	...&task_id=1	Строка такого вида означает, что нагрузку дает одно из заданий в Cron	Необходимо перейти в "Настройки Cron" и открыть задание, вызывающее нагрузку (ID задания указано в поле "get_data"). Стоит либо оптимизировать код задания, либо уменьшить его периодичность. О настройках Cron .
view_line2.php	table=42&line=1&filter=48&page=1	Строка такого вида означает, что нагрузку дает одно или несколько вычислений в определенной таблице при просмотре записи
fields.php	table=42&filter=48	Строка такого вида означает, что нагрузку дает одно или несколько вычислений в определенной таблице при просмотре таблицы	Необходимо перейти в настройки вычислений таблицы, указанной в поле "get_data" (в примере, это таблица с ID 42). Для начала, стоит посмотреть и оптимизировать условия выполнения вычислений в указанной таблице. Если этого не помогло, стоит оптимизировать сам код вычислений.
report.php	id=30	Строка такого вида означает, что нагрузку дает один из отчетов программы	Необходимо оптимизировать код отчета, указанного в поле "get_data" (в примере, это отчет с ID 30).

29 декабря 2012 в 22:01

• Microsoft SQL Server

Продолжаем рассматривать полезные советы для начинающих, при создании отчетов в Microsoft Reporting Services.
Начало можно найти здесь:
Заинтересовавшихся, прошу под кат…

0) Как разместить несколько контролов в ячейке таблицы?

Достаточно часто возникает необходимость разместить несколько контролов в 1 ячейке таблицы. Если просто перетаскивать контрол в ячейку, то он полностью ее заполняет. Выйти из этой ситуации помогает контрол, под названием Rectangle.

Rectangle представляет собой аналог контрола Panel, используемого в WinForms, это некая площадка для размещения контролов. При размещении в ячейке, Rectangle заполняет собой всю ячейку таблицы создавая «площадку» для размещения остальных контролов.

1) Задавайте язык отчета по умолчанию

При создании отчетов старайтесь декларировать язык отчета (Свойства отчета - Language).

Это очень полезно если вы работаете с заграничным клиентом у которого региональные настройки отличаются от Ваших. Если Вы не знаете какие настройки использует Ваш клиент, то есть возможность указать Expression следующего содержания:
=User!Language
Этим Вы избежите неровностей в форматировании числовых значений, даты, времени, валюты и т.п которые ожидает клиент.

2) Конкатенация строк

Иногда возникает необходимость «вставить» в статический текст отчета, размещенный например в texbox, значение поля из базы данных. Иными словами нужно сложить строки текста в 1 строку. Для этого в SSRS предусмотрен операнд «&».
Предположим в texbox у нас имеется статический текст «Здравствуйте, ув. Иван Иванович…». Нам необходимо вместо Иван Иванович подставлять ФИО из базы данных, из поля fio. Для этого правой кнопкой мыши над texbox, вызываем контекстное меню, выбираем свойство Expression у texbox и меняем текст следующим образом:
=” Здравствуйте, ув. “ & Fields!fio.Value & ” …”
upd: Как подсказал в коментарии уважаемый , более правильный способ конкатенации строк - использовать placeholder.
Использовать его просто: в texbox, необходимо уставнить курсор в то место, куда предполагается вставить значение из поля базы данных. Правой кнопкой мыши вызываем контекстное меню и выбираем «Create placeholder...»

Задаем значение Label(это значение будет видно в тексте, если не указать значение для поля Lable, то будет использовано название поля из базы данных) и Value(в нашем случае это поле из базы данных)

Применение placeholder преподносит дополнительные выгоды:
1) Видно текст, который находится в контроле(в методе что описал я, пользователь видит только текст <> , что вводит человека, который видит код отчета впервые в замешательство и тратит его время на поиск нужного Expression.)
2) Placeholder позволяет произвести форматирование поля (задать формат данных, изменить шрифт, цвет, выравнивание и т.п) не меняя при этом форматирование основного текста.

Разница «на лицо»:

3) Способы форматирования числовых данных

SSRS предоставляет несколько возможностей форматировать данные. Наиболее простой способ форматирования это указать формат(свойство Format) в свойствах контрола.

Этот способ имеет 2 недостатка:
1) контрол содержит кроме данных которые предполагается форматировать еще и дополнительный текст.
2) при экспорте отчета в хмл
Решить эту проблему возможно с помощью вызова специальных методов. Рассмотрим пример:
Textbox содержит следующий текст: “Уважаемый клиент, остаток средств на вашем счету составляет: ” & Fields!UserBalance.Value & “ руб.” .
Если не производить форматирование, то при условии, что значение Fields!UserBalance.Value равно 1005.35 может отобразится пользователю, как 1005.350000000000. Для избежания такого казуса, необходимо использовать метод Format или FormatNumber .
Пример использования: “Уважаемый клиент, остаток средств на вашем счету составляет ” & Format(Fields!UserBalance.Value,”#,##0.00”) & “ руб.”
“Уважаемый клиент, остаток средств на вашем счету составляет ” & FormaNumber(Fields!UserBalance.Value,2) & “ руб.”
При использовании Format необходимо использовать маску форматирования, при использовании FormaNumber достаточно указать количество знаков после запятой.
Примечание: метод Format применим так же для форматирования даты, времени, денег и т.п

4) Экспорт отчета в хмл формат настройка полей

SSRS позволяет экспортировать отчет в разные форматы, одним из них является ХМЛ. У каждого контрола отчета есть 3 свойства которые отвечают за поведение при экспорте в хмл.

Рассмотрим их поближе:
DataElementName – отвечает за название элемента в хмл, по умолчанию значение не выполнено. Если не выполнить этот элемент, то название в хмл будет соответствовать названию контрола.
DataElementOutput – свойство отвечает за то будет элемент экспортирован в хмл или нет. Значения которые можно задать:
Auto (значение по умолчанию) – элемент будет экспортирование в том случает если он имеет значение, если значение null, то не экспортируется.
Output – элемент всегда экспортируется.
NoOutput – элемент в хмл не экспортируется
DataElementStyle – отвечает за стиль элемента в хмл(будет это элемент или атрибут)
Значения которые возможно использовать:
Auto (значение по умолчанию) – в зависимости от контрола будет экспортирован в виде элемента(node) или атрибута(attribute). По сути, только texbox по умолчанию экспортируется в виде атрибута, остальные элементы виде нодов.
Attribute – значение будет представлено в виде атрибута
Element – значение будет представлено в виде элемента (node)
Важная фишка: на экспорт в хмл не распространяется свойство Hidden.Поэтому если в хмл предполагается экспортировать элемент который показывается или нет на основании условия то это условие нужно перенести в Expression контрола. Пример: textbox содержит текст который показывается лишь в случает когда поле condition = 1. Тогда Expression будет выглядеть так:
=IIF(Fields!Condition.Value = 1, “Some text”,””)

На сегодня все, продолжение следует.