Работа для программистов » PHP http://job-interview.ru/articles вакансии, вопросы, статьи Thu, 29 Mar 2012 20:53:41 +0000 http://wordpress.org/?v=2.8 en hourly 1 Разработка в среде WEB: Java или PHP? http://job-interview.ru/articles/post/356 http://job-interview.ru/articles/post/356#comments Tue, 28 Feb 2012 18:31:26 +0000 /articles/?p=356 Вместо предисловия.

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

Начнем.

WEB развивается уже второй десяток лет. Время статичных HTML-страниц кануло в истории, на смену которому пришел абстрактный стандарт WEB2, главное требование которого – взаимодействие с пользователем. Спорить, правильно ли это, конечно, можно, только в таком случае появляется вполне резонный вопрос: зачем читать эту статью, если она о средствах создания подобных сервисов?

Порог вхождения.

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

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

PHP считается простым языком. Это не удивительно: от открытия учебника до первого “HelloWorld-a” проходит не больше 5 минут. С одной стороны это хорошо. Но подводных камней не мало.

Потратив неделю на изучение PHP, можно научиться базовым приемам ввода-вывода, примитивной выборке из БД и парочке других алгоритмов обработки информации. С усложнением задач появляется соблазн изобретать “велосипеды” и “костыли” на основе старых знаний, делая код нечитабельным, уничтожая возможность дальнейшей поддержки на корню.

Работа с таким “кодером” в команде, или еще хуже, поддержка проекта, написанного им, превращается в будни школьного учителя. Естественно, это утверждение относится не ко всем, но такая проблема существует.

Что касается Java, порог вхождения очень высокий. Вместо “Установка LAMP под Ubuntu” и “Скачать самоучитель PHP“, необходимо вникнуть в сервлеты, взаимодействие между ними, jsp, научиться работе с каким-нибудь фреймворком.

Плюс ООП, который в Java обязателен. Если проводить аналогию, начало работы сравнимо с высшей математикой в ВУЗ-е: всех неспособных отправить на службу родине.

Подобный подход к оценке языка не панацея. Достаточно много серьезных проектов, написанных на PHP. Более того, на данный момент в сфере WEB-разработок он доминирует.

Синтаксис и код.

Одна из обсуждаемых проблем Java – длиннейшие названия классов и стандартных методов. Чего только стоит “System.out.println()” оного вместо “echo” на PHP. Конечно, это легко решается “import-ом” в начале документа или выбором современной IDE, в которой достаточно написать первую букву метода или поля, как появится возможность выбора нужного из списка. Тем не менее, отрицать впечатляющий объем кода на Java – предвзято.

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

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

Здесь принудительное ООП Java и Javadoc для документации дают ощутимый прирост в копилке аргументов “За Java”.

В PHP эти возможности так же есть. Сравнительно недавно я узнал о аналогах Javadoc в PHP- phpdoc/PhpDocumentor.

С известных версий PHP поддерживает объектный подход(ООП). Правда он смешанный, и соблазн написать простую функцию без обертки очень большой.

Техническая площадка.

С кодом мы разобрались. А вот что касается хостинга, Java в проигрыше. PHP-хостинг распространен и он дешевле.

Правда под вопросом, стоит ли экономить на хостинге, если проект серьезный? Тем не менее, то, что заменить техническую основу проекта на PHP проще – факт.

Другой вопрос, если проект используется в интрасети. Стоимость хостинга отпадает. И программирование на стороне клиента дает плюс в сторону Java. Интеграция апплетов на нем в сети интернет потерпела крах, так как для запуска они требуют имплементатор на локалхосте. Но когда клиенты доступны физически, проблем нет.

Единая платформа, без связки разных языков – очевидный плюс.

Вместо заключения.

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

Претензий на объективность у меня нет. Я попытался, насколько успешно- не знаю. Буду рад аргументированной критике.

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

]]> http://job-interview.ru/articles/post/356/feed 513 Ускоряем проект на Symfony через nginx+memcached http://job-interview.ru/articles/post/300 http://job-interview.ru/articles/post/300#comments Wed, 23 Feb 2011 15:11:09 +0000 /articles/?p=300

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

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

В этой статье я постараюсь описать минусы кэширования в Symfony и приемы их обхода.

Представьте ситуацию, когда есть страница, на которой данные могут меняться только раз в 1-2 суток, тогда мы смело можем ее закэшировать на 24 часа. В Symfony это делается очень просто установкой параметров в файле cache.yml для модулей:

enabled: true
with_layout: true
lifetime: 86400

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

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

Проблема в том, что блок с последними комментариями может обновиться как через минуту, так и через 2-3 часа, поэтому кэшировать всю страницу мы не можем, т. к. не понятно какое время жизни выставлять для кэша. Вообще это типичный случай, когда следует применять блочное кэширование, т. е. делим страницу на блоки (или компоненты в Symfony), каждому блоку задаем свои параметры кэширования.

Но такой тип кэширования далек от идеала, т. к. в этом случае Symfony придется выполнить большую часть своего кода. Код исполняется, как обычно, просто перед выполнением каждого блока будет проверка на наличие блока в кэше и, если он там есть и время жизни не истекло, то вместо выполнения этого блока будет просто вставлен html-код из кэша.
При таком блочном кэшировании будет исполняться код Symfony при каждом http-запросе, кроме того, будет как минимум один запрос к базе данных, если пользователь авторизован – Symfony получает данные о пользователе из базы еще до подключения блоков.

Однако, есть другой способ применения кэширования для случая, описанного выше. Для этого нам понадобится (я также привожу описание установки нужного ПО, для тех, кому оно понадобится, все примеры я проверял у себя на Linux SUSE 11.3):

  • Nginx в качестве web-сервера

    Как установить и настроить Nginx

  • Фреймворк Symfony

    Как установить Symfony и настроить связку Nginx+Symfony

  • Memcached и расширение для PHP

    Как установить memcached и расширение PHP к нему.

Сейчас после открытия в браузере http://localhost мы видим страницу нашего проекта на Symfony.

Итак, у нас все есть для работы, начнем ускорять наш проект. За основу берется то, что Nginx умеет обращаться к memcached по ключу и отдавать значение, которое содержится по этому ключу, в качестве ответа web-сервера.

Memcached — это демон, который хранит данные в оперативной памяти, обращаться к этим данным мы можем по определенному ключу.

Воспользуемся всеми вышеописанными возможностями memcached и nginx. В качестве ключа в memcached мы будем использовать URL-адрес страниц нашего сайта, а в качестве содержимого HTML страницы. Теперь нам нужно настроить nginx так, чтобы он при наличии в memcached значения (html) по ключу (url страницы) отдавал его сразу же в ответе клиенту, в противном случае запрос должен передаваться к Symfony, который его обрабатывает, сохраняет в memcached и отдает ответ для клиента. Таким образом, если в данный момент страница не в кэше, то его добавит в кэш Symfony, и при следующем запросе к этой странице ответ будет получен еще на стороне nginx, не доходя даже до Symfony.

Итак, добавим в наш проект возможность записи ответа сервера в memcached. Для этого воспользуемся механизмом фильтров в Symfony. Создадим в директории lib нашего проекта поддиректорию cache, а в ней создадим файл sfHtmlCacheFilter.class.php. Содержимое этого файла будет следующее: 

<?php
 
class sfHtmlCacheFilter extends sfFilter
{
    private static $replacement = array();
    private static $multi_replacement = array();
    private static $pageLimit = array();
    private static $host = '';
 
    /**
     * Метод вызывается после того, как страница полностью сформирована,
     * здесь содержимое страницы записывается в memcached, если она указана в конфиге html_cache.yml.
     *
     * @param <Object> $filterChain
     * @return <NULL>
     */
    public function execute ($filterChain)
    {
        $filterChain->execute();
 
        $response = $this->getContext()->getResponse();
        $request = $this->getContext()->getRequest();
 
	// Если в наших конфигах прописано не использовать кэширование или мы находимся в debug-режиме, то прекращем выполнение.
	// Здесь также проверяется код ответа - если он не равен 200, то прекращем выполнение.
        if (
          (!sfConfig::get('sf_cache') || count($request->getGetParameters()) || count($request->getPostParameters()))
          ||
          (sfConfig::get('sf_debug') || !sfConfig::get('sf_no_script_name') || $response->getStatusCode() != 200)
        )
        {
          return;
        }
 
        $uri = $this->getContext()->getRouting()->getCurrentInternalUri();
        self::$host = 'http://'.$request->getHost();
	// Получаем запрошенный URI - будущий ключ для memcached
        $webUri = str_replace(self::$host, '', $request->getUri());
        $uriCacheParams = null;
	// Получаем из конфига страницы, которые подлежат кэшированию
        $config = self::getConfig();
        foreach($config as $item)
        {
            foreach($item as $key=>$uriParams)
            {
                $routing_uri = preg_replace('/^(.*)\?.*$/i', '$1', $uri);
		// Сравниваем запрошенный URI с записями в конфиге
                if(preg_match('#^'.$key.'$#', $webUri))
                {
                    $uriCacheParams = $uriParams;
                    break;
                }
            }
 
	    // Если запрошенная страница есть в конфиге, то прекращаем цикл
            if($uriCacheParams)
            {
                break;
            }
        }
        $webUri = self::_decodeUri($webUri);
        if ($uriCacheParams && $response->getStatusCode() == '200')
        {
	    // Записываем содержимое ответа в кэш
            self::setUri(self::$host.$webUri, $response->getContent(), $uriCacheParams['lifetime']);
        }
 
        return;
    }
 
    /**
     * Получить конфиг тэгов
     *
     * @return <Array>
     */
    private static function getConfig() {
        $conf = sfYaml::load(sfConfig::get('sf_config_dir') . '/html_cache.yml');
 
        return $conf;
    }
 
    /**
     * Вызывается из методов save() моделей,
     * удаляет из кэша все страницы, зависящие от заданной модели
     *
     * @param <Object> $model - объект, для которого вызывается метод save в модели
     */
    public static function deleteCache($model)
    {
        $request = sfContext::getInstance()->getRequest();
        $model_name = get_class($model);
        $config = self::getConfig();
 
        $arUri = array();
 
        // Получаем страницы из конфига по этой модели
        $arCacheParam = $config[$model_name];
        self::$host = 'http://'.$request->getHost();
        // Обходим в цикле страницы, строим из них ключи для memcache
        foreach($arCacheParam as $uri=>$param)
        {
            self::$replacement = array();
            self::$multi_replacement = array();
            self::$pageLimit = array();
 
            $pageLimit = null;
            $attr = (isset($param['attributes']) ? $param['attributes'] : null);
            settype($attr, 'array');
            foreach($attr as $prop)
            {
                $method = 'get'.$prop;
                $value = false;
                /**
                 * method_exists не работает для Doctrine,
                 * но работает для Propel, is_callable всегда будет
                 * возвращать true для Doctrine, поэтому существование
                 * метода проверяется таким образом.
                 */
                try {
                        $value = $model->$method();
                }
                catch (Exception $e) {}
 
                if($value !== false)
                {
                    if (is_string($value) && strpos($value, ' ') !== false) {
                        $value = self::_decodeUri($value, false);
                    }
                    self::$replacement[] = $value;
                }
                elseif(preg_match('/^pageLimit:(\d+)$/', $prop, $matches))
                {
                    $pageLimit = $matches[1];
                    self::$replacement['pageLimit'] = range(1, $pageLimit);
                }
            }
 
            $isCachable = true;
            $beforeDeleteCache = (isset($param['beforeDeleteCache']) ? $param['beforeDeleteCache'] : null);
            settype($beforeDeleteCache, 'array');
            foreach($beforeDeleteCache as $callback)
            {
                $method = $callback;
                $isCachable = $model->$method();
            }
 
            if($isCachable)
            {
                $uri = preg_replace_callback('/\(.*\)/U', array('self', 'replace_attr_callback'), $uri);
                if(self::$multi_replacement)
                {
                    self::replace_multi_attr(self::$multi_replacement, $uri, $arUri);
                }
                else
                {
                    $arUri[] = self::$host.$uri;
                }
            }
        }
 
        // Удаляем массив страниц из memcached
        if($arUri)
        {
            self::deleteUri($arUri);
        }
    }
 
