Статьи

Для своего сайта решил сделать красивые урлы, вроде как и для SEO лучше, да и для глаза приятней смотреть на красивые урлы. Как известно в symfony достаточно прописать в файле routing.yml желаемые урлы и все, но для symfony 1.1.4 это не очень помогло, тогда пришло в голову сделать так:

Хранилище данных Falcon

Автор: Павел Пушкарев, paulus (at) sqlinfo (dot) ru

В сервере MySQL версии 5.2 появился новый вид хранилища данных — Falcon. Эта статья является обзором нового вида хранилища. В ней будут обсуждены его достоинства, недостатки и возможности.

Введение

По данным Netcraft, Apache — самый популярный веб-сервер в интернет, он обслуживает множество серверов и сайтов. Часто возникает необходимость увеличить производительность веб-сервера. Наверное лучший способ это сделать — перейти к схеме frontend+backend, но это может потребовать достаточно серьезных изменений в приложении (например, у вас наверняка отвалятся всяческие индикаторы прогресса аплоада файлов).

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

Этот перевод я прочел на хабре, где автор (Joe Stagner) рассказывает как он добился профессионального положения и положения в обществе разработчиков. ИМХО, есть что подчерпнуть из его жизни.

(перевод, оригинал: thecodist.com — All I Need To Know To Be A Better Programmer I Learned In Kindergarten).

Программирование — сложная штука, но многие из принципов, которые делают программиста лучше, не слишком отличаются от того, чему нас учили тети-воспитательницы.

Автор: Peter, Percona
Перевод: Vladimir Rusinov

Существует значительная часть проектов, которые используют MyISAM и задаются вопросом, стоит ли им перейти на InnoDB, или же лучше продолжить использовать MyISAM?

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

Обзор InnoDB

InnoDB — один из почти десятка доступных движков для MySQL, и вот его основные достоинства:

• Скорость:
  • построчные блокировки (а не целых таблиц как в InnoDB)
  • эффективное использование CPU, памяти и i/o
  • эффективные индексы
• Стабильность и целостность:
  • автоматическое восстановление после сбоев
  • транзакции и ссылочная целостность
  • возможен онлайн бекап с помощью InnoDB Hot Backup
  • хороший, протестированный код
• Проверенность:
  • распространяется в составе MySQL с 2001 года
  • широко используется в различных крупных проектах

Эту статью я прочитал на simplecoding.org и призадумался. В большинстве web приложений, которых я видел, не производят проверку на длину входях данных. Слабое место это все, что связано с личными данными пользователя, авторизация, регистрация, восстановление пароля от учетной записи etc.

SQL-инъекции (SQL-injection) на сегодняшний день остаются наиболее обсуждаемыми проблемами безопасности web приложений.

В тоже время, другие уязвимости SQL запросов, например, связанные со слишком длинными входными данными, обычно игнорируются, хотя могут привести ко всем видам проблем безопасности.

Уязвимости в различных CMS, форума etc отходят и найти банальную SQL-injection, RFI, LFI или XSS довольно таки сложно, а если обновления выходят незамедлительно, практически сводятся к нулю. В таком случае необходимо искать баги уже в программном обеспечении. Иногда при удачной эксплуатации баги в интерпретаторе бывает достаточно чтобы провести vendor:)

Проект Suhosin

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

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

И снова приветствую вас.
В этой (последней) части статьи я расскажу про установку и настройку дополнительных сервисов, таких как Apache и MySQL, а так же, PHP, его различные модули и Zend Optimizer.
Действия, описанные здесь, уже могут выполняться с использованием удалённого доступа (SSH), не имея физического доступа к серверу.
Итак, начнём.

Снова приветствую вас.
В этой части статьи рассказано про конфигурацию ядра и загрузчика системы (на примере ветки 6.x с архитектурой i386; конфигурация других систем будет аналогичной).
Для конфигурации ядра и загрузчика крайне желательно иметь физический доступ к серверу, т.к. в случае, если что-то пойдёт не так как должно, чтобы была возможность восстановить работоспособность системы. Крайне не советую использовать удалённый (SSH) доступ выполняя описанные в статье действия.
Конфигурация ядра — процесс продолжительный. Время, которое уйдёт на компиляцию, напрямую зависит от частоты процессора. Например, с процессором Pentium III, частотой 733МГц, процесс компицялии занимает примерно от получаса до 40 минут. Интернет при этом не используется, так что сеть можно смело отключить (временно).
Итак, начнём.

