Знайшов НЕ Хабрахабр просто чудову статтю по оптимізацію PHP.
Одним з основних критеріїв успішності будь-якого інтернет-ресурсу є швидкість його роботи і з кожним роком користувачі стають все більш і більш вимогливими за цим критерієм. Оптимізація роботи php-Скіпт - це один з методів забезпечення швидкості роботи системи.
У цій статті я б хотів представити на суд громадськості свою збірку порад і фактів щодо оптимізації скриптів. Збірник збирався мною досить довго, заснований на декількох джерелах і особистих експериментах.
Чому збірка порад і фактів, а не жорстких правил? Тому що, як я переконався, не існує «абсолютно правильною оптимізації». Багато прийоми і правила суперечливі і виконати їх всі неможливо. Доводиться вибирати сукупність методів, якими прийнятно користуватися без шкоди безпеці і зручності. Я зайняв рекомендаційну позицію і тому у мене поради і факти, які Ви можете дотримуватися, а можете і не дотримуватися.
Що б не було плутанини, я розділив всі поради і факти на 3 групи:
- Оптимізація на рівні логіки і організації додатки
- оптимізація коду
- Не корисна оптимізація
Групи виділені умовно і деякі пункти можна віднести відразу до кількох із них. Цифри наведені для середньостатистичного сервера (LAMP). У статті не розглядаються питання пов'язані з ефективністю різних сторонніх технологій і фреймворків, так як це тема окремих дискусій.
Оптимізація на рівні логіки і організації додатки
Багато з рад і фактів, що відносяться до цієї групи оптимізації, є вельми значущими і дають досить великий виграш у часі.
- Постійно профілюють свій код на сервері (xdebug) і на клієнті (firebug), що б виявити вузькі місця коду
Слід зазначити, що профілювати треба і серверну, і клієнтську частину, так як не всі серверні помилки можна виявити на самому сервері. - Кількість, використовуваних в програмі призначених для користувача функцій, ніяк не впливає на швидкість
Це дозволяє використовувати в програмі незліченну кількість призначених для користувача функцій. - Активно використовуйте для користувача функцій
Позитивний ефект досягається за рахунок того, що всередині функцій операції ведуться тільки з локальними змінними. Ефект цього більше, ніж витрати на виклики для користувача функцій. - «Критично важкі» функції бажано реалізувати на сторонньому мови програмування у вигляді розширення PHP
Це вимагає навичок програмування на сторонньому мовою, що значно збільшує час розробки, але в той же час дозволяє використовувати прийоми поза можливості PHP. - Обробка статичного файлу html швидше, ніж інтерпретується файлу php
Різниця повремени на клієнті може становити близько 1 секунди, тому має сенс чіткий поділ статики і генеруються засобами PHP сторінок. - Розмір оброблюваного (підключається) файлу впливає на швидкість
Приблизно на обробку кожних 2 КБ витрачатися 0.001 секунди. Цей факт штовхає нас на проведення мінімізації коду скриптів при перенесенні на робочий сервер. - Намагайтеся не використовувати постійно require_once або include_once
Ці функції потрібно використовувати при наявності можливості повторного зчитування файлу, в інших випадках бажано використовувати require і include. - При розгалуженні алгоритму, якщо є конструкції, які можуть не оброблятися і їх обсяг близько 4 КБ і більше, то більш оптимально їх підключати за допомогою include.
- Бажано використовувати перевірку даних, що відправляються на клієнті
Це викликано тим, що при перевірці даних на стороні клієнта, різко знижується кількість запитів з невірними даними. Системи перевірки даних на клієнті будуються в основному з використанням JS і жорстких елементів форми (select). - Бажано великі конструкцій DOM для масивів даних будувати на клієнті
Це дуже ефективний метод оптимізації при роботі з відображенням великого обсягу даних. Суть його зводиться до наступного: на сервері готується масив даних і передається клієнтові, а побудова конструкцій DOM надається JS функцій. В результаті навантаження частково перерозподіляється з сервера на клієнт. - Системи, побудовані на технології AJAX, значно швидше, ніж системи, які не використовують цю технологію
Це викликано зменшенням обсягів виведення і перерозподілом навантаження на клієнта. На практиці швидкість систем з AJAX в 2-3 рази вище. Зауваження: AJAX в свою чергу створює ряд обмежень на використання інших методів оптимізації, наприклад, робота з буфером. - При отримання post-запиту завжди повертайте що-небудь, можна навіть пробіл
Інакше клієнту буде відправлена сторінка помилки, яка важить кілька кілобайт. Дана помилка дуже часто зустрічається в системах, що використовують технологію AJAX. - Отримання даних з файлу швидше, ніж з БД
Це багато в чому викликано витратами на підключення до БД. На мій подив, величезний відсоток програмістів маніакально зберігають всі дані в БД, навіть коли використання файлів швидше і удобнее.Замечаніе: в файлах можна зберігати дані, по яким не ведеться пошук, в іншому випадку слід використовувати БД. - Чи не здійснюйте підключення до БД без необхідності
З невідомої мені причини, багато програмістів здійснюють підключення до БД на етапі зчитування налаштувань, хоча далі вони можуть не робити запитів до БД. Це шкідлива звичка, яка коштує в середньому 0.002 секунди. - Використовуйте постійне з'єднання з БД при малій кількості одночасно активних клієнтів
Вигода в часі викликана відсутністю витрат на підключення до БД. Різниця в часі приблизно 0.002 секунди. Зауваження: при великій кількості користувачів постійні з'єднання використовувати небажано. При роботі з постійними сполуками повинен бути механізм завершення з'єднань. - Використання складних запитів до БД швидше, ніж використання декількох простих
Різниця в часі залежить від багатьох факторів (обсяг даних, налаштування БД та ін.) І вимірюється тисячними, а іноді навіть сотими, секунди. - Використання обчислень на стороні СУБД швидше, ніж обчислення на стороні PHP для даних зберігаються в БД
Це викликано тим фактором, що для таких обчислень на стороні PHP потрібно два запити до БД (отримання і зміна даних). Різниця в часі залежить від багатьох факторів (обсяг даних, налаштування БД та ін.) І вимірюється тисячними і сотими секунди. - Якщо дані вибірки з БД рідко змінюються і до цих даних звертається безліч користувачів, то має сенс зберегти дані вибірки в файл
Наприклад можна використовувати наступний простий підхід: отримуємо дані вибірки з БД і зберігаємо їх як серіалізовані масив в файл, далі будь-який користувач використовує дані з файлу. На практиці такий метод оптимізації може дати багаторазовий приріст швидкості виконання скрипта. Зауваження: При використанні даного методу потрібні писати інструменти для формування та зміни даних, що зберігаються файлі. - Кешуйте дані, які рідко змінюються, за допомогою memcached
Виграш часу може бути досить значним. Зауваження: кешування ефективно для статичних даних, для динамічних даних ефект знижується і може бути негативним. - Робота без об'єктів (без ООП) швидше, ніж робота з використанням об'єктів, приблизно, в три рази
Пам'яті «з'їдається» також більше. На жаль, інтерпретатор PHP не може працювати з ООП також швидко як зі звичайними функціями. - Чим більше мірність масивів, тим повільніше вони працюють
Втрата часу виникає через обробку вкладеності структур.
оптимізація коду
Дані поради і факти дають незначні в порівнянні з попередньою групою приріст швидкості, але в своїй сукупності ці прийоми можуть дати непоганий виграш часу.
Не корисна оптимізація
Ряд методів оптимізації на практиці не мають великого впливу на швидкість виконання скриптів (виграш часу менш 0.000001 секунди). Незважаючи на це, така оптимізація часто ставати предметом суперечок. Я навів дані «непотрібні» факти для того, щоб ви в наступним не приділяли їм особливої уваги при написанні коду.
Наостанок, хочу раз нагадати, що наведені мною поради і факти не абсолютні і значимість їх застосування залежить від конкретної ситуації. Необхідно пам'ятати, що оптимізація скриптів лише мала частина від всієї процедури оптимізації і часто можливо спокійно жити без вищеописаних рад.