    /**
     * Используется для парсинга конфига при удалении страницы из memcached
     *
     * @param <Array> $matches
     * @return <String>
     */
    private static function replace_attr_callback($matches)
    {
        $expr = $matches[0];
        $arKeys = array_keys(self::$replacement);
        $key = $arKeys[0];
        if(!is_array(self::$replacement[$key]) && $key !== 'pageLimit' && isset(self::$replacement[$key]) && preg_match('/'.$expr.'/', self::$replacement[$key]))
        {
            $expr = self::$replacement[$key];
        }
        else
        {
            self::$multi_replacement[] = self::$replacement[$key];
            $expr = '%MULTI_REPLACEMENT_'.(count(self::$multi_replacement) - 1).'%';
        }
 
        unset(self::$replacement[$key]);
 
        return $expr;
    }
 
    /**
     * Используется для парсинга конфига при удалении страницы из memcached
     *
     * @param <Array> $attr
     * @param <String> $uri
     * @param <Array> $arUri
     * @param <Integer> $key
     */
    private static function replace_multi_attr($attr, $uri, &$arUri, $key = 0)
    {
        if(isset($attr[$key]))
        {
            foreach($attr[$key] as $ind=>$i)
            {
                self::replace_multi_attr($attr,
                                str_replace('%MULTI_REPLACEMENT_'.$key.'%', $i, $uri),
                                $arUri,
                                $key+1);
            }
        }
        if($key == count($attr))
        {
            $arUri[] = self::$host.$uri;
        }
    }
 
    /**
     * Возвращает объект для работы с memcached.
     *
     * @return <Object>
     */
    private static function getMemcache()
    {
        $memcache = new Memcache();
        $con = $memcache->connect('127.0.0.1', 11211);
	return $memcache;
    }
 
    /**
     * Записываем содержимое страницы в memcached
     *
     * @param <String> $uri - ключ в memcached
     * @param <String> $data - значение в memcached
     * @param <Integer> $lifetime - время жизни кэша
     */
    private static  function setUri($uri, $data, $lifetime)
    {
	$memcache = self::getMemcache();
	$memcache->set($uri, $data, 0, $lifetime);
    }
 
    /**
     * Удаляет страницу из memcached
     *
     * @param <Array> $arUri - массив ключей memcached,
     * которые следует удалить
     */
    private static function deleteUri($arUri)
    {
        settype($arUri, 'array');
        $memcache = self::getMemcache();
        foreach($arUri as $uri)
        {
            $memcache->delete($uri);
        }
    }
 
 
    /**
     * Метод декодирует URI через rawurldecode,
     * но символ пробела оставляет в прежнем виде,
     * т.к. nginx его не декодирует в своей переменной $uri
     *
     * @param <string> $uri
     * @param <boolean> $decode
     * @return <string>
     */
    private static function _decodeUri($uri, $decode = true)
    {
        $url = ($decode ? rawurldecode($uri) : $encodedUri);
 
        return str_replace(' ', '%20', $url);
    }
}

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

Все, что делается в методе execute — это получение текущего адреса страницы, проверка его в конфиге html_cache.yml и, если он там есть, записываем содержимое в memcached.

Теперь создадим сам конфиг html_cache.yml и положим его в папку config нашего проекта: 

Index:
  /: { lifetime: 86400 }

Здесь мы задаем адрес запрошенной страницы («/» – запрос главной страницы сайта), в фигурных скобках перечислены параметры кэширования, мы указали время жизни кэша 86400 секунд, т. е. сутки. Параметр Index сейчас используется только лишь в качестве группировки адресов страниц, но здесь можно также указывать названия моделей Symfony, об этом будет рассказано ниже.

По части Symfony у нас почти все готово, осталось включить использование кэширования и активировать наш фильтр.

Чтобы включить кэширование для секции prod прописываем в файле apps/frontend/config/settings.yml (изменения выделены жирным шрифтом): 

1
2
3
4
5

prod:
  .settings:
    no_script_name:         true
    cache:               true
    logging_enabled:        true

А теперь активируем фильтр, добавляем в файл apps/frontend/config/filters.yml пару строчек:

1
2
3
4
5
6
7
8
9
10

rendering: ~
security:  ~
 
# insert your own filters here
 
htmlcache:
    class: sfHtmlCacheFilter
 
cache:     ~
execution: ~

Тем самым мы активировали наш класс-фильтр.

Теперь сбрасываем кэш Symfony: 

# php symfony cache:clear

И заходим на страницу http://localhost/ . Если все правильно сделали главная страница нашего сайта должна оказаться в memcached, проверяем: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

# telnet localhost 11211
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get http://localhost/
VALUE http://localhost/ 0 2026
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
 
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title></title>
<link rel="stylesheet" type="text/css" media="screen" href="/css/main.css" />

<link rel="stylesheet" type="text/css" media="screen" href="/sf/sf_default/css/screen.css" />
 
<link rel="shortcut icon" href="/favicon.ico" />

 
<!--[if lt IE 7.]>
<link rel="stylesheet" type="text/css" media="screen" href="/sf/sf_default/css/ie.css" />

<![endif]-->
 
</head>
<body>
<div class="sfTContainer">
  <a href="http://www.symfony-project.org/"><img alt="symfony PHP Framework" class="sfTLogo" src="/sf/sf_default/images/sfTLogo.png" height="39" width="186" /></a>

<div class="sfTMessageContainer sfTMessage">
  <img alt="ok" class="sfTMessageIcon" src="/sf/sf_default/images/icons/ok48.png" height="48" width="48" />  <div class="sfTMessageWrap">

    <h1>Symfony Project Created</h1>
    <h5>Congratulations! You have successfully created your symfony project.</h5>
  </div>
</div>
<dl class="sfTMessageInfo">

  <dt>Project setup successful</dt>
  <dd>This project uses the symfony libraries. If you see no image in this page, you may need to configure your web server so that it gains access to the <code>symfony_data/web/sf/</code> directory.</dd>
 
  <dt>This is a temporary page</dt>

  <dd>This page is part of the symfony <code>default</code> module. It will disappear as soon as you define a <code>homepage</code> route in your <code>routing.yml</code>.</dd>

 
  <dt>What's next</dt>
  <dd>
    <ul class="sfTIconList">
      <li class="sfTDatabaseMessage">Create your data model</li>

      <li class="sfTColorMessage">Customize the layout of the generated templates</li>
      <li class="sfTLinkMessage"><a href="http://www.symfony-project.org/doc">Learn more from the online documentation</a></li>
    </ul>

  </dd>
</dl>
</div>
</body>
</html>
 
END
quit
Connection closed by foreign host.

Отлично! Теперь наш проект может перед отдачей ответа клиенту записывать в memcached HTML страниц.

Ну а теперь осталось настроить nginx, чтобы он мог сам отвечать клиенту, если запрошенная страница присутствует в memcached.

Для этого нам надо добавить еще один upstream для memcached в конфиг nginx и задать правила для проксирования в него запросов. Вот каким должен получиться конфиг для Nginx (изменения выделены жирным шрифтом): 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132

worker_processes  1;
 
 
events {
    worker_connections  1024;
}
 
 
http {

    include       mime.types;
    default_type  application/octet-stream;
 
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '

                      '"$http_user_agent" "$http_x_forwarded_for"';
 
    access_log  logs/access.log  main;
    error_log  logs/error.log info;
 
    sendfile        on;
    keepalive_timeout  65;

 
    upstream memcached_backend {
	server 127.0.0.1:11211;
    }
 
    upstream fcgi_www {
	server 127.0.0.1:9000;
    }

 
    server {
        listen       80;
        server_name  localhost;
 
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {

            root   html;
        }
 
	root /srv/www/symfony/web; #%ПУТЬ_ДО_ВАШЕГО_ПРОЕКТА%/web
 

	location ~ "^(/css/|/images/|/js/|/uploads/)" {
	    expires 3d;
	}
 
	location /sf/ {
	    root /srv/www/symfony/lib/vendor/symfony/data/web; #%ПУТЬ_ДО_ВАШЕГО_ПРОЕКТА%/lib/vendor/symfony/data/web

	}
 
	location / {
	    fastcgi_param REQUEST_URI            $request_uri;
	    fastcgi_param DOCUMENT_URI           $document_uri;
	    fastcgi_param DOCUMENT_ROOT          $document_root;
	    fastcgi_param GATEWAY_INTERFACE      CGI/1.1;
	    fastcgi_param SERVER_SOFTWARE        nginx/$nginx_version;
	    fastcgi_param REMOTE_ADDR            $remote_addr;
	    fastcgi_param REMOTE_PORT            $remote_port;
	    fastcgi_param SERVER_ADDR            $server_addr;
	    fastcgi_param SERVER_PORT            $server_port;
	    fastcgi_param SERVER_NAME            $server_name;
	    fastcgi_param SERVER_PROTOCOL        $server_protocol;
	    fastcgi_param CONTENT_TYPE           $content_type;
	    fastcgi_param CONTENT_LENGTH         $content_length;
	    fastcgi_param HTTP_ACCEPT_ENCODING   gzip,deflate;
	    fastcgi_param QUERY_STRING           $query_string;
	    fastcgi_param REDIRECT_STATUS        200;
	    fastcgi_param REQUEST_METHOD         $request_method;
	    fastcgi_param SCRIPT_FILENAME        /srv/www/symfony/web/index.php; #%ПУТЬ_ДО_ВАШЕГО_ПРОЕКТА%/web/index.php

	    fastcgi_param SCRIPT_NAME            /index.php;
	    fastcgi_param PATH_INFO              $request_uri;
 
            # Если это POST-запрос, то передаем обработку сразу в Symfony
	    if ($request_method = POST) {

		fastcgi_pass  fcgi_www;
		break;
	    }
 
           # Если на предыдущем шаге мы не вышли из location'а, то это GET-запрос.
           # Устанавливаем ключ для memcached, по которому будем искать значение
	    set $memcached_key "http://$host$uri";
           # Задаем upstream для memcached

	    memcached_pass  memcached_backend;
 
           # Устанавливаем тип содержимого, полученного от memcached, у нас хранится HTML
	    default_type text/html;
           # Указываем nginx'у переходить в именованный location @symfony в случае отсутствия ключа 
           # в memcached или в случае возникновении ошибки при запросе к memcached
	    proxy_intercept_errors  on;
	    error_page 404 502 = @symfony;
	}

 
       # Здесь описан именованный location, куда nginx переходит в случае отсутствия ключа или                                          
       # возникновении ошибки при обращении к memcached. Здесь просто перечислены параметры 
       # fastcgi так же, как было сделано выше.
	location @symfony {
	    fastcgi_param REQUEST_URI            $request_uri;
	    fastcgi_param DOCUMENT_URI           $document_uri;
	    fastcgi_param DOCUMENT_ROOT          $document_root;
	    fastcgi_param GATEWAY_INTERFACE      CGI/1.1;
	    fastcgi_param SERVER_SOFTWARE        nginx/$nginx_version;
	    fastcgi_param REMOTE_ADDR            $remote_addr;
	    fastcgi_param REMOTE_PORT            $remote_port;
	    fastcgi_param SERVER_ADDR            $server_addr;
	    fastcgi_param SERVER_PORT            $server_port;
	    fastcgi_param SERVER_NAME            $server_name;
	    fastcgi_param SERVER_PROTOCOL        $server_protocol;
	    fastcgi_param CONTENT_TYPE           $content_type;
	    fastcgi_param CONTENT_LENGTH         $content_length;
	    fastcgi_param HTTP_ACCEPT_ENCODING   gzip,deflate;
	    fastcgi_param QUERY_STRING           $query_string;
	    fastcgi_param REDIRECT_STATUS        200;
	    fastcgi_param REQUEST_METHOD         $request_method;
	    fastcgi_param SCRIPT_FILENAME        /srv/www/symfony/web/index.php; #%ПУТЬ_ДО_ВАШЕГО_ПРОЕКТА%/web/index.php

	    fastcgi_param SCRIPT_NAME            /index.php;
	    fastcgi_param PATH_INFO              $request_uri;
	    fastcgi_pass  fcgi_www;
	}
    }
 
}