Приветствую!
Сегодня я расскажу про настройку веб сервера на базе ОС FreeBSD 6.x/7.x
Для экспериментов можно использовать виртуальную машину, вместо компьютера. В дальнейшем можно будет полностью настроенную систему перенести на винчестер будущего сервера.
Сразу оговорюсь, что процесс установки системы занимает меньше получаса даже на Pentium II с 128МБ ОЗУ, однако настройка системы процесс достаточно долгий и требует участия человека. Так что, расчитывайте своё время. Так же, желательно иметь быстрый безлимитный интернет, т.к. в общей сложности прийдётся скачать более 200МБ (не считая саму систему).
Итак, начинаем

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

Сеть

Пожалуй, самое узкое место любого крупного веб-ресурса — это сеть. Представим картину — сервер с каналом 10Мбит/с и страница, размером в 10КБ. Такой сервер сможет обработать чуть больше 100 запросов в секунду (учитывая HTTP заголовки). Избегайте в вебсервере и в скриптах лишней работы с сетью.
Настоятельно рекомендую выключить опцию HostNamesLookup в настройках Apache. При этом сервер будет в логи записывать IP адреса клиентов, не пытаясь получить обратную DNS запись для них (имя хоста).
Так же, порой, лучше применять сжатие (GZIP, Deflate) для передаваемых страниц. В случае с хорошим процессором и медленной сетью, это существенно поднимет производительность.
P.S. Избегайте работы с базами данных по сети (для этого есть опция skip-networking в конфигурационном файле MySQL). Работа с базой должна происходить через UNIX Socket.

Процессор

Процессор для сервера нужно выбирать исходя из типа его загрузки. Если запускается много разных процессов (или потоков) Apache, которые более или менее равномерно нагружают процессор, то в такой ситуации себя лучше покажет многоядерный процессор и система сконфигурированная с SMP. Если наблюдается иная картина — один процесс (например, MySQL) нагружает процессор на 80% и более — то в такой ситуации лучше себя покажет одноядерный процессор, т.к. у него частота больше, чем у одного ядра двухъядерного процессора, а система не сможет распараллелить один процесс между ядрами.
 

Оперативная память

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

Настройки веб сервера

Первое, и самое главное — веб сервер должен работать только в StandAlone режиме. Забудьте про inetd для веб сервера. При inetd режиме серверу приходится каждый раз читать конфигурации и т.п., на что уходит достаточно много драгоценного процессорного времени. Так же, существенно поднимает производительность использование Keep-Alive режима. При этом несколько HTTP запросов могут обрабатываться сервером в пределах одного соединения с клиентом. Т.е. не нужно будет тратить время на установку нового соединения для каждого запроса.
Некоторые параметры Apache:
MaxClients — максимальное количество одновременно обрабатываемых запросов.
StartServers — количество процессов сервера, запускаемых при его включении.
MinSpareServers — устанавливает желательное минимальное число неиспользуемых дочерних процессов сервера.
MaxSpareServers — устанавливает желательное максимальное число неиспользуемых дочерних процессов сервера. Если запущено больше чем MaxSpareServers неиспользуемых процессов, то родительский процесс убьет лишние.
MaxRequestsPerChild — максимальное количество запросов, которое может обработать один процесс (после чего он будет перезапущен).
KeepAlive — включает или выключает поддержку Keep-Alive соединений.
KeepAliveTimeout — время в секундах, по истечению которого соединение Keep-Alive будет прервано (при неактивности клиента).
MaxKeepAliveRequests — максимальное количество запросов, которое может быть обработано в пределах одного Keep-Alive соединения.
TimeOut — таймаут неактивности (в секундах). Соединение с сервером будет прервано, если за это время не было передано ниодного байта ни в одну сторону.
 

Настройки PHP

