Коефіцієнт допустимого навантаження на сервер - один із параметрів SaaS-акаунтів. Для кожного тарифного плану встановлені параметри навантаження. З поточним навантаженням облікового запису Ви завжди можете ознайомитись в особистому кабінеті CRM системи.
Іноді може відбуватися така ситуація, що обліковий запис видає навантаження, яке вище дозволеного на Вашому тарифному плані. Про це Ви будете сповіщені відповідним листом.
Основні параметри, що впливають на навантаження:
- Кількість користувачів у системі працюючих одночасно;
- Кількість записів у таблицях програми;
- Кількість правил та груп доступу;
- Кількість нагадувань, колірних форматувань, фільтрів тощо;
- Кількість обчислень та їх складність;
- Кількість завдань, які виконуються у фоновому режимі (через систему Cron);
- Кількість запущених розсилок (електронної пошти та СМС);
- Кількість звітів;
- Об'єм лога програми.
Тому, якщо деякі групи доступу, колірні форматування, фільтри та інші елементи конфігурації не використовуються, їх бажано видалити. Можна також видалити непотрібні записи з таблиць. Крім видалення елементів конфігурації, можна вжити й інших заходів щодо зниження навантаження на сервер. Про них докладніше йтиметься нижче.
Усі заходи для зниження навантаження можна розділити на дві частини: для адміністраторів і для розробників. Ці заходи можуть також знизити навантаження на сервер під час використання веб-версії програми.
Інструкції для адміністраторів
Початок оптимізації
Найперша дія, яку Ви повинні зробити – переконатися, що у Вас використовується остання версія програми. Переконатися в цьому можна, перейшовши до "Налаштування" - "Додатково" - "Оновлення ревізії". Якщо Ви використовуєте останню версію та ревізію програми, Ви побачите відповідне повідомлення
Якщо Ви використовуєте стару версію або ревізію, то програма запропонує Вам оновитися.
Далі слід запустити розширену перевірку системи. Для цього перейдіть в "Налаштування" - "Додатково" - "Перевірка системи" та натисніть кнопку "Розширена перевірка системи". У разі виникнення помилок у програмі вони будуть автоматично виправлені.
Загальні налаштування програми
Перейдіть до "Параметри" - "Додатково" - "Загальні налаштування". Тут варто звернути увагу на два пункти.
Інтуїтивний пошук - Ви можете вимкнути цю опцію, якщо Вам не потрібен пошук транслітерації значення.
Режим скролла вікна - Докладніше про режими скролла вікна Ви можете прочитати в нашій документації. Бажано вказати у налаштування значення "Простий".
Налаштування 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). |
- 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. Щоб уникнути такого казусу, необхідно використовувати метод Форматабо 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. Приклад: textbox містить текст який показується лише у випадку коли поле condition = 1. Тоді Expression буде виглядати так:
=IIF(Fields!Condition.Value = 1, “Some text”,””)
На сьогодні все продовження слідує.
У статті описано функціонал, який доступний у PHP (актуально для 5.3.х) для обробки помилок усіх типів, включаючи помилки інтерпретації коду (E_ERROR, E_PARSE, E_WARNING, etc). Ця обробка допоможе вам для керованого відображення сторінки у разі виникнення таких проблем. У статті присутня безліч описів та робочих прикладів (архітектури) для того, щоб відразу скористатися у своєму програмному продукті. Зрештою, ну трохи зламали сайт, ну треба ж, про це повідомити пошукачу із заголовком 4хх або 5хх і повеселити користувача, замість повернення білого екрана (або що гірше за екран зі священною інформацією, для хакерів) з відповіддю 200 Ok.
Ідея написати цей топік виникла, коли я на хоробрі поставив 2 питання:
- Питання про
- Питання про
Якщо зацікавилися, то подробиці під катом.
Причини використання
Користувачеві/пошукачеві, потрібно чітко відповісти, що на сервері проблеми. Без використання певного фен-шуя, цього досягти досить важко, а часом неможливо. Тут я проливаю світло на все це, та й собі замітку залишаю, бо ще тиждень тому я не знав за що взятися, і, напевно, багато новачків теж будуть збентежені.Опис функцій
Даний функціонал доступний в PHP для того, щоб обробляти помилки та контролювати висновок. Ось опис їх смаколиків та недоліків. Документацію я наводити не буду, я тільки пошлюся її сторінки і опишу свою думку. Все, що буде наведено, це тільки мала частка, посилання на відповідні розділи документації я наведу в кінці статті. Отже зустрічаємо:- Контроль некритичних помилок:зауваження, попередження, помилки користувача. Загалом, усе те, що не завершує інтерпретацію аварійно.
set_error_handler - Задає певний користувачем обробник помилок.
Потрібний для того, щоб писати в ліг всі такі помилки. Якщо її не задати, то в ліг це не пишеться, а мені завжди хочеться дізнатися при яких бойових ситуаціях можуть викликатися зауваження і попередження. Тобто дозволяє автоматично тестувати продукт користувачем і він навіть не помічатиме цього.
Якщо функція не задана, то PHP лише намагається вивести дані на екран, а якщо йому і це не дають, взагалі ніяких ознак життя від цих типів помилок не виникає.
- Контроль, винятків:є помилкою типу E_ERROR.
set_exception_handler - Задає користувальницький обробник винятків
Ну не знаю, навіщо це взагалі було вигадано, коли є те, що описано нижче і просто обробка помилки типу Exception. Так що повідомляю, що воно просто існує. Вона перехоплює критичну помилку «виключення» і дозволяє щось із нею робити. У будь-якому випадку скрипт завершується. Її роботи за умовчанням особисто для мене достатньо (пише у логи, намагається вивести на екран). Я б її взагалі не перевизначав, а то доведеться в логі про виключення, що сталося, самому писати.
- функції контролю висновку:Тут я опишу три функції, які слід знати з різних причин. Наприклад, для або для проблем виведення заголовків. У разі потрібно виводити заголовки помилок.
Умови
Є файл з кодом, який запускається першим або перед кодом в якому може з'явитися помилка і цей файл і всі файли до нього 100% налагоджені з неможливістю появи помилки. Ось така умова, що було б простіше - без помилок доти поки не пройдуть усі реєстрації вищевикладених функцій. У цьому файлі описані дані методики контролю помилок у комплексі. Контролюється буфер якщо помилка, то скинути буфер і вивести помилку.Код із коментарями
Від себе додам, що код не тестував, тому що це спрощена схема того, що у мене в коді, зауваження приймаютьсяУ цьому уроці ми навчимося такої речі, як приховування помилок 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 _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
Якщо ви вважаєте хорошим стилем код з поясненнями, то цей код, але з коментарями:
# обробка помилок PHP для робочого сервера # відключення відображення помилок запуску php_flag display_startup_errors off # відключити відображення всіх інших помилок php_flag display_errors off # відключити помилки html розмітки php_flag html_errors off # включити запис помилок php _flag ignore_repeated_errors off # вимкнути ігнорування помилок з унікальних джерел php_flag ignore_repeated_source off # включити запис витоків пам'яті php php_flag report_memleaks on # зберігати більшість останніх помилок через php_errormsg p_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 # захист
Наведена стратегія є ідеальною для публічного сервера в робочому оточенні. Усі помилки приховані від сторонніх очей, причому вони акуратно збираються для адміністраторів і програмістів. Звичайно, ви можете налаштувати наведені директиви під себе, щоб вони ідеально підходили до ваших завдань. А тепер розглянемо стратегію роботи з помилками для оточення розробки.
Збираємо все разом - оточення розробки
Розробляючи або налагоджуючи програму, зручніше відстежувати PHP помилки, що виникають в режимі реального часу, прямо в браузері. Приклад.htaccess з відповідними налаштуваннями під оточення розробки наведено нижче:
# робота з помилками PHP для серверів розробників php_flag display_startup_errors on php_flag display_errors on php_flag html_errors on php_flag s 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
Не пояснюватимемо кожен рядок — ви можете подивитися відповідні роз'яснення трохи вище.
Підказки
Щоб дізнатися абсолютний шлях до лог файлу на сервері методами 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 ot 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 Не працює
Цей спосіб не застосовується на хостингах, де 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потрібно вказати ваш обліковий запис.
Замість сайтпотрібно вказати ваш домен.
До речі, хороший хостинг, на якому працює цей сайт. Рекомендуємо!
20.6KPHP — це серверна мова програмування, що вбудовується. Більшість його синтаксису запозичена з C, Java і Perl. А також додана пара унікальних характерних лише для PHP функцій. Основна мета цієї мови - створення динамічно генерованих PHP HTML сторінок.
PHP у HTML
Під час створення складних веб-сторінок ви зіткнетеся з необхідністю об'єднати PHP та HTML для реалізації конкретних завдань. На перший погляд це може здатися складним, оскільки PHP та HTML є двома незалежними дисциплінами, але це не так. PHP призначений для взаємодії з HTML і його код може бути включений в розмітку сторінки.
У HTML-сторінки PHP-код включається за допомогою спеціальних тегів. Коли користувач відкриває сторінку, сервер обробляє PHP-код, а потім надсилає результат обробки (не сам PHP-код) у браузер.
HTML та PHP досить просто об'єднати. Будь-яка частина PHP-скрипту за межами тегівігнорується PHP-компілятором і передається безпосередньо до браузера. Якщо подивитися на приклад, наведений нижче, можна побачити, що повний PHP-скрипт може виглядати наступним чином:
Привіт, сьогодні.