Теперь проверяем нет ли ошибок в конфигах Nginx после внесения изменений: 

# /etc/init.d/nginx configtest
the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/nginx/conf/nginx.conf test is successful

И говорим Nginx, чтобы он перечитал конфиг: 

# /etc/init.d/nginx reload
Reloading nginx:  reloaded

Проверяем! Заходим на страницу http://localhost/ , она у нас уже должна лежать в memcached. Лично я в своем браузере Mozilla Firefox даже на примере такой простой странички вижу, что она стала загружаться гораздо быстрее!

Но не будем доверять всему тому, что видим. Проведем небольшой бенчмарк, в этом нам поможет утилита ab2 — инструмент от разработчиков web-сервера Apache.

Сначала закомментируем наши настройки в Nginx, чтобы он перенаправлял все на Symfony.

Вносим следующие изменения в наш конфиг для Nginx, начиная с 71-й строки: 

71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

	    fastcgi_param SCRIPT_NAME            /index.php;
	    fastcgi_param PATH_INFO              $request_uri;
	    fastcgi_pass  fcgi_www;
 
#	    if ($request_method = POST) {

#		fastcgi_pass  fcgi_www;
#		break;
#	    }
 
#	    set $memcached_key "http://$host$uri";
#	    memcached_pass  memcached_backend;
 
#	    default_type text/html;
#	    proxy_intercept_errors  on;