Для начала, необходимо правильно настроить memory_limit — ограничение памяти для скрипта. Как правило, редко нужно больше 16МБ памяти для одного скрипта. Ограничение времени работы скрипта (max_execution_time) служит, в основном, для предотвращения зацикливаний в скриптах. Разумно было бы оставить стандартное значение в 30 секунд, а в скриптах, которые должны работать дольше — вручную задать новый лимит функцией set_time_limit().
С осторожностью стоит относиться к безопасному режиму (safe_mode) и open_basedir. При правильно настроенном веб сервере (с разграничением пользователей) эти настройки не нужны, а скорее и наоборот, мешать будут. А если все скрипты выполняются от одного имени, то open_basedir можно обойти и получить доступ к чужим файлам. Т.к. при условии что скрипты выполняются от разных пользователей, никто не сможет сделать в системе ничего большего, чем то, на что у него есть права. Классическим примером разделения пользователей является mpm_itk в Apache 2.x.
Есть ещё один интересный параметр — disable_functions, служит для запрета вызова тех или иных функций. Это уже на ваше усмотрение. Лично я предпочёл оставить этот параметр пустым. Не вижу смысла запрещать пользователям функции, если скрипты выполняются от их имени.
magic_quotes… Сколько о них разговоров было. В принципе, для граммотно написанного скрипта этот параметр ничего не меняет. magic_quotes_gpc автоматически экранирует «опасные символы» в параметрах, переданных скрипту от клиента, magic_quotes_runtime — экранирует «опасные символы» при чтении данных из внешних источников (файлы, сокеты, база данных). Крайне советую избегать этой функции в PHP.
output_buffering — тоже интересная настройка. Указанное здесь количество байт будет буфферизироваться перед отправкой клиенту. Оптимальное значение — 2048-4069 байт.
expose_php — указывает на необходимость передавать в HTTP заголовках информацию о том, что страница сгенерирована с помощью PHP. По умолчанию включен, однако я предпочёл выключить передачу этой информации. На производительность и безопасность, в общем, не влияет.
error_reporting — уровень вывода предупреждений и ошибок. По умолчанию равен E_ALL&~E_NOTICE, т.е. выводятся все ошибки, кроме Notice (думаю, что логический опреатор «И НЕ» знаком всем...). Для продуктивных целей и лучшей безопасности лучше отключить вывод всяческих ошибок, однако сохранять ошибки в лог. Я, например, использую syslog для этого.
register_globals — регистрировать ли в скрипте переданные параметры как переменные? Отрицательный ответ напрашивается сам собой. Это может нарушить безопасность скриптов (однако, если скрипт написан граммотно, то этот параметр ни на что не влияет). Но, на удивление, многие скрипты написаны таким образом, что требуют, чтобы эта функция была включена...
Касаемо других оптимизаций — крайне желательно использовать оптимизаторы для PHP, такие как eAccelerator, Zend Optimizer и другие. Самым популярным является Zend Optimizer. Тесты производительности я не проводил.
 

Оптимизации PHP кода

Много статей было на эту тему… Выделю самое главное, на чём реально можно поднять производительность и то, что меньше всего описанного в других статьях влияет на производительность.
Первое, что я хочу выделить:
1) Необходимо задавать максимальное количество проходов цикла for до цикла, а не во время его выполнения. В противном случае, как на примере, функция strlen() будет вызвана 20 раз:
 

$str = 'abcdefghijklmnopqrst';
for ($i = 0; $i < strlen($str); $i++) echo ord($str[$i])." ";

Правильнее было бы делать так:

$str = 'abcdefghijklmnopqrst';
$n = strlen($str);
for ($i = 0; $i < $n; $i++) echo ord($str[$i])." ";

Если, конечно, в цикле не меняется исходная строка...
2) По возможности, стоит избегать регулярных выражений. Стандартные функции работы со строками работают гораздо быстрее. Но при необходимости регулярных выражений, стоит использовать PCRE вместо POSIX. Причин на то две — они работают быстрее и безопасны для обработки бинарных данных.
3) Не следует использовать лишние переменные, там где они не нужны. Например:

