Php оптимизация программ на php
Частная коллекция качественных материалов для тех, кто делает сайты
- Фотошоп-мастер2000+ уроков по фотошопу
- Фото-монстр300+ уроков для фотографов
- Видео-смайл200+ уроков по видеообработке
- Жизнь в стиле «Кайдзен» Техники и приемы для гармоничной и сбалансированной жизни
В этом разделе помещены уроки по PHP скриптам, которые Вы сможете использовать на своих ресурсах.
Фильтрация данных с помощью zend-filter
Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.
Контекстное экранирование с помощью zend-escaper
Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.
Подключение Zend модулей к Expressive
Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.
Совет: отправка информации в Google Analytics через API
Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.
Подборка PHP песочниц
Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.
Совет: активация отображения всех ошибок в PHP
При поднятии PHP проекта на новом рабочем окружении могут возникнуть ошибки отображение которых изначально скрыто базовыми настройками. Это можно исправить, прописав несколько команд.
Агент
PHP парсер юзер агента с поддержкой Laravel, работающий на базе библиотеки Mobile Detect.
Php оптимизация программ на 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 не может работать с ООП также быстро как с обычными функциями. - Чем больше мерность массивов, тем медленнее они работают
Потеря времени возникает из-за обработки вложенности структур.
Оптимизация кода
Данные советы и факты дают незначительны по сравнению с предыдущей группой прирост скорости, но в своей совокупности эти приёмы могут дать неплохой выигрыш времени.
- echo и print значительно быстрее, чем printf
Разница во времени может доходить до нескольких тысячных секунды. Это вызвано тем, что printf служит для вывода форматированных данных и интерпретатор проверяет полностью строку на вхождение таких данных. printf используется только для вывода данных, которым нужно форматирование. - echo $var.»text» быстрее, чем echo «$var text»
Это вызвано тем, что движок PHP во втором случае вынужден искать переменные внутри строки. Для больших объёмов данных и старых версий PHP различия по времени заметны. - echo ‘a’ быстрее, чем echo «a» для строк без переменных
Это вызвано тем, что во втором случае движок PHP пытается найти переменные. Для больших объёмов данных различия во времени достаточно заметны. - echo ‘a’,’b’ быстрее, чем echo ‘a’.’b’
Вывод данных через запятую быстрее, чем через точку. Это вызвано тем, что во втором случае происходит конкатенация строк. Для больших объёмов данных различия во времени достаточно заметны. Примечание: это работает только с функцией echo, которая может принимать несколько строк в качестве аргументов. - $return=’a’; $return.=’b’; echo $return; быстрее, чем echo ‘a’; echo ‘b’;
Причина в том, что вывод данных требует некоторых дополнительных операций. Для больших объёмов данных различия во времени достаточно заметны. - ob_start(); echo ‘a’; echo ‘b’; ob_end_flush(); быстрее, чем $return=’a’; $return.=’b’; echo $return;
Это вызвано тем, что вся работа осуществляется без обращения к переменным. Для больших объёмов данных различия во времени достаточно заметны. Замечание: данный прием неэффективен, если вы работаете с AJAX, так как в этом случае данные желательно возвращать в виде одной строки. - Используйте «профессиональную вставку» или ?> a b быстрее, чем
Статические данные (вне программного кода) обрабатываются быстрее, чем вывод данных PHP. Этот прием называется профессиональной вставкой. Для больших объёмов данных различия во времени достаточно заметны. - readfile быстрее, чем file_get_contents , file_get_contents быстрее, чем require , а require быстрее, чем include для вывода статического контента из отдельного файла
По времени считывания пустого файла колебания от 0.001 для readfile до 0.002 для include . - require быстрее, чем include для интерпретируемых файлов
Замечание: при ветвлении алгоритма, когда есть возможность не использовать интерпретируемый файл, надо использовать include , т.к. require подключает файл всегда. - if (. ) <. >else if (. ) <> быстрее, чем switch
Время зависит от количества веток. - if (. ) <. >else if (. ) <> быстрее, чем if (. ) <. >; if (. ) <>;
Время зависит от количества веток и условий. Необходимо использовать else if везде, где это возможно, так как это самая быстрая «условная» конструкция. - Наиболее часто встречающиеся условия конструкции if (. ) <. >else if (. ) <> надо помещать в начале ветвления
Интерпритатор просматривает конструкцию сверху вниз, пока не найдет выполнение условия. Если интерпретатор находит выполнение условия, то остальныю часть конструкции он не просматривает. - x = sizeOf($array); for($i = 0; $i быстрее, чем for($i = 0; $i
Это вызвано тем, что во втором случае операция sizeOf будет выполнятся при каждой итерации. Время разницы выполнения зависит от числа элементов массива. - x = sizeOf($array); for($i = 0; $i быстрее, чем foreach($arr as $value) <. >для не ассоциативных массивов
Разница во времени значительна и увеличивается при увеличении массива. - preg _replace быстрее, чем ereg_replace , str_replace быстрее, чем preg_replace , но strtr быстрее, чем str_replace
Разница во времени зависит от объёма данных и может достигать нескольких тысячных секунд. - Функции работы со строками быстрее, чем регулярные выражения
Это правило является следствием предыдущего. - Удаляйте уже ненужные переменные-массивы для освобождения памяти.
- Старайтесь не использовать подавление ошибок @
Подавление ошибок производит ряд очень медленных операций, а так как частота повтора может быть очень большой, потери скорости могут быть значительными. - if (isset($str<5>)) <. >быстрее, чем if (strlen($str)>4)
Это вызвано тем, что вместо функции для работы со строками strlen используется стандартная операция проверки isset . - 0.5 быстрее, чем 1/2
Причина в том, что во втором случае выполняется операция деления. - return быстрее, чем global при возвращении значения переменной из функции
Это вызвано тем, что во втором случае создаётся глобальная переменная. - $row[‘id’] быстрее, чем $row[id]
Первый вариант быстрее в 7 раз. - $_SERVER[’REQUEST_TIME’] быстрее, чем time() для определения времени запуска скрипта
Причина в том, что в первом случае нет использования функции. - if ($var===null) <. >быстрее, чем if (is_null($var))
Причина в том, что в первом случае нет использования функции. - ++i быстрее, чем i++ , —i быстрее, чем i—
Это вызвано особенностями ядра PHP. Разница по времени менее 0.000001, но если у Вас данные процедуры повторяются тысячи раз, то присмотритесь к данной оптимизации. - Инкремент инициализированной переменой i=0; ++i; быстрее, чем не инициализированной ++i
Разница по времени около 0.000001 секунды, но из-за возможной частоты повтора следует помнить данный факт. - Использование «отработавших» переменных быстрее, чем объявление новых
Или перефразирую иначе – Не создавайте лишних переменных. - Работа с локальными переменными быстрее, чем с глобальными, примерно, в 2 раза
Хоть и разница во времени менее 0.000001 секунды, но из-за высокой частоты повторения следует стараться работать с локальными переменными. - Обращение к переменной напрямую быстрее, чем вызов функции, внутри которой определяется эта переменная в несколько раз
На вызов функции тратиться примерно в три раза больше времени, чем на вызов переменной.
Бесполезная оптимизация
Ряд методов оптимизации на практике не оказывают большого влияния на скорость выполнения скриптов (выигрыш времени менее 0.000001 секунды). Несмотря на это, такая оптимизация зачастую становиться предметом споров. Я привел данные «бесполезные» факты для того, чтобы вы в последующим не уделяли им особого внимания при написании кода.
- echo быстрее, чем print
- include(‘абсолютный путь’) быстрее, чем include(‘относительный путь’)
- sizeOf быстрее, чем count
- foreach ($arr as $key => $value) <. >быстрее, чем reset ($arr); while (list($key, $value) = each ($arr)) <. >для ассоциативных массивов
- Не комментированный код быстрее, чем комментированный, так как уходит дополнительное время на чтение файла
Весьма глупо уменьшать объём комментариев ради оптимизации, надо просто в рабочих («боевых») скриптах проводить минимизацию. - Переменные с короткими названиями быстрее, чем переменные с длинными названиями
Это вызвано сокращением объёмов обрабатываемого кода. Аналогично предыдущему пункту, надо просто в рабочих («боевых») скриптах проводить минимизацию. - Разметка кода с использованием табуляции быстрее, чем с использованием пробелов
Аналогично предыдущему пункту.
Напоследок, хочу раз напомнить, что приведённые мною советы и факты не абсолютны и значимость их применения зависит от конкретной ситуации. Необходимо помнить, что оптимизация скриптов лишь малая часть от всей процедуры оптимизации и зачастую возможно спокойно жить без вышеописанных советов.
Если у Вас возникли вопросы, то для скорейшего получения ответа рекомендуем воспользоваться нашим форумом
Оптимизация PHP скриптов
Отличие PHP от других языков программирования, например, C++, Pascal и т.д. заключается в том, что исходный код программы на php при каждом обращении к скрипту интерпретируется по-новой. Поэтому важно научиться правильно (оптимально) составлять код программ.
- используем короткие имена переменных (не более 4 символов)
- используем sizeof() вместо count()
- выносим определение размера массива за пределы цикла
- элементы масива с числовыми индексами лучше перебирать через for/while
- элементы ассоциативного масива лучше перебирать через foreach
- доступ к элементу одномерного ассоциативного массива по имени, не заключенному в кавычки, тормозит процесс на треть
- не создаем лишних переменных. Вместо $x=1; $y=2; $z=x+y; пишем $z=1+2
- выносите $переменные из «текстовых строк» и вместо echo » Итого: $cnt»; используйте echo ‘ Итого: ‘.$cnt;
- для чтения файла file() быстрее, чем fopen+цикл
PHP-код является интерпретируемым, поэтому каждый раз, при выполнении той или иной команды происходит ее разбор. Если количество кода велико, то и время, затраченное на его прочтение и интерпретацию тоже большое. Если использовать дозагрузку частей кода, то среднее время выполнения скрипта уменьшится.
Но, сделаю замечание, если есть определенный набор скриптов, который подключается гарантированно всегда (базовая библиотека), то их лучше всего объеденить в один файл. Это увеличит скорость их подключения.
Проведя ряд экспериментов, можно получить интересный результат: если в функцию передавать глобальные переменные в виде параметров функции, а не через директиву global, то работа локального участка кода php-скрипта увеличивается в 2 раза.
Чем меньше трафик от сервера к клиенту, чем быстрее загружаются страницы. Следующий эксперимент позволил ускорить работу php-скриптов в 4 — 20 раз! Действительно, впечатляющие показатели. Чтобы добиться такого ускорения, нужно использовать всего два оператора PHP:
- @ob_start(«ob_gzhandler»); — в самом начале скрипта.
- @ob_end_flush(); — в завершении скрипта.
Первая команда создает объект, в который перенаправляется вся информация после работы php-скрипта. Вторая команда отправляет содержимое буфера клиентскому приложению (браузеру) и удаляет буфер.
Если клиентское приложение поддерживает стандарты передачи-приема сжатой информации, то получаемая информация из буфера будет сжата, что сэкономит немного трафика и уменьшит время получения ответа от сервера.
HOWTO по оптимизации PHP
PHP очень быстрый язык программирования, но есть еще множество способов оптимизации, помимо оптимизации кода.
В этом материале мы объясним, почему оптимизация PHP захватывает собой гораздо больше факторов, нежели простая оптимизация кода, и почему настройка PHP требует понимания, каким образом работает PHP относительно других компонентов вашего сервера. Также мы займемся выявлением узких мест, связанных с этими компонентами и устранением их. Также мы затронем вопросы оптимизации ваших PHP скриптов, чтобы они работали еще быстрее.
Достижение высокой производительности
Когда мы говорим о хорошей производительности, мы не говорим о том, насколько быстро ваши скрипты будут запускаться. Производительность это набор компромисов между масштабируемостью и скоростью. Скрипты, настроенные, чтобы использовать минимум ресурсов, могут быть медленнее, чем скрипты, использующие кэширование, потомучто больше копий одного и того же скрипта может быть запущено одновременно на одном сервере.
В примере ниже, A.php спринтер настроен для быстрого запуска, а B.php бегун марафона может бегать трусцой, почти с той же самой скоростью. При низкой загрузке, A.php существенно быстрее, но как только трафик начинает увеличиваться, работа B.php снижается лишь немного, тогда как A.php выдыхается.
Давайте возьмем более реалистичный пример для дальнейших рассуждений. Предположим, нам необходимо написать скрипт, который должен прочитать файл размером 250 кб и сгенерировать HTML, резюмирующий информацию из файла. Мы пишем два сценария, которые делают одно и тоже: hare.php, который читает файл в память целиком и обрабатывает его за один проход, и tortoise.php, который читает файл построчно не сохраняя в памяти информации, больше чем одна строка. Tortoise.php будет медленнее, потомучто использует многократное чтение, требует большего количества системных вызовов.
Hare.php требует 0.04 секунды центрального процессора, а также 10 мб памяти. Tortoise.php требует 0.06 секунд процессорного времени и 5 мб памяти. Сервер располагает 100 мб свободной памяти и процессор на 99% свободен. Предположим, что никакой фрагментации памяти не происходит (для упрощения).
При 10 одновременных запусках скрипта, hare.php исчерпает память (10 х от 10 до 100). В этой точке, tortoise.php все еще будет иметь в своем распоряжении 50 мб свободной памяти. 11 запуск hare.php приведет к уменьшению производительности, поскольку система начнет использовать виртуальную память. При этом, его первоначальная скорость может упасть более чем в половину. Каждый запуск hare.php на данный момент занимает 0.08 секунд процессорного времени. Тем временем tortoise.php все также будет занимать свое процессорное время 0.06 секунд.
В таблице ниже, самый быстрый сценарий выделен полужирным:
Соединения | CPU секунды при запуске 1 скрипта | CPU секунды при запуске 10 скриптов | CPU секунды при запуске 11 скриптов |
Hare.php | 0.04 | 0.40 | 0.88 (свободная память закончилась) |
Tortoise.php | 0.06 | 0.60 | 0.66 |
Вышеприведенные примеры говорят нам о том, что тот, кто хочет получить высокую производительность не пишет просто быстрые скрипты. Для достижения высокой производительности PHP требуется хорошее понимание работы основных аппаратных средств, операционной системы и другого программного обеспечения, типа сервера и базы данных.
Узкие места
Пример hare и tortoise (зайца и черепахи) показал нам причины узких мест. С бесконечной оперативной памятью hare будет быстрее всегда, чем tortoise. К сожалению, вышеупомянутая модель слишком упрощена, и есть еще много других узких мест, препятствующих работе, помимо оперативной памяти:
Ваша сеть, вероятно, самое узкое место. Например, вы говорите, что у вас 10 Мбит связь с интернетом, по которой вы можете скачать 1 мб данных в секунду. Если каждая страница у вас занимает 33 кб, то обычные 33 страницы в секунду будут занимать весь ваш канал.
Более тонкие узкие места в сети это скорость отклика, например, сервера имен (DNS), или адресация нужного количества памяти для программного обеспечения сети.
Центральный процессор
Если вы контролируете загрузку центрального процессора, то увидите, что пересылка обычных HTML страниц вообще не будет обременять процессор, и, в данном случае, самым узким местом будет сеть. Однако, для сложных динамических web-страниц, производимых PHP, скорость вашего процессора будет ограничивающим фактором. Наличие нескольких процессоров или фермы серверов может значительно снизить подобное ограничение.
Shared Memory (общедоступная память)
Общедоступная память используется для связи между процессами, и хранит ресурсы, которые делятся между несколькими процессами, типа кэшированных данных и кода. Если общей памяти недостаточно, то любая попытка обратиться к ресурсам, использующим общую память, например, соединение с базой данных, или запуск кода, вызовет ошибку.
Файловая система
Доступ к жесткому диску может быть в 50-100 раз медленнее, чем доступ к данным в оперативной памяти. Кэширование файлов с использованием оперативной памяти могут снизить данное ограничение. Однако, в условиях небольшого количества памяти для системного кэша, работа будет замедляться. Системные файлы так же могут быть сильно фрагментированными, замедляя дисковый доступ. Частое использование симлинков на UNIX системах также приводят к замедлению.
Также печально известны установки поумолчанию для доступа к диску в Linux системах, которые настроены для совместимости, а не для скорости. Используйте команду hdperm, чтобы перенастроить параметры диска вашей Linux системы.
Управление процессами
В некоторых операционных системах, например, в Windows, создание нового процесса это медленная операция. Это означает, что CGI процесс, вызываемый для каждой операции, будет работать значительно медленнее. Запуск PHP в multi-threaded (в виде модуля) режиме должно увеличить скорость ответа (примечание: старые версии PHP неустойчивы в данном режиме).
Избегайте переполнения вашего сервера множеством ненужных процессов. Например, если ваш сервер предназначен только для обслуживания сети, избегайте запуска (или даже вообще установки) X-Windows. На Windows-системах избегайте запуска Microsoft Find Fast (компонент офиса), а также всякого рода screensaver’ов. Потомучто все это заканчивается 100% использованием процессора.
Некоторые программы вы можете рассмотреть к удалению, включая неиспользуемые сетевые протоколы, серверы почты, сканеры антивирусов, аппаратные драйверы для мыши, инфракрасного порта и так далее. На Unix: я подразумеваю, что вы общаетесь со своим сервером посредствам SSH. В этом случае, вы можете рассмотреть к удалению следующее:
- демоны, например, telnetd, inetd, atd, ftpd, lpd, sambad
- sendmail для поступающей почты
- portmap для NFS
- xfs, fvwm, xinit, X
Также вы можете отключить запуск некоторых программ при загрузке, изменяя файлы запуска, которые обычно хранятся в /etc/init* или /etc/rc*/init* директории.
Также рассмотрите задачи, которые запускаются по крону. Посмотрите, можно ли их удалить или перенести на непиковые периоды.
Соединение с другими серверами
Если ваш сервер требует услуг, выполняющихся на других серверах, это тоже может стать узким местом. Самый общий пример это медленный сервер базы данных, который обслуживает много сложных SQL запросов от разных серверов сети.
Когда начинать оптимизацию?
Многие говорят, что оптимизацию лучше отложить до тех пор, пока кодирование не будет закончено. Этот совет имеет смысл, только если вша группа программистов выдает код очень высокого качества и вы уже имеете хорошее чувство рабочих параметров вашего приложения. Иначе вы подвергаете себя риску необходимости переписывать существенные части приложения после проведения испытаний.
Мой совет преже чем начинать проектирование приложения, сделайте некоторые основные эталонные тесты аппаратных средств и программного обеспечения, чтобы получить чувство максимальной работоспособности, которую вы могли бы достигнуть. Тогда, когда вы проектируете и кодируете приложение, держите желательные рабочие параметры в памяти, потому что на каждом этапе пути вам придется идти на компромиссы между производительностью, функциональностью, защитой и гибкостью.
Также выберите хорошие испытательные данные. Если ваша база данных, как ожидается, будет хранить только 100 000 записей, избегайте тестирования ее только со 100 записями, вы будете потом об этом сожалеть. Это когда-то случилось с одним из программистов в моей компании: мы обнаружили медленный код значительно позже, потратив много времени впустую, поскольку пришлось переписать большую часть кода, который работал, но не масштабировался.
Настройка вашего сервера для PHP
Далее, мы рассмотрим с вами, как оптимизировать работу с PHP двух самых распространенных web-серверов, Apache 1.3 и IIS.
Разработчики PHP заявляют, что нет никакой разницы в скорости и преимуществах масштабирования при использовании Apache 2.0 над Apache 1.3, особенно, если PHP установлен в виде модуля.
Apache 1.3/2.0
Этот сервер доступен на Unix и Windows платформах, это самый популярный сервер в мире. Apache 1.3 использует pre-forking (предразветвления) модель для обслуживания сети. После старта, сервер создает дочерние процессы для обслуживания каждого HTTP запроса. Родительский процесс действует как ангел-хранитель, проверяя, что все дочерние процессы работают правильно и координирует их действия. Чем больше HTTP запросов, тем больше дочерних процессов будет порождено, чтобы их обработать. Поскольку HTTP запросы начнут замедляться, родительский процесс уничтожает неактивные дочерние процессы, освобождая ресурсы для новых процессов. Красота данного подхода в том, что это делает Apache чрезвычайно устойчивым. Даже если дочерний процесс рушится, родительский и другие дочерние процессы будут изолированы от сбойного дочернего процесса.
Модель предразветвления не настолько быстра, как другие решения. Но, что касается меня, то это является суматохой ни о чем, на сервере, обслуживающем PHP сценарии, потомучто другие узкие места дадут сбой раньше, чем проблемы Apache станут существенными для сервера. Ошибкоустойчивость и надежность Apache более важный фактор.
Apache 2.0 может работать в модульном режиме (multi-threaded). Мои эталонные тесты показали, что преимуществ этого режима не так уж много. Также будте готовы к тому, PHP расширения несовместимы, например GD и IMAP. Проверено на Apache 2.0.47 (23 октября 2003).
Apcahe сконфигурирован при помощи файла httpd.conf. Следующие параметры особенно важны при настройке дочерних процессов:
Параметр | Поумолчанию | Описание | |||||||||||||||||||||||||||||||
MaxClients | 256 | ||||||||||||||||||||||||||||||||
StartServers | 5 | ||||||||||||||||||||||||||||||||
MinSpareServers | 5 | ||||||||||||||||||||||||||||||||
MaxSpareServers | 10 | ||||||||||||||||||||||||||||||||
MaxRequestsPerChild |
Параметр | Поумолчанию | Описание | ||||||||||||||||
SendBufferSize | Определяется операционной системой. | |||||||||||||||||
KeepAlive [on|off] | On | |||||||||||||||||
KeepAliveTimeout | 15 | |||||||||||||||||
MaxKeepAliveRequests | 100 | |||||||||||||||||
TimeOut | 300 | |||||||||||||||||
LimitRequestBody |
Настройка производительности исходя из обращений к серверу в день. | |||||||||||||
Управление полосой пропуска | |||||||||||||
Управление процессом | |||||||||||||
HTTP компрессия |
MemCacheSize | |
MaxCachedFileSize | |
ObjectCacheTTL | |
MaxPoolThreads | |
ListenBackLog | 20.09.2010, 15:39 |
Как проверить степень нагрузки кода на сервер php? Распределение нагрузки на сервер Работа скрипта — уменьшение нагрузки на сервер Снижение нагрузки на сервер сайта за счёт использования ajax Оптимизация нагрузки на сервер |
|
20.09.2010, 15:47 | 2 |
Оптимизация бывает, грубо говоря, двух типов: оптимизировать код, и оптимизировать логику. Одним словом: руками. |
|
20.09.2010, 15:50 | 3 |
Решение
Было: if (strlen($foo) Добавлено через 2 минуты и вот Оптимизация PHP-кодаСегодня я хотел бы рассказать о том, как оптимизировать PHP-код. Безусловно, всех способов я сейчас не напишу, но кое-какие интересные примеры того, как можно неплохо ускорить время выполнения PHP-скрипта, я покажу. Правило №1: Старайтесь не использовать длинные переменныеДействительно, если длина имени переменной больше 4-х символов, то скорость выполнения начинает падать. Особенно это заметно при длине от 8-ми символов. Правило №2: Старайтесь не использовать цикл foreachЦикл foreach используйте только для перебора ассоциативных массивов, а для всех остальных случаев жизни используйте только for или while. Выигрыш в скорости 25-30%. Правило №3: Старайтесь переменные выносить за пределы кавычекДавайте разберём такой код: Если проверить скорость выполнения, то можно заметить, что присвоение $y идёт примерно на 20% медленее, чем присвоение переменной $z. Особенно это актуально, если вместо переменной $x поставить элемент двумерного массива. Это были 3 правила по оптимизации PHP-кода. Если я буду обнаруживать ещё какие-то интересные моменты, то обязательно напишу 2-ю часть этой статьи. Было бы очень здорово, если бы Вы в комментариях написали ещё какие-нибудь способы оптимизировать PHP-код. Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)! Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov. Если Вы не хотите пропустить новые материалы на сайте, Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы. Порекомендуйте эту статью друзьям: Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте): Она выглядит вот так: Комментарии ( 4 ):Интерпретатор быстрее обрабатывает одиночные кавычки (поскольку передаваемый текст не изменяется) чем двойные. Пример: $v=7; echo ‘Саше исполнилось ‘ . $v . ‘лет’; быстрее чем echo «Саше исполнилось $v лет»; Касательно правила №1 по поводу длины имени переменных. Дело в том, что короткие имена крайне затрудняют в дальнейшем как понимание так и исправление возможных ошибок. И имеет смысл вначале делать все-таки максимально понятные имена, а когда надобность в отладке программы отпадет заменить их на более короткие для ускорения кода. Неплохо было бы еще услышать пару советов, как оптимизировать запросы к базе данных. ) Да, неплохая тема для статьи, обязательно освещу. Спасибо! Для добавления комментариев надо войти в систему. Copyright © 2010-2020 Русаков Михаил Юрьевич. Все права защищены. Спортивные секции и клубы
|