#	    error_page 404 502 = @symfony;
	}
 
	location @symfony {

Затем стандартные команды: 

# /etc/init.d/nginx configtest
the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/nginx/conf/nginx.conf test is successful
# /etc/init.d/nginx reload
Reloading nginx:  reloaded

И запускаем утилиту от Apache, отправим на наш сайт 1000 запросов, причем 10 будем выполнять параллельно: 

# ab2 -n 1000 -c 10 http://127.0.0.1:80/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
 
Server Software:        nginx/0.8.54
Server Hostname:        127.0.0.1
Server Port:            80
 
Document Path:          /
Document Length:        2026 bytes
 
Concurrency Level:      10
Time taken for tests:   26.412 seconds
Complete requests:      1000
Failed requests:        646
   (Connect: 0, Receive: 0, Length: 646, Exceptions: 0)
Write errors:           0
Non-2xx responses:      646
Total transferred:      1142110 bytes
HTML transferred:       964622 bytes
Requests per second:    37.86 [#/sec] (mean)
Time per request:       264.116 [ms] (mean)
Time per request:       26.412 [ms] (mean, across all concurrent requests)
Transfer rate:          42.23 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     0  264 349.9      3     827
Waiting:        0  264 349.9      3     810
Total:          1  264 349.9      3     827
 
Percentage of the requests served within a certain time (ms)
  50%      3
  66%    703
  75%    713
  80%    716
  90%    748
  95%    788
  98%    790
  99%    796
 100%    827 (longest request)

У меня после таких тестов отваливался через некоторое время fastcgi. Во время выполнения ab2 попробуйте проверить загрузку страницы в браузере — можно наблюдать постепенное нарастание тормозов при загрузке страницы.

Итак, если вас настигла беда с fastcgi, как и у меня, то запускаем его снова: 

php-cgi -a -b 127.0.0.1:9000 -c /etc/php5/fastcgi/php.ini

Далее убираем наши комментарии, сделанные перед запуском теста, релоадим nginx и запускаем ab2 с теми же параметрами: 

# /etc/init.d/nginx configtest
the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/nginx/conf/nginx.conf test is successful
# /etc/init.d/nginx reload
Reloading nginx:  reloaded
# ab2 -n 1000 -c 10 http://127.0.0.1:80/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
 
Server Software:        nginx/0.8.54
Server Hostname:        127.0.0.1
Server Port:            80
 
Document Path:          /
Document Length:        2026 bytes
 
Concurrency Level:      10
Time taken for tests:   0.337 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      2170000 bytes
HTML transferred:       2026000 bytes
Requests per second:    2971.65 [#/sec] (mean)
Time per request:       3.365 [ms] (mean)
Time per request:       0.337 [ms] (mean, across all concurrent requests)
Transfer rate:          6297.35 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.4      0       3
Processing:     1    3   0.6      3       5
Waiting:        0    3   0.6      3       4
Total:          1    3   0.5      3       6
 
Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      4
  80%      4
  90%      4
  95%      4
  98%      4
  99%      4
 100%      6 (longest request)

Тут даже говорить нечего, все сказано в первом и втором выводах ab2. Достаточно взглянуть хотя бы на параметр «Time taken for tests», который показывает общее время проведения тестов. В первом случае он равен 26.412 секунд, во втором - 0.337 секунд. Прирост производительности почти в 80 раз!

Конечно, тестирование на локальном компьютере — это не есть тестирование в условиях, приближенных к реальным, однако какое-то представление оно все же дает.

А теперь вернемся к примеру, который был описан в самом начале статьи. Есть страница с постоянным контентом и есть блок с последними комментариями.

Как кэширование, которое мы только что внедрили в Symfony, поможет нам с кэшированием такой страницы? Пока никак. Наш кэш живет только какое-то определенное время, указанное в параметре lifetime, поэтому блок с комментариями будет обновляться только, когда истечет время жизни кэша. Но нас это не устраивает, нужно, чтобы страница обновлялась каждый раз после того, как добавился комментарий. Хорошо бы после добавления комментария удалять из кэша страницу.

Зададимся вопросом: «В какой момент у нас обычно должен обновляться кэш?». Обычно в момент, когда что-то меняется в базе данных. При чем, если изменения производятся в таблице, где хранятся комментарии, то обновляться должны страницы, где выводятся блоки, связанные с комментариями.

Для начала подключим к нашему проекту на Symfony базу данных. Не имеет значения какую базу данных использовать. Если вы знакомы с Symfony, то без труда сможете подключить свою базу данных. В своих же примерах я использую MySQL, пользователь root с паролем secretpass, имя базы данных — symfony. 

# mysqladmin -uroot -psecretpass create symfony
# php symfony configure:database "mysql:host=localhost;dbname=symfony" root secretpass

Теперь опишем нашу будущую базу данных в Symfony, для этого отредактируем файл config/doctrine/schema.yml: 

Comment:
  columns:
    text: { type: string(255), notnull: true }

Далее воспользуемся готовыми инструментами Symfony и сгенерируем код для моделей, SQL для базы данных. 

# php symfony doctrine:build --model
# php symfony doctrine:build --sql
# php symfony doctrine:insert-sql

Последняя команда выполняет SQL, чтобы создать необходимые таблицы в базе данных. Вместо этих трех команд можно было бы выполнить php symfony doctrine:build —all, которая выполняет те же 3 действия, но за один раз.

Теперь сгенерируем стандартную функциональность для добавления, удаления, редактирования и просмотра списка объектов модели: 

# php symfony doctrine:generate-module --with-show --non-verbose-templates frontend comment Comment

Здесь мы говорим сгенерировать код для нового модуля comment, код генерируется для существующей модели Comment.

Далее необходимо переопределить метод save() для моделей, участвующих в кэшировании. У нас это одна модель Comment, поэтому открываем файл lib/model/doctrine/Comment.class.php и добавляем в класс Comment метод save(): 

class Comment extends BaseComment
{
    public function save(Doctrine_Connection $conn = null) {
        parent::save($conn);
        sfHtmlCacheFilter::deleteCache($this);
    }
}

Мы добавили метод save(), который переопределяет метод save() класса Doctrine_Record. В нашем методе мы вызываем метод save() родительского класса, которым и окажется Doctrine_Record::save().

Далее вызывается метод нашего класса-фильтра sfHtmlCacheFilter::deleteCache($this), которому в качестве параметра передается сохраняемый объект. Таким образом, этот новый метод не делает ничего нового, кроме как добавляется метод для очистки кэша при каждом сохранении объекта.

Удаляем кэш Symfony, чтобы наши изменения вступили в силу. 

# php symfony cache:clear

Все, теперь зайдем по адресу http://localhost/comment и увидим сгенерированную Symfony страницу. Нажимаем на ссылку «New», добавляем первую запись, возвращаемся назад к списку и видим только что добавленный комментарий.

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

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

Сейчас у нас в файле html_cache.yml на первом уровне прописана несуществующая модель Index, на втором уровне прописана главная страница. Т. к. модели Index у нас нет, то эта настройка просто говорит о том, что неоходимо записывать в кэш содержимое главной страницы, но никакого удаления ее из кэша не происходит.

Для такой главной страницы это и не нужно, т. к. там выводится всегда одна и та же информация. А вот со страницей списка комментариев ситуация иная — если для нее мы применяем кэширование, то необходимо удалять кэш этой страницы при каждом добавлении комментария.

Добавим такую настройку. Страница со списком комментариев располагается по адресу http://localhost/comment. Добавляем в файл config/html_cache.yml следующую запись: 

Comment:
  /comment: { lifetime: 86400 }

Теперь наша страница http://localhost/comment будет отдаваться клиенту еще на стороне nginx при наличии ее в кэше. В противном случае nginx передаст управление Symfony, который сформирует и запишет содержимое страницы в кэш.

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

В файле html_cache.yml можно использовать регулярные выражения, а также подставлять в адреса страниц результаты выполнения методов объектов. Применим кэширование к детальным страницам комментариев, которые располагаются по адресам вида - http://localhost/comment/show/id/1 .

Добавим к модели Comment следующую зависимость: 

1
2
3
4

Comment:
  /comment: { lifetime: 86400 }
  /comment/show/id/(\d+): { lifetime: 86400, attributes: [Id] }

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

В данном примере вместо регулярного выражения (\d+) будет подставлен результат вызова метода getId() для объекта модели Comment. Это справедливо только при сохранении объекта и удалении кэша для него. При добавлении страницы в кэш будет произведено лишь сравнение текущего адреса страницы с регулярным выражением /comment/show/id/(\d+) и, если адрес пройдет проверку, то страница добавится в кэш.

После произведенных изменений в файле html_cache.yml страницы вида http://localhost/comment/show/id/1 постигнет участь предыдущих рассматриваемых страниц — они будут писаться в кэш.

Помимо параметров lifetime и attributes можно использовать параметр beforeDeleteCache, в который передается название метода модели (полное название). Этот метод должен возвращать true или false. При получении false кэш для записи с этим параметром удаляться не будет.

На этом все. Теперь наш проект на Symfony стал не просто быстрым, а мегабыстрым. Ответы клиент получает не от php-скриптов на сервере и даже не с диска, а из памяти сервера.

Спасибо за внимание! Чтобы ваши сайты всегда летали!

UPD: Спасибо Sergei за найденную ошибку. Все описанное работало только с латинскими буквами в url'е, но не работало с русскими. Внесены нужные изменения в класс-фильтр для Symfony, а также в конфиге nginx в качестве ключа для memcached теперь используется переменная $uri, а не $request_uri

]]> http://job-interview.ru/articles/post/300/feed 561 CMS Битрикс. За и против. http://job-interview.ru/articles/post/234 http://job-interview.ru/articles/post/234#comments Thu, 04 Feb 2010 21:45:56 +0000 /articles/?p=234 Проработав 2 года с CMS Битрикс, у меня сформировалось свое отношение к этому движку. Есть как плюсы, так и минусы, но все же негатива накопилось гораздо больше.

В этой статье я поделюсь своим мнением с читателями и постараюсь описать и хорошие, и плохие стороны этой CMS.

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

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

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

Диаграмма инфоблоков Битрикс

Инфоблок — это такая сущность, которая объединяет элементы с определенным набором свойств. Часть свойств, такие как название элемента, раздел, даты активности и т.п., присутствует у элементов всех инфоблоков. К этим свойствам проектировщик может добавить еще и свои свойства, но они уже будут рассматриваться в контексте каждого конкретного инфоблока.

Существует также понятие типа инфоблока, который объединяет в себе инфоблоки.
Поясню на примере. Допустим, мы создаем сайт, на котором будут размещены вакансии.. В этом случае нам будут необходимы 3 инфоблока: «Вакансии», «Отрасли», «Компании».

После создания инфоблока «Вакансии» мы можем создать в нем элементы со стандартным набором свойств:

  • Название
  • Активность (да/нет)
  • Период активности (активен в указанный период времени)
  • Краткое описание
  • Подробное описание
  • Изображение-превью
  • Увеличенное изображение
  • Раздел

Этих свойств будет достаточно для обычного текстового контента (статьи, новости и т.д.), но нам для вакансий этого не хватит. Мы создадим еще свойства:

  • Компания (свойство, ссылающееся на инфоблок «Компании»)
  • Отрасль (свойство, ссылающееся на инфоблок «Отрасли»)
  • Опыт работы (свойство типа список с значениями «до 2-х лет», «от 2-х до 4-х лет», «более 4 лет» и т.д.)

В инфоблоке «Отрасли» и «Компании» ограничимся стандартным набором свойств, которые предоставляет нам битрикс.

Вот, что у нас получилось:

Структура инфоблоков Битрикс для размещения вакансий

Вроде бы с точки зрения теории баз данных у нас все верно. Все сущности разделены, избыточности нет и т.д. Но давайте взглянем на структуру базы.

Рассмотрим как работает выборка из инфоблоков на простом примере. В битриксе существует часть таблиц в базе данных, которые хранят данные, связанные с инфоблоками — сами инфоблоки (b_iblock), их элементы(b_iblock_element), свойства(b_iblock_property), значения свойств (b_iblock_element_property).

Это не все таблицы, связанные с инфоблоками, но для простоты понимания нас будут интересовать именно они.

ER-диаграмма некоторых таблиц Битрикса, хранящих данные об инфоблоках

Как видим, элементы всех инфоблоков хранятся в одной таблице, все свойства этих элементов так же хранятся в одной таблице.

Как же так! Зачем СУБД копаться в вакансиях, отраслях, если нам нужно будет выбрать всего лишь список всех компаний, вакансии которых храняться в базе ?!

А что будет, если нашему сайту необходим более сложный функционал? Вот тогда то и начнутся тормоза.

Теперь воспользуемся АПИ битрикса и выберем список вакансий конкретной компании, но те вакансии, которые не относятся к определенной отрасли.

В примере происходит выборка из инфоблока «Вакансии», ID которого 23, а также происходит фильтрация по компании, ID которой 373, и по отрасли, ID которой 317. В последнем параметре метода GetList передается список выбираемых полей — ID, компания, опыт работы, начало периода активности вакансии.

$arFilter = Array(
"IBLOCK_ID"=>23, // выбираем элементы из инфоблока, ID которого 23
"ACTIVE"=>"Y", // выбираем только активные элементы
"PROPERTY_COMPANY"=>373, // вакансии будут принадлежать компании с ID=373
"!PROPERTY_BRANCH" =>317 // вакансии, принадлежащие отрасли с ID=317, нас не интересуют
);
$res = CIBlockElement::GetList(Array("DATE_ACTIVE_FROM"=>"ASC"), $arFilter, false, false, Array("ID", "PROPERTY_COMPANY", "PROPERTY_EXPERIENCE", "DATE_ACTIVE_FROM"));

Выглядит красиво, прямо как-будто один безобидный SQL запрос, но заглянем внутрь:

SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('COMPANY')
 
SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('EXPERIENCE')
 
SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('BRANCH')
 
SELECT BE.ID AS ID, FPV0.VALUE AS PROPERTY_COMPANY_VALUE, FPV0.ID AS PROPERTY_COMPANY_VALUE_ID, FPEN0.VALUE AS PROPERTY_EXPERIENCE_VALUE, FPEN0.ID AS PROPERTY_EXPERIENCE_ENUM_ID, FPV1.ID AS PROPERTY_EXPERIENCE_VALUE_ID,IF(EXTRACT(HOUR_SECOND
FROM
BE.ACTIVE_FROM)>0, DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y %H:%i:%s'), DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y')) AS DATE_ACTIVE_FROM,IF(EXTRACT(HOUR_SECOND
FROM
BE.ACTIVE_FROM)>0, DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y %H:%i:%s'), DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y')) AS ACTIVE_FROM
FROM
b_iblock B
INNER JOIN b_lang L ON B.LID=L.LID
INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID
INNER JOIN b_iblock_property FP0 ON FP0.IBLOCK_ID = B.ID AND FP0.CODE='COMPANY'
LEFT JOIN b_iblock_property FP1 ON FP1.IBLOCK_ID = B.ID AND FP1.CODE='EXPERIENCE'
LEFT JOIN b_iblock_property FP2 ON FP2.IBLOCK_ID = B.ID AND FP2.CODE='BRANCH'
INNER JOIN b_iblock_element_property FPV0 ON FPV0.IBLOCK_PROPERTY_ID = FP0.ID AND FPV0.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV1 ON FPV1.IBLOCK_PROPERTY_ID = FP1.ID AND FPV1.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV2 ON FPV2.IBLOCK_PROPERTY_ID = FP2.ID AND FPV2.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_property_enum FPEN0 ON FPEN0.PROPERTY_ID = FP0.ID AND FPV1.VALUE_ENUM = FPEN0.ID
WHERE
1=1 AND ( ((((BE.IBLOCK_ID = '23')))) AND ((((BE.ACTIVE='Y')))) AND ((((FPV0.VALUE_NUM = '373')))) AND ((( FPV2.VALUE_NUM IS NULL OR NOT (FPV2.VALUE_NUM = '317')))) ) AND (((BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL)))
ORDER BY
BE.ACTIVE_FROM ASC

Ужас! А что же тогда творится с СУБД на реальных сайтах.

Мы при написании метода GetList использовали 3 свойства (ключи значений массивов, начинающиеся с «PROPERTY_») и в SQL-запросах, которые сгенерил битрикс, видим 3 запроса для каждого из 3-х свойств. А что будет, если создать десятки свойств? А будет ровно столько запросов сколько участвует в методе GetList.

Ну и в конце мы видим громадный запрос, напичканный join’ами. Если приглядеться к этому запросу, то можно догадаться, что количество join’ов зависит от количества свойств, участвующих в методе GetList.

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

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

Возникает вопрос. Зачем простому сайту, на котором в основном статьи и новости, дополнительные модули в виде магазина, форума, блогов, тормозной статистики (которую к тому же предлагают многие бесплатные сервисы). А ведь такой сайт программист может без проблем создать, например, на бесплатном фреймворке symfony, в котором админка генерится одной командой. Так зачем платить больше?

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

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

Как-то раз ко мне подошел один из сотрудников за помощью. Он парсил файл CSV, но этот процесс у него отрабатывал не верно. Стали смотреть скрипт и тут программист высказывает свое предположение: «Может быть битрикс где-то закрался?». Может быть всемогущий битрикс каким-то магическим образом и мог бы закрасться в его скрипт, но дело в том, что он его запускал без подключения движка. На самом деле потом нашли обычную ошибку в логике самого скрипта.

Еще был случай. Отмечали чей-то день рождения и двое программистов начали обсуждать все достоинства битрикса. Один из них кинул фразу: «Ну битрикс — это очень мощная система, он внутри себя и язык Си использует, и ассемблер». Второй округлил глаза и не поверил. А тот ему: «Ну ты залезь в код битрикса, посмотри». Тут вообще без комментариев.

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

Таким образом, на свет появляются web-студии, которые штампуют на битриксе сайт за сайтом. Их основной задачей в итоге становиться увеличение штата сотрудников, способных делать сайты на битриксе. Дешевая рабочая сила. Чем больше штат, тем больше сайтов они смогут клепать.

И напоследок хотелось бы дать совет начинающим программистам. Не устраивайтесь на работу в web-студии, которые в своих описаниях вакансий упоминают слово «Битрикс». Если вы начнете свой карьерный путь с этого движка, то потом соскочить с него будет не просто. Пройдет года 2 и ваши друзья уже неплохо продвинуться в программировании, кто-то перерастет в проектировщика, а вы будете жить одними инфоблоками и не понимать что происходит внутри.
Я сейчас не говорю о всех, но именно таких программистов я встречал часто. Конечно, все люди разные, кто-то может на работе использовать битрикс, но дома в целях самообразования тренироваться в других областях программирования. Но все же лучше набираться знаний на работе, где человек проводит большую часть своего времени.

На этом все. Спасибо за внимание. В комментариях жду ваших мыслей по поводу использования битрикса.

]]> http://job-interview.ru/articles/post/234/feed 875 “Многопоточность” в PHP (socket) http://job-interview.ru/articles/post/194 http://job-interview.ru/articles/post/194#comments Sun, 27 Dec 2009 13:21:34 +0000 /articles/?p=194 Использование асинхронных сокетов.