$sql = "SELECT `a`,`b`,`c` FROM `table` WHERE `b` IN ('1','2','3')";
$q = mysql_query($sql);

Гораздо разумнее было бы сделать так:

$q = mysql_query("SELECT `a`,`b`,`c` FROM `table` WHERE `b` IN ('1','2','3')");

Если, конечно, не нужно после запроса выводить его.
4) Очищайте память от ненужных переменных вызовом unset(). Используйте mysql_free_result() для очистки памяти после SQL запроса (вызов этой функции можно опустить, если это конец скрипта, т.к. после выполнения скрипта память освобождается автоматически).
5) Никогда не используйте конструкции вида $array[index] (если index — не константа, а название индекса массива). Подобные конструкции замедляют код и вызывают ошибки Warning...
Следующие пункты незначительно влияют на оптимизации
1) echo быстрее, чем print. Полностью согласен, т.к. print — это функция и ей нужно дополнительное время для возвращения результата выполнения. Однако, сильно на производительность это не влияет. И, кроме этого, желательно вызывать echo один раз при отдаче данных клиенту, а до этого собирать данные в строку.
2) Конструкции вида echo $var.' some string'; работают немного быстрее, чем echo "$var some string";
Так же, строки, заключённые в одинарные кавычки обрабатываются немного быстрее, чем в двойных кавычках, т.к. PHP не выполняет поиск переменных и спец. символов (\r \n \t \0 и символов в виде \x[NN], где [NN] — шестнадцатеричный код символа). Больше всего это касается старых версий PHP. На мой взгляд, здесь выиграш процессорного времени будет минимальным.
3) Подавление ошибок символом @ в коде медленнее, чем error_reporting(0). В общем, вполне разумный совет и по другим причинам. Не нужно задумываться, какие строки в коде могут вызвать ошибку (например, fopen при попытке открыть на чтение несуществующий файл или fsockopen при таймауте).
4) Прединкремент и декремент выполняются немного быстрее, чем постинкремент и декремент, соответственно.
5) Пожалуй, самый нелепый приём оптимизации, который я встречал.

if (strlen($foo) < 5) { echo "Foo is too short"; }

медленнее, чем

if (!isset($foo{5})) { echo "Foo is too short"; }

Может, второй вариант и будет работать быстрее, но и код скрипта должен быть читаемым… Без комментариев, думаю...
Несколько приёмов, которые можно делать при запуске скрипта:
error_reporting(0); — выключить вывод ошибок (или задать новый уровень вывода ошибок).
set_time_limit(0); — убрать ограничение по времени для скрипта (если скрипт должен выполняться долго). Однако, не стоит злоупотреблять этим. Лучше расчитать по максимуму, сколько скрипт может выполняться и задать нужный лимит. Это не даст положить сервер в случае случайного зацикливания в скрипте.
ini_set('memory_limit','-1'); — выключить лимит памяти для скрипта. Так же, вместо -1 можно задать выделенный объём памяти с суффиксами K и M (килобайты и мегабайты, соответственно)
set_magic_quotes_runtime(0); — выключить magic_quotes_runtime в пределах одного скрипта.
ignore_user_abort(1); — предотвратит прекращение выполнения скрипта, в случае если пользователь остановил загрузку страницы. Весьма полезная вещь, т.к. бывает нужно, чтоб скрипт отработал до конца, записал все данные в логи, удалил все временные файлы и т.п.
Так же, против magic_quotes_gpc можно использовать такой код: 

if(get_magic_quotes_gpc() || (ini_get("magic_quotes_sybase") && (strtolower(ini_get("magic_quotes_sybase")) != "off"))) {
    $_GET = array_map("stripslashes",$_GET);
    $_POST = array_map("stripslashes",$_POST);
    $_COOKIE = array_map("stripslashes",$_COOKIE);
}

Если через GPC не передаются массивы. В противном случае, можно использовать array_walk_recursive (доступно только в PHP5) или написать свою маленькую функцию, для рекурсивной обработки элементов массива.

За сим, пожалуй, всё. Желаю удачи в ваших веб разработках.
С вами был Eugen && gibson. 

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