Предлагаю вашему вниманию третью статью из цикла “Многопоточность” в PHP. В данной статье мы рассмотрим асинхронные или неблокирующие сокеты.

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

Но сначала давайте разберем само понятие “сокет”. Что такое сокет?

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

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

Работа с сокетами достаточно проста:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
$url = 'www.mail.ru';
// создаем сокет
$sh = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
// определяем ip хоста
$ip = gethostbyname($url);
// открываем сокет
socket_connect($sh, $ip, '80');
// формируем http-заголовки
$headers  = "GET / HTTP/1.0\r\n";
$headers .= "Host: ".$url."\r\n";
$headers .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.6) Gecko/2009011913 MRA 5.3 (build 02557) Firefox/3.0.6\r\n";
$headers .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n";
$headers .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n";
$headers .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n";
$headers .= "\r\n";
// записываем данные в сокет
socket_write($sh, $headers, strlen($headers));
// читаем данные из сокета
$result = '';
while ($r = socket_read($sh, 1024)) $result .= $r;
?>

Сначала функцией socket_create инициализируем сокет и задаем его характеристики – флаг AF_INET, переданный в качестве первого параметра, указывает, что создается сокет для интернета, второй параметр – тип сокета (самые распространенные – TCP и UDP) нам нужен TCP-сокет – SOCK_STREAM, и третий параметр задает протокол (TCP).
Затем с помощью функции socket_connect происходит соединение к указанному адресу и порту. Надо заметить, что эта функция принимает в качестве параметра не сам адрес хоста, а его ip адрес, поэтому сначала мы должны его определить функцией gethostbyname.
Теперь нам надо сформировать запрос, который мы отправим на сервер (подробнее о http-заголовках можно почитать в статье PHP и HTTP). Собственно отправку производит функция socket_write, второй параметр которой – это то, что мы отправляем и третий – длина отправляемой строки (т.е. всех сформированных заголовков).
Запись произведена, теперь функцией socket_read читаем данные, переданные для нас сервером.
В результате в переменной $result хранится хтмл, который нам необходим.

Задача у нас стоит та же, что и в предыдущих примерах: получить содержимое нескольких html-страниц. Вот код, реализующий это:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

<?php
// страницы, содержимое которых надо получить
$urls = array('www.yandex.ru', 'www.google.ru', 'www.mail.ru', 'www.rambler.ru');
 
$rtasks = array(); // задачи чтения
$wtasks = array(); // задачи записи
$results = array(); // результаты
 
foreach ($urls as $url) {
	// открываем отдельный сокет
	$sh = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
	if (!$sh) continue;
 
	// таймаут для чтения
	socket_set_option($sh, SOL_SOCKET, SO_RCVTIMEO, array("sec" => 10, "usec" => 0));
	// таймаут для записи
	socket_set_option($sh, SOL_SOCKET, SO_SNDTIMEO, array("sec" => 10, "usec" => 0));
	// задаем неблокирующий режим сокетов
	socket_set_nonblock($sh);
	// определяем ip хоста
	$ip = gethostbyname($url);
	// соединяемся
	socket_connect($sh, $ip, 80);
 
	// добавляем в задачи для записи
	$wtasks[$url] = $sh;
}
 
// продолжаем, пока есть задачи для записи или чтения
while ($wtasks || $rtasks) {
	// массив для сокетов с возможностью чтения
	$rtasks_ = $rtasks;
	// массив для сокетов с возможностью записи
	$wtasks_ = $wtasks;
 
	// ждем результатов из сокетов
	$n = socket_select($rtasks_, $wtasks_, $e=null, 10);
	if ($n > 0) {
		// сокеты, доступные для записи
		foreach ($wtasks_ as $sh) {
			// ищем урл страницы по дескриптору сокета в массиве задач записи
			$url = array_search($sh, $wtasks);
			// удаляем из задач записи
			unset($wtasks[$url]);
			// добавляем в задачи чтения
			$rtasks[$url] = $sh;
			// формируем http-заголовки
			$headers  = "GET / HTTP/1.0\r\n";
			$headers .= "Host: ".$url."\r\n";
			$headers .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.6) Gecko/2009011913 MRA 5.3 (build 02557) Firefox/3.0.6\r\n";
			$headers .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n";
			$headers .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n";
			$headers .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n";
			$headers .= "\r\n";
 
			// записываем в сокет
			if (socket_write($sh, $headers) === false) fclose($sh);
		}
 
		// сокеты, доступные для чтения
		foreach ($rtasks_ as $sh) {
			// ищем урл страницы по дескриптору сокета в массиве задач чтения
			$url = array_search($sh, $rtasks);
			if (!$url) continue;
			// считываем результат из сокета
			$result = '';
			while ($r = socket_read($sh, 1024)) $result .= $r;
			// закрываем сокет
			socket_close($sh);
			// удаляем из задач чтения
			unset($rtasks[$url]);
			// заносим html в массив результатов
			$results[$url] = $result;
		}
	}
	else {
		break;
	}
}
?>

Можно заметить, что код несильно отличается от кода для stream-функций.

В общих словах здесь происходит следующее. Каждый сокет инициализируется и переводится в неблокирующий режим. Затем в цикле производится проверка готовых к чтению или записи сокетов, и если такие существуют, производится соответствующая операция. Все действия протекают в асинхронном порядке, т.е не ждут окончания предыдущей операции. Например, если данные с мэйл.ру поступили раньше, чем от яндекса, то будут обрабатываться именно они, хотя коннект к яндексу мог произойти до коннекта к мэйлу. Можно сказать, что все происходит в несколько “потоков”, когда параллельно ожидается готовность каждого сокета к какому-либо действию.

Теперь разберем код более подробно.
Итак, у нас есть массив с адресами страниц. В строке 9 запускается цикл для инициализации соединения с каждым хостом. В 11 строке создается сокет, затем в 15 и 17 строках мы задаем таймауты для чтения и записи соответственно. В 19 строчке функцией socket_set_nonblock задаем неблокирующий режим, превращающий каждый наш сокет в асинхронный. Это необходимо для того, чтобы после очередной операции над сокетом не происходило ожидание ее окончания, а продолжал работу остальной код программы. В 26 строке заносим инициализированный сокет в массив сокетов для записи.

Основной цикл начинается в 30 строчке. Он будет продолжаться до тех пор, пока у нас остаются сокеты, в которые нужно записать или из которых надо прочитать.
В 32 строке массиву $rtasks_ присваиваем массив сокетов, из которых должна быть прочитана информация. В 34-ой в $wtasks_ заносится массив с сокетами, в которые необходимо произвести запись.
Главная функция в этом цикле – socket_select. Она принимает на вход массивы сокетов, ожидающих чтения, ожидающих запись и массив для исключительных ситуаций, четвертый параметр, передаваемый в данную функцию – таймаут. Параметры-массивы передаются по ссылке, т.е когда произойдет ожидаемое событие (socket_select в этом случае вернет число больше 0), в них появятся соответствующие дескрипторы.
Если нашлись сокеты, доступные для записи, ищем урл, соответствующий каждому из готовых сокетов, и функцией socket_write записываем в него заголовки для получения хтмл страницы в ответе. Так же в 44-ой строке удаляем дескриптор из массива для записи, так как она будет произведена, и заносим его в строке 46 в массив для чтения, чтобы потом получить интересующий нас ответ.
Если же имеются сокеты, готовые нам ответить, считываем из них информацию функцией socket_read.
Profit! В массиве $results содержится вожделенный хтмл-код!

Замечание:
При вызове функции socket_connect, когда сокет переведен в неблокирующий режим функцией socket_set_nonblock, выдается предупреждение “Operation now in progress” (”Операция на незаблокированном сокете не может быть завершена немедленно”), а socket_connect возвращает false. Несмотря на это, код нормально отрабатывает.

]]> http://job-interview.ru/articles/post/194/feed 12683 Вопросы на собеседовании для PHP-программиста (часть 3) http://job-interview.ru/articles/post/104 http://job-interview.ru/articles/post/104#comments Sat, 01 Aug 2009 17:49:23 +0000 /articles/?p=104 Это заключительная статья, о вопросах на собеседованиях для PHP-программиста, на которые мне приходилось отвечать.

В первых двух статьях я уже выкладывал список вопросов.

В первой статье были вопросы по темам:

  • PHP
  • Задачи по составлению различных запросов SQL

В второй статье были вопросы по темам:

  • Администрирование MySQL
  • Основные принципы ООП

В этой статье я выкладываю вопросы с собеседований для PHP — программиста по следующим темам:

  • Регулярные выражения
  • Основные протоколы интернета
  • Работа в командной строке Linux

Итак, представляю список вопросов.

Регулярные выражения

  1. Напишите регулярное выражение для проверки E-mail.
  2. С использованием регулярных выражений напишите скрипт, который в заданном тексте ищет все слова, начинающиеся на «Str», и переворачивает эти слова. На выходе скрипта должен быть текст с перевернутыми словами.
  3. Напишите регулярное выражение, которое ищет все ссылки в документе HTML.

Основные протоколы интернета

  1. По какому протоколу передаются данные в интернете?
  2. Назовите уровни модели OSI.
  3. В чем основные отличия протокола HTTP/1.1 от HTTP 1.0 ?
  4. Что такое заголовки HTTP?
  5. В чем состоит преимущество постоянных соединений?
  6. Какие методы запроса протокола HTTP вы знаете?

Работа в командной строке Linux

  1. Напишите команду, которая убьет все процессы, начинающиеся на «proc».
  2. Напишите команду, которая поставит папке и всем папкам и файлам, которые в ней хранятся права: чтение, запись, выполнение для владельца, чтение, запись для группы, выполнение для всех остальных.
  3. Какими средствами будете пользоваться, если нужно отслеживать запросы к web-серверу в реальном времени?

На этом все. Надеюсь мой список вопросов поможет кому-то подготовиться к прохождению собеседования на должность PHP-программиста.

Вопросы на собеседовании для PHP-программиста (часть 1)

Вопросы на собеседовании для php-программиста (часть 2)

]]> http://job-interview.ru/articles/post/104/feed 452 “Многопоточность” в PHP (stream) http://job-interview.ru/articles/post/92 http://job-interview.ru/articles/post/92#comments Tue, 28 Jul 2009 07:24:35 +0000 /articles/?p=92 Использование stream-функций.

Это вторая статья из серии “Многопоточность” в PHP.

В прошлый раз мы рассмотрели curl, теперь давайте поговорим о stream-функциях.

Вольный перевод документации:

Streams (потоки) были введены в PHP 4.3.0 как способ обобщить работу с файлами, сетью, сжатием данных и другими процессами, которые совместно используют единый набор функций. В простейшем определении, поток – объект ресурса, имеющий “потокообразное” поведение, т.е. из которого можно читать, в который можно писать и внутри которого можно перемещаться.

stream_socket-функции являются частью streams, при помощи них мы можем коннектиться или писать/читать данные, не дожидаясь завершения предыдущей операции.

Итак, дано: массив с урлами. Задача: непоследовательно получить их содержимое.

Давайте рассмотрим код, который решает поставленную нами задачу:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

<?php
// страницы, содержимое которых надо получить
$urls = array('www.yandex.ru', 'www.google.ru', 'www.mail.ru', 'www.rambler.ru');
 
$rtasks = array(); // задачи чтения
$wtasks = array(); // задачи записи
$results = array(); // результаты
 
foreach ($urls as $url) {
    // открываем отдельный сокет
    $sh = stream_socket_client($url.':80', $errno, $errstr, 10,
        STREAM_CLIENT_ASYNC_CONNECT|STREAM_CLIENT_CONNECT);
    if (!$sh) continue;
    // добавляем в задачи для записи
    $wtasks[$url] = $sh;
}
 
while ($wtasks || $rtasks) {
    // массив для сокетов с возможностью чтения
    $rtasks_ = $rtasks;
    // массив для сокетов с возможностью записи
    $wtasks_ = $wtasks;
 
    // ждем результатов из сокетов
    $n = stream_select($rtasks_, $wtasks_, $e=null, 10);
    if ($n > 0) {
        // сокеты, доступные для записи
        foreach ($wtasks_ as $sh) {
            // ищем урл страницы по дескриптору сокета в массиве задач записи
            $url = array_search($sh, $wtasks);
            // удаляем из задач записи
            unset($wtasks[$url]);
            // добавляем в задачи чтения
            $rtasks[$url] = $sh;
            // формируем http-заголовки
            $headers  = "GET / HTTP/1.0\r\n";
            $headers .= "Host: ".$url."\r\n";
            $headers .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.6) Gecko/2009011913 MRA 5.3 (build 02557) Firefox/3.0.6\r\n";
            $headers .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n";
            $headers .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n";
            $headers .= "Accept-Encoding: gzip,deflate\r\n";
            $headers .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n";
            $headers .= "\r\n";
            // записываем в сокет
            if (fwrite($sh, $headers) === false) fclose($sh);
        }
 
        // сокеты, доступные для чтения
        foreach ($rtasks_ as $sh) {
            // ищем урл страницы по дескриптору сокета в массиве задач чтения
            $url = array_search($sh, $rtasks);
            if (!$url) continue;
            // считываем результат из сокета
            $result = '';
            while ($r = fread($sh, 8192)) $result .= $r;
            // закрываем сокет
            fclose($sh);
            // удаляем из задач чтения
            unset($rtasks[$url]);
            // заносим html в массиы результатов
            $results[$url] = $result;
        }
    }
    else {
        break;
    }
}
?>

Сначала инициализируются три массива: $rtasks – в него будут заноситься сокеты, из которых можно читать данные, $wtasks – для сокетов, готовых к записи, и $results – массив для сохранения содержимого заданных страниц.

Затем в цикле функцией stream_socket_client открываются сокеты для каждого из урлов, при этом ставится флаг STREAM_CLIENT_ASYNC_CONNECT, который указывает, что каждое следующее соединение надо открывать не дожидаясь завершения открытия предыдущего. Флаг STREAM_CLIENT_CONNECT указывает, что мы создаем именно клиентское подключение.
Дескрипторы сокетов заносятся в массив $wtasks.

В 18-ой строке начинается главный цикл, и сразу массивам $rtasks_ и $wtasks_, передаваемым в функцию stream_select, присваиваются массивы, в которых хранятся сокеты для чтения и записи соответственно. Функция stream_select отслеживает наличие данных в потоках и принимает на вход несколько параметров: первый – это массив дескрипторов, в которых ожидается завершение операции чтения, второй – массив с дескрипторами, ожидающими завершение записи, третий – для особых случаев (поступление “out-of-band data” – внеполосных данных) и четвертый параметр – это таймаут. Массивы передаются в функцию по указателям, и как только функция возвращает число больше 0, в них будут находится сокеты, готовые к действиям.

В 28-ой строке мы смотрим, в какие сокеты можно записать данные (надо что-то отправить, прежде чем нам придет ответ-результат), и если такие сокеты есть, то удаляем из массива для записи текущий дескриптор, помещаем его в массив для чтения, и отправляем заголовки, необходимые для получения контента.
Далее, в 49-ой строчке, просматриваем сокеты, готовые для считывания из них данных, забираем содержимое, удаляем дескриптор из масива для чтения и закрываем сокет. Результат заносим в массив $results. Повторяем эти операции до тех пор, пока у нас остаются какие-либо открытые сокеты.

После работы скрипта нужный нам контент находится в массиве $results.

В статье рассмотрен пример работы с функциями stream_socket_*, на очереди асинхронные сокеты.

]]> http://job-interview.ru/articles/post/92/feed 108 PHP и HTTP http://job-interview.ru/articles/post/86 http://job-interview.ru/articles/post/86#comments Mon, 27 Jul 2009 19:00:02 +0000 /articles/?p=86 В этой статье я постараюсь описать работу с HTTP-запросами в языке программирования PHP.

Очень часто на собеседованиях приходится слышать вопрос:

Что происходит, когда пользователь в адресной строке браузера, вводит адрес сайта и нажимает enter?

Ответ должен звучать примерно так:

Отправляется HTTP-запрос по протоколу TCP/IP на сервер, на котором расположен сайт. Далее программа web-сервер (обычно Apache, nginx или lighttpd) принимает этот запрос и в случае, если вызываемый файл — это обычный HTML, то посылает в ответ браузеру свой HTTP-ответ, в котором содержится этот HTML.

Если вызываемый файл — это скрипт, например PHP, то сначала передается управление этому скрипту, который после всех своих операций на выход подает HTML, который web-сервер отсылает HTTP-ответом обратно браузеру.

Получив от сервера HTML, браузер его преобразовывает в удобочитаемый вид согласно стандарту W3C, отправляет дополнительные запросы для отображения изображений или flash и пользователь видит содержимое сайта — текст, картинки, flash и т.д.

В этой статье я дам подробное описание HTTP-запросов и параметров, которые могут в нем содержаться. Потом представлю реализацию обмена HTTP-запросами посредством языка PHP — мы напишем простой прокси-сервер, при обращении к которому он возвращает браузеру страницу сайта, адрес которого был указан в GET-параметре.

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

Кстати, очень полезными бывают утилиты, отображающие HTTP-запросы, которые отправляет и получает браузер. Я пользуюсь для этого браузером Mozilla Firefox и утилитой HttpFox.

Итак, давайте рассмотрим пример.

Введем в адресную строку браузера http://example.com и нажмем enter.

В результате браузер отправит HTTP-запрос вида: 

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

В приведенном примере браузер хочет получить индексную страницу сайта example.com.

Получив запрос от браузера, web-сервер проверяет в своих настройках что является индексным файлом для сайта example.com.

Если это обычный HTML, например файл index.html, то просто возвращается его содержимое.

При запросе индексной страницы сайта http://example.com браузер получает от сервера следующий ответ:

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8 

<HTML>
<HEAD>
  <TITLE>Example Web Page</TITLE>
</HEAD>
<body>
<p>You have reached this web page by typing "example.com",
"example.net",
  or "example.org" into your web browser.</p>
<p>These domain names are reserved for use in documentation and are not available
  for registration. See <a href="http://www.rfc-editor.org/rfc/rfc2606.txt">RFC
  2606</a>, Section 3.</p>
</BODY>
</HTML>

Обратите внимание на 2 перевода строки в ответе сервера. Они являются разделением между параметрами ответа и телом сообщения, содержащего html, который и отображается в окне браузера.

В случае какого-либо скрипта, сначала происходит выполнение этого скрипта, который возвращает web-серверу HTML. Web-сервер в свою очередь отправляет этот HTML браузеру.

Представим себе, что индексной страницей сайта example.com является файл index.php. Web-сервер в этом случае, получив запрос от браузера, сначала передает управление интерпретатору PHP, который выполняет код, содержащийся в этом файле.

Например, в файле index.php содержался бы следующий код:

1
2
3
4
5
6
7
8
9
10

<?php
	if($GET['category'] == 1)
	{
		echo "<p>This is a category of example.com</p>";
	}
	else
	{
		echo "<p>This is a main page of example.com</p>";
	}
?>

Если ввести в адресной строке браузера http://example.com?category=1 и нажать enter, то браузер отправит примерно следующий запрос:

GET /index.php?category=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

От сервера придет в этом случае следующий ответ:

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 39
Connection: close
Content-Type: text/html; charset=UTF-8 

<p>This is a category of example.com<p>

Однако, если в адресной строке браузера ввести http://example.com/index.php, то ответ сервера будет таким: 

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 40
Connection: close
Content-Type: text/html; charset=UTF-8 

<p>This is a main page of example.com</p>

С телом запроса думаю все понятно — в нем содержится html, который и отражается в окне браузера. Давайте теперь разберем что же хранится в параметрах запроса браузера и ответа сервера.

Начнем с HTTP-запроса, который отправляет браузер.

Первая строка – это строка запроса. Она содержит следующие поля, разделенные через пробел:

  • Метод запроса. Может принимать значения: OPTIONS, GET, HEAD, POST, DELETE, TRACE. Целью настоящей статьи не является рассмотрение всех методов. Нам будет достаточно метода GET. Если вы хотите получить описание каждого из методов, то советую обратится к документу RFC 2068
  • Запрашиваемый URI — путь до запрашиваемого ресурса на сервере. Если запрашивается главная страница сайта, то указывается путь до корневого каталога сервера – «/».
  • Версия HTTP-протокола. В этом поле содержится строка вида: «HTTP/1.1». О различных версиях протокола HTTP также можно прочитать в документе RFC 2086.

Далее после строки запроса следуют HTTP-заголовки. Описание каждого заголовка начинается с новой строки и представлено в виде:
ЗАГОЛОВОК: ЗНАЧЕНИЕ.

Рассмотрим заголовки, которые отсылает браузер в нашем примере.

  • Host. Значением для этого заголовка должно быть доменное имя и порт запрашиваемого ресурса. Значение представляется в виде:

    ДОМЕННОЕ_ИМЯ:ПОРТ

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

    В нашем последнем примере для этого заголовка устанавливается значение example.com, т.е. браузер отправляет запрос на сервер example.com и хочет обратиться к файлу /index.php с переданным GET-параметром category=1.

  • User-Agent. Содержит информацию о клиенте, который инициировал запрос к серверу, а также его программное обеспечение. Значение этого поля описывает ряд компонентов клиента. Оно может быть множественным, где все значения отделены друг от друга через пробел.

    В нашем последнем примере значением этого заголовка является:

    Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8

    Здесь описываются параметры браузера и операционной системы — браузер Mozilla Firefox 3.0.8, основанный на движке Gecko, операционная система Linux Suse 11.1 оконной системой X11, процессор с архитектурой i686.

    Этот заголовок используется для статистических целей.

  • Accept. В этом заголовке клиент передает список форматов, которые допустимы для ответа. Значение этого поля хранит список допустимых форматов, разделенных через запятую. Кроме того, для каждого формата можно указать уровень предпочтения от 0 до 1. Если уровень предпочтения не указан, то он считается равным 1. Значение в этом поле должно соответствовать виду:

    ФОРМАТ1[;q=УРОВЕНЬ_ПРЕДПОЧТЕНИЯ1],ФОРМАТ2[;q=УРОВЕНЬ_ПРЕДПОЧТЕНИЯ2]…

    В нашем примере браузер в этом заголовке посылает значение:

    text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

    Его можно прочитать следующим образом: браузер предпочитает ответы в форматах text/html, application/xhtml+xml. Если сервер не может послать ответ в этих форматах, то браузер будет ожидать ответ в формате application/xml. Если же и в этом формате сервер не может послать ответ, то браузер примет ответ в любом формате.

  • Accept-Language. Этот заголовок аналогичен заголовку ACCEPT, только здесь браузер сообщает серверу о своих предпочтениях о естественных языках, в которых должен приходить ответ.

    В нашем примере значением заголовка является:

    ru,en-us;q=0.7,en;q=0.3

    Браузер сообщает серверу, что ждет ответ на русском языке, но также примет ответ на «американском английском» и английском языках.

  • Accept-Encoding. Подобен ACCEPT. В этом заголовке браузер указывает какое кодирование к содержимому допустимо в ответе. Кодирование содержимого необходимо для сжатия или других его преобразований.

    В нашем примере в ответе для браузера допустимо сжатие программой gzip и механизмом deflate:

    gzip,deflate

  • Accept-Charset. Этот заголовок браузер посылает, чтобы сообщить серверу о своих предпочтениях кодировки ответа.

    В нашем примере этот заголовок принимает значение:

    windows-1251,utf-8;q=0.7,*;q=0.7

    Браузер ждет ответ от сервера в первую очередь в кодировке windows-1251, но также примет ответ в любой кодировке.

  • Keep-Alive. Заголовок Keep-Alive содержит значение, которое означает в течение какого времени в секундах будет удерживаться соединение. Этот заголовок следует отправлять только в том случае, если заголовок Connection содержит значение keep-alive.

    Поддерживается только для протокола HTTP версии 1.1.

    В нашем примере этот заголовок содержит значение 300, т.е. браузер сообщает серверу, что намерен удерживать постоянное соединение с сервером в течение 300 секунд.

  • Connection. Информация о проводимом соединении. В нашем примере этот заголовок принимает значение keep-alive, которое говорит серверу о том, что браузер хочет установить постоянное TCP соединение.

    До появления постоянных соединений для запроса каждой страницы сайта устанавливалось отдельное соединение. Открытие каждый раз отдельного соединения требует дополнительной нагрузки на сервер.

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

    Использование постоянных соединений решает эту проблему. Если обе стороны (клиент и сервер) их поддерживают, то, в случае приведенного примера, HTML страницы и каждое изображение могут быть получены за одно TCP соединение.

    Заголовок Connection поддерживается только для протокола HTTP версии 1.1.

    Этот заголовок также может принимать значение close. В этом случае клиент сообщит серверу, что после принятия HTTP-запроса соединение должно быть разорвано.

А теперь давайте рассмотрим параметры HTTP-ответа, который отправляет сервер браузеру.

Первая строка — это строка состояния, которая состоит из следующих полей, разделенных пробелом:

  • Версия протокола HTTP. В нашем ответе от сервера в этом поле содержится HTTP/1.x. Сервер поддерживает протоколы HTTP 1.0 и 1.1.
  • Код состояния ответа. С возможными кодами состояния можно ознакомиться в документе RFC 2068. В нашем случае от сервера нам необходим код состояния ответа, равный 200, который означат, что запрос браузера был выполнен удачно.
  • Комментарий. Комментарий для кода состояния. Если код состояния 200, то комментарий будет «OK».

За строкой состояния следуют HTTP-заголовки, каждый начинается с новой строки. В нашем примере сервер отсылает следующие HTTP-заголовки:

  • Date. В этом заголовке хранится дата в формате RFC 822, описывающее когда отправляемый ответ был сгенерирован. Но это теория, на практике значением этого заголовка может быть любое время.

    В нашем примере в этом заголовке содержится:

    Tue, 21 Jul 2009 17:09:54 GMT.

  • Server. В этом заголовке содержится информация о программном обеспечении, которое используется на сервере, а также его компонентах. Если ответ от сервера направляется через proxy, то используется заголовок «Via».

    В ответе от сервере на наш запрос содержится следующее:

    Apache/2.2.3 (CentOS)

    Это означает, что на сервере используется web-сервер Apache версии 2.2.3. В качестве операционной системы используется дистрибутив Linux CentOS.

  • Last-Modified. В этом заголовке сервер сообщает дату последнего изменения какой-либо сущности — файла, базы данных и т.п. В нашем случае сервер отправляет дату последнего изменения файла index.php.

    Этот заголовок важен для браузера при использовании механизма кеширования. При обращении к какой-либо странице браузер кеширует ее. При повторном обращении к этой странице браузер, основываясь на заголовке Last-Modified проверит не устарела ли страница, сохраненная в кеше. Если нет, то браузер не будет еще раз считывать данные, а выведет страницу из кеша.

    В ответе сервера из нашего примера в этом заголовке хранится:

    Tue, 15 Nov 2005 13:24:10 GMT

  • Etag. В этом заголовке содержится метка объекта ресурса. В нашем случае в качестве объекта выступает файл index.php.

    Наряду с заголовком Last-Modified значение этого заголовка используется при кешировании браузером. При первом запросе страницы браузер сохраняет значение Etag для страницы. При повторном запросе страницы значение Etag, которое пришло от сервера, сравнивается с тем, которое хранится в кеше браузера. Если они равны, то браузеру нет смысла считывать еще раз данные страницы, он просто возьмет их из кеша.

    В нашем примере в ответе сервера Etag имеет следующее значение:

    “b80f4-1b6-80bfd280″

  • Accept-Ranges. Этот заголовок сообщает клиенту о том, что он может запрашивать данные с сервера фрагментами, указывая их смещение в байтах.

    Используется для реализации скачивания файлов с докачкой.

    В нашем примере сервер поддерживает эту возможность, о чем он и сообщает, передав в заголовке Accept-Ranges значение bytes.

    Зная эту возможность, браузер может передать серверу смещение в байтах, с которого необходимо начать передачу файла. Для этого браузер посылает заголовок Range с параметром bytes, значение которого и является смещением в байтах. Например:

    Range: bytes=2048

    Этот заголовок означает, что браузер запросил у сервера содержимое файла, начиная с 2-го мегабайта.

  • Content-Length. Этот заголовок содержит размер тела HTTP-ответа сервера.
    В нашем примере размер тела сообщения 40.

  • Connection. Как и в случае для клиента, этот заголовок предоставляет информацию о проводимом соединении. В нашем примере этот заголовок принимает значение close, которое говорит клиенту о том, что сервер либо не поддерживает постоянное TCP соединение, либо он просто отказывает браузеру в постоянном соединении.

  • Content-Type. В этом заголовке содержится формат тела HTTP-ответа сервера.

    В нашем примере в этом заголовке содержится:

    text/html; charset=UTF-8

    Это означает, что сервер отвечает браузеру данными в формате text/html и кодировке UTF-8.

    В этом заголовке сервера также может храниться, например, «text/css; charset=utf-8» при ответе браузеру на запрос файла CSS. Или, например, может храниться «image/gif» при ответе браузеру на запрос GIF-изображения.

    О других форматах тела сообщения в ответах сервера читайте в RFC 822.

После HTTP—заголовков в ответе сервера содержится 2 перевода строки, за которыми следует само тело сообщения. 2 перевода строки служат разделением между параметрами ответа сервера и телом сообщения, в котором содержится html, отображаемый браузером.

В нашем примере в теле сообщения ответа от сервера содержится:

<p>This is a main page of example.com</p>

Ну а теперь напишем простой прокси-сервер на PHP, который покажет практическое использование упомянутых HTTP-заголовков. 

<?php
$body = "";
// доменное имя передаем в GET-параметре $_GET['host']
$host = $_GET['host'];
// открываем сокет на стандартном для HTTP порту 80
$hSocket = fsockopen($host, 80, $errno, $errstr, 30); 
if ($hSocket)
{
    // первой строкой идет строка запроса
    $request = "GET / HTTP/1.1\r\n";
    // указываем доменное имя
    $request .= "Host: $host\r\n"; 
     // пусть мы будем для сервера браузером Mozilla Firefox
    $request .= "User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.\r\n";
    // указываем форматы, в которых будем ожидать ответ от сервера
    $request .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"; 
    // языки, на которых ожидаем ответ
    $request .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n"; 
    // указываем какое кодирование к содержимому допустимо в ответе. 
    //Только в этом случае нужно будет раскодировать содержимое.
    //$request .= "Accept-Encoding: gzip,deflate\r\n"; 
    // выставляем предпочтения для кодировок ответа
    $request .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n"; 
    // будем удерживать постоянное соединение в течение 300 секунд
    $request .= "Keep-Alive: 300\r\n";
    // открываем постоянное соединение
    // здесь мы завершаем передачу HTTP-заголовков, 
    // поэтому в конце обязательно указываем 2 перевода строки
    $request .= "Connection: keep-alive\r\n\r\n"; 
    // посылаем HTTP-заголовки через открытый сокет
    fwrite($hSocket, $request); 
    // флаг, указывающий на то, что считывается тело запроса
    $bIsData = false; 
    while (!feof($hSocket)) // считываем ответ от сервера
    {
        $str = fgets($hSocket, 128); // построчно
        if($bIsData)
        {
            $body .= $str; // тело запроса записываем в переменную $body
        }
        // встретилась строка, содержащая только перевод строки, это означает, 
        //что дальше пойдет тело запроса
        elseif($str == "\r\n") 
        {
            $bIsData = true;
        }
    }
    fclose($hSocket); // закрываем сокет
 
    // указываем на то, чтобы web-сервер отправил браузеру заголовки 
    // Last-Modified, Connection и Keep-alive
    header("Last-Modified: Tue, 21 Jul 2009 17:09:54 GMT", true);
    header("Connection: Keep-Alive", true); //
    header("Keep-Alive: timeout=30, max=100", true);
    // передаем тело запроса
    echo $body;
}
 
// работа php-скрипта закончена, теперь web-сервер отправляет ответ браузеру
?>

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

В нашем случае один процесс — это процесс браузера, второй — это процесс web-сервера, запущенный на удаленном компьютере.

В PHP сокет открывается функцией fsockopen. Далее в переменную $request мы записываем все нужные нам заголовки и отправляем их серверу функцией fwrite. После этого мы построчно считываем ответ сервера пока не будет достигнут конец данных (feof). После получения ответа мы отправляем этот ответ браузеру вместе с заголовками, которые в PHP выставляются функцией header.

Этот скрипт принимает через GET-параметр доменное имя сайта и отправляет к нему HTTP-запрос, считывает ответ и отдает этот ответ web-серверу, который отправляет его браузеру.

При помощи подобного скрипта вы можете сами поиграться с отправляемыми HTTP-запросами.

Нам этом все. Спасибо за внимание.

Для тех, кто заинтересовался и хочет подробнее изучить HTTP могу посоветовать следующие ссылки:

http://ru.wikipedia.org/wiki/HTTP – статья, подробно описывающая HTTP.

http://www.faqs.org/rfcs/rfc2068.html – документ RFC 2068.

]]> http://job-interview.ru/articles/post/86/feed 5545 “Многопоточность” в PHP (curl) http://job-interview.ru/articles/post/67 http://job-interview.ru/articles/post/67#comments Thu, 09 Jul 2009 07:09:35 +0000 /articles/?p=67 Использование библиотеки curl.

Эта статья является первой из серии “Многопоточность” в PHP

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

Используем это в нашем примере скачивания нескольких страниц.

Рассмотрим сначала процесс скачивания содержимого с одного url. 

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php
$url = 'mail.ru';
// инициализация сеанса curl
$ch = curl_init('http://'.$url);
// curl_exec будет возвращать результат
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
// не будет возвращаться http-заголовок
curl_setopt($ch, CURLOPT_HEADER, 0);
// загрузка страницы и выдача её браузеру
$content = curl_exec($ch);
// завершение сеанса и освобождение ресурсов
curl_close($ch);
?>

Здесь функцией curl_init мы инициализируем сеанс curl и в качестве параметра передаем урл страницы, которую хотим скачать. Далее первым вызовом функции curl_setopt говорим, что результат надо вернуть, а не вывести в браузер, и вторым запрещаем передачу нам http-ответа сервера. curl_setopt принимаюет в качестве параметров дескриптор соединения $ch, название опции и ее значение соответственно. С помощью curl_setopt можно задать много параметров для более тонкого управления соединением, подробнее читайте в мануале к этой библиотеке. Затем функцией curl_exec производим собственно скачивание и в завершении закрываем соединение – curl_close. В переменной $content у нас теперь находится код страницы, указанной в $url.

А сейчас давайте попробуем скачать сразу несколько страниц (основа примера взята из документации на php.net): 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

<?php
 
// страницы, содержимое которых надо получить
$urls = array('yandex.ru', 'google.ru', 'mail.ru', 'rambler.ru');
 
// инициализируем "контейнер" для отдельных соединений (мультикурл)
$cmh = curl_multi_init();
 
// массив заданий для мультикурла
$tasks = array();
// перебираем наши урлы
foreach ($urls as $url) {
	// инициализируем отдельное соединение (поток)
	$ch = curl_init('http://'.$url);
	// если будет редирект - перейти по нему
	curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
	// возвращать результат
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	// не возвращать http-заголовок
	curl_setopt($ch, CURLOPT_HEADER, 0);
	// таймаут соединения
	curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);
	// таймаут ожидания
	curl_setopt($ch, CURLOPT_TIMEOUT, 10);
	// добавляем дескриптор потока в массив заданий
	$tasks[$url] = $ch;
	// добавляем дескриптор потока в мультикурл
	curl_multi_add_handle($cmh, $ch);
}
 
// количество активных потоков
$active = null;
// запускаем выполнение потоков
do {
	$mrc = curl_multi_exec($cmh, $active);
} 
while ($mrc == CURLM_CALL_MULTI_PERFORM);
 
// выполняем, пока есть активные потоки
while ($active && ($mrc == CURLM_OK)) {
	// если какой-либо поток готов к действиям
	if (curl_multi_select($cmh) != -1) {
		// ждем, пока что-нибудь изменится
		do {
			$mrc = curl_multi_exec($cmh, $active);
			// получаем информацию о потоке
			$info = curl_multi_info_read($cmh);
			// если поток завершился
			if ($info['msg'] == CURLMSG_DONE) {
				$ch = $info['handle'];
				// ищем урл страницы по дескриптору потока в массиве заданий
				$url = array_search($ch, $tasks);
				// забираем содержимое
				$tasks[$url] = curl_multi_getcontent($ch);
				// удаляем поток из мультикурла
				curl_multi_remove_handle($cmh, $ch);
				// закрываем отдельное соединение (поток)
				curl_close($ch);
			}
		}
		while ($mrc == CURLM_CALL_MULTI_PERFORM);
	}
}
 
// закрываем мультикурл
curl_multi_close($cmh);
 
?>

Код подробно откомментирован, но давайте разберем все по порядку.
В 7 строчке мы инициализируем контейнер для отдельных соединений curl (далее я буду называть его мультикурл), именно он позволит нам проводить операции с ними параллельно.
Далее в цикле инициализируем соединение (назовем его поток) для каждого урла из нашего массива, попутно добавляя его в мультикурл и в массив заданий $tasks. $tasks – массив, в котором ключами являются адреса наших страниц, а значениями – соответствующие дескрипторы curl. Функция curl_multi_add_handle добавляет к дескриптору нашего мультизапросного соединения отдельное созданное соединение.

В 34 строке запускается цикл для начала работы нашего мультикурла. Функция curl_multi_exec одновременно отправляет на выполнение все объявленные потоки, при этом в переменную $active заносится количество выполняемых потоков.

В основном цикле, начинающемся на 40 строчке, происходят главные действия. Он выполняется до тех пор, пока есть незавершенные потоки или пока не произошла ошибка. В 42 строке вызывается функция curl_multi_select, которая проверяет готовность какого-либо из потоков к дальнейшим действиям с ним. Затем, в 47 строке, функцией curl_multi_info_read получаем информацию о потоке. Но так как curl_multi_info_read обновляет возвращаемую информацию только после вызова curl_multi_exec, сделаем это в строке 45.

Функция curl_multi_info_read возвращает массив, в котором нас интересуют ключи ‘msg’ и ‘handle’. По ‘msg’ мы проверяем, выполнился ли поток, а по ‘handle’ узнаем его дескриптор. Получив дескриптор, ищем по массиву заданий, к какому урлу он относится и записываем вместо него вожделенное содержимое страницы, получаемое функцией curl_multi_getcontent.
Теперь, когда данный поток выполнил свою задачу, удаляем его из мультикурла, а потом закрываем самого.

После завершения всех потоков функцией curl_multi_close закрываем мультикурл.

Сейчас в массиве заданий $tasks находятся html-коды заданных страниц.

Надеюсь, после прочтения статьи стало немного понятнее, как можно реализовать выполнение “многопоточных” запросов на PHP.

В следующей статье рассмотрим использование stream-функций для подобных целей.

]]> http://job-interview.ru/articles/post/67/feed 17579 “Многопоточность” в PHP (вступление) http://job-interview.ru/articles/post/62 http://job-interview.ru/articles/post/62#comments Thu, 09 Jul 2009 07:05:07 +0000 /articles/?p=62 Intro

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

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

Возьмем пример, встречающийся достаточно часто: скачать программно содержимое нескольких страниц. Если страниц немного, то их можно без проблем и больших затрат времени загрузить последовательно. Но если их тысячи? И вот здесь можно применить подходы, позволяющие выполнить скачивание одновременно. Некоторые из них и будут подробно описаны в данном материале. Сначала мы рассмотрим использование библиотеки curl, которая может производить загрузку одновременно нескольких страниц. Затем попробуем применить к нашей задаче stream-функции. После этого сделаем то же самое с помощью асинхронных сокетов. И наконец распараллелим наш процесс функцией fork.

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

Для вступления рассмотрим такой способ, как

Вызов одновременно нескольких копий скрипта

Суть состоит в том, что один скрипт вызывается с разными параметрами, разбивающими задачу на несколько одинаковых подзадач.

Пример. Пусть у нас есть скрипт getcontent.php

1
2
3
4
5
6
7
8
9
10

<?php
$urls = array('yandex.ru', 'google.ru', 'rambler.ru', 'bing.com', 'mail.ru');
 
$k = $_GET['k'];
$url = $urls[$k];
$content = file_get_contents('http://'.$url);
$f = fopen($k.'.cont', 'w');
fwrite($f, $content);
fclose($f);
?>

Здесь $urls – массив урлов, содержимое с которых нам надо получить.
Вызывая этот скрипт как getcontent.php?k=n , где n равен какому-либо ключу массива $urls, мы получим на жестком диске файл с именем n.cont, в котором и сохранен html интересующей нас страницы.

Теперь откроем в браузере пять вкладок, напишем в адресной строке первой http://путь/getcontent.php?k=0, адресной строке второй http://путь/getcontent.php?k=1 и т.д. до http://путь/getcontent.php?k=4 и в каждой быстро нажмем Enter. Если теперь зайти в папку с нашим скриптом, то мы увидим там 5 файлов с html сайтов из масива, причем их получение произошло практически (зависит от того, как быстро жать enter) одновременно. Вот на таком нехитром примере мы показали простейший способ выполнения одного задания в несколько “потоков” :)

Недостаток этого способа в том, что на каждый запущенный скрипт выделяется определенное количество памяти, общее количество которой в данном случае пропорционально количеству запущенных копий скрипта. Другой минус – неудобство управлением данными.

В следующей статье мы попробуем для достижения нашей цели воспользоваться более гуманным способом – использовать библиотеку curl.

]]> http://job-interview.ru/articles/post/62/feed 66 Вопросы на собеседовании для PHP-программиста (часть 2) http://job-interview.ru/articles/post/57 http://job-interview.ru/articles/post/57#comments Wed, 08 Jul 2009 21:18:15 +0000 /articles/?p=57 Итак, в продолжение моей предыдущей статьи, выкладываю следующий список вопросов, на которые мне приходилось отвечать на собеседованиях. В первой статье я разделил их на 7 тем и выложил вопросы из первых двух.

Теперь я затрону 2 темы — это «Администрирование СУБД» и «Основные принципы ООП».

Как уже было упомянуто, я являюсь PHP-программистом и, основываясь на своем опыте прохождения собеседований, могу сказать, что в основном при упоминании СУБД имеется ввиду MySQL, реже PostgreSQL. В настоящей статье я перечислю вопросы, касающиеся администрирования именно MySQL.

Администрирование MySQL

1.  Что работает быстрее? MyISAM или InnoDB? Почему в основном используют MyISAM?

2.  Есть ли для MySQL универсальная защита от SQL-инъекций?

3.  Какими средствами вы будете пользоваться при поиске источника замедления запросов к MySQL? Дайте описание полей, выводимых командой EXPLAIN.

4.  Расскажите о способах хранения деревьев в таблице? Например, когда нужно реализовать древовидные комментарии к статье.

5.  На что вы в первую очередь обратите внимание при при наличии ощутимых «тормозов» MySQL при условии, что все направленные запросы составлены корректно? Расставьте приоритеты:

  • Настройки MySQL
  • Файловая система
  • Язык программирования
  • Память

6.  Перечислите случаи, когда использование индексов может только навредить.

Основные принципы ООП

1.  Чем интерфейс отличается от абстрактного класса?

2.  Как реализовать множественное наследование в PHP?

3.  Напишите класс, реализующий синглтон, подсчитывающий количество попыток создания объектов этого класса.

4.  Каким будет вывод? Объясните.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?
class foo {
  function bar(&$a) 
  { 
    $a++; 
  }
 
  function bar2($a) 
  { 
    ++$a;
  }
}
 
$f =& new foo();
$a = 0; 
$b =& $a; 
$c =& $b; 
$d =& $c;
$f->bar($a);
$f->bar2($a);
echo $d;
?>

5.  Для чего нужен паттерн «Наблюдатель». В каких случаях его применение может быть полезно?

На этом все. В следующей статье я выложу вопросы по оставшимся темам:

  • Регулярные выражения
  • Основные протоколы интернета
  • Работа в командной строке Linux

Вопросы на собеседовании для PHP-программиста (часть 1)

]]> http://job-interview.ru/articles/post/57/feed 45