Bitrix: Проверка наличия товара на складах.


 <?

//////////////// проверка наличия товара на складах ///////////////////////////////

if(CModule::IncludeModule('catalog')){

 $resStore = CCatalogStore::GetList(array(),array("ACTIVE" => "Y", "TITLE" => "Склад ".$_SESSION["city"]),false,false,array());

 $sklad = $resStore->Fetch();

 $arFilter = Array('PRODUCT_ID' =>$arItem["PRODUCT_ID"], 'STORE_ID' => $sklad["ID"]);

 $rsStore = CCatalogStoreProduct::GetList(array(), $arFilter, false, false, array('AMOUNT'));

 if ($arStore = $rsStore->Fetch())

 {

  $RegionStore = $arStore['AMOUNT'];///////////// наличие в региональном складе

 }

 $resStore = CCatalogStore::GetList(array(),array("ACTIVE" => "Y", "TITLE" => "Склад Центральный"),false,false,array());

 $sklad = $resStore->Fetch();

 $arFilter = Array('PRODUCT_ID' =>$arItem["PRODUCT_ID"], 'STORE_ID' => $sklad["ID"]);

 $rsStore = CCatalogStoreProduct::GetList(array(), $arFilter, false, false, array('AMOUNT'));

 if ($arCentrStore = $rsStore->Fetch())

 {

  $CentrStore = $arStore['AMOUNT'];///////////// наличие на центральном складе

 }

}

?>

Docker на ubuntu через прокси

sudo nano /etc/default/docker
раскомментировать  строку http_proxy ...

Установите docker с помощью скрипта:

curl -sSL https://get.docker.com/ | sh

Примечание: Если ваш сервер находится за прокси фильтрацией, вы можете обнаружить, что команде apt-key не удается получить ключ для докер репозитория во время установки. Чтобы обойти эту проблему, добавьте ключ непосредственно с помощью следующих действий: wget -qO- https://get.docker.com/gpg | sudo apt-key add -

Локальный вебсервер без боли с Docker

Локальный вебсервер без боли с Docker:



'via Blog this'



Локальный вебсервер без боли с Docker

Всем доброго времени суток!
Довольно давно я сюда уже не писал, но сегодня решил сделать исключение и написать пост с решением одной проблемы - лично мне уже давно лень тестировать различные CMS на PHP хотя бы потому что приходится делать однотипные действия - добавить хост в Apache, добавить пользователя и базу в MySQL. А потом еще не забыть все это удалить чтобы не замусоривалось.
Сразу оговорюсь что для локальной разработки я в основном использую Vagrant и Docker т.к. не хочу захламлять основную систему установленным LAMP-стеком. Обычно после пары тройки однотипных добавлений новых хостов получалось что виртуальные машины и контейнеры замусоривались никому не нужными БД и конфигами для сайтов которые уже неактуальны. Да и в hosts нет уже желания видеть бесчисленную череду всяких blog.dev,test.dev,site.dev и т.д.
Ну а сегодня я решил сказать «Хватит!».
Выбор решения
Реализовать решил все на Docker т.к. он обладает рядом неоспоримых плюсов:
  1. Это не виртуальная машина -> контейнер жрет меньше ресурсов и стартует мнгновенно
  2. Если не закоммитить изменения вручную то при остановке контейнера все ваши изменения в контейнере никуда не запишутся.
Второй пункт особенно для нас важен так как мы планируем изменять только код веб-приложений, сами настройки серверного ПО пусть будут постоянными.
Статья рассчитана в основном на линуксоидов т.к. для той же Windows придется сперва поднять виртуальную машину с Linux и уже только на ней Docker. Думаю что в таком случае проще поставить какой-нибудь OpenServer и в ус не дуть :P
Для Mac OS X кстати говоря вроде запилили нативный инсталлятор докера.
Тут должна была быть картинка по теме, но таковых нет. Поэтому чтобы хоть как то разбавить скучный текст держите сиськи xD
Ну да ладно, что-то я отвлекся.
Итак, вот краткий рецепт:
  1. Ставим Docker (желательно отсюда из раздела Installation т.к. в репах дистрибутивов обычно старые версии докера)
  2. Скачиваем образ моего контейнера с hub.docker.io:
    sudo docker pull rhamdeew/lamp
  3. Создаем директорию для проекта:
    mkdir ~/dockertest
  4. Запускаем контейнер:
    sudo docker run -v ~/dockertest/:/var/www/srv/ -p 80:80 -t -i rhamdeew/lamp /bin/bash
  5. В контейнере:
    cp -R /var/www/example /var/www/srv
  6. В контейнере:
    cd /var/www/srv
  7. В контейнере:
    ./start.sh
  8. В браузере открываем: http://localhost/1.php
  9. Видим вывод phpinfo =)
Теперь рассказываю что же мы такое сделали
Итак, первым делом мы стянули образ с преднастроенным контейнером, там уже установлены Apache2, PHP и MySQL, а в директории /var/www/example лежит шаблон для добавления проектов.
Далее мы стартуем контейнер.
Если внимательно посмотреть на аргументы запуска контейнера то можно увидеть что для контейнера мы прокинули нашу локальную директорию ~/dockertest в /var/www/srv у контейнера и также прокинули наружу 80 порт.
После старта контейнера (обычно это моментально!) мы получаем доступ к рутовой консоли внутри контейнера. Тут вспоминаем про то что я заботливо положил шаблон для нового проекта в /var/www/example и копируем его в /var/www/srv помня что на хостовой машине это папка ~/dockertest/. После мы переходим в /var/www/srv и запускаем скрипт start.sh.
Сам скрипт ничего магического не делает, просто стартует MySQL с Apache2 и подгружает базу данных из дампа лежащего в db/db.sql с реквизитами указанными в db/db.txt.
Там же кстати лежит скрипт stop.sh который дампит базу обратно в db.sql (ведь в процессе работы мы могли что-то писать в базу). Его нужно запускать после того как вы поработали с контейнером и решили его остановить.
В итоге получается что нам больше не нужно канифолить себе мозги кучей конфигов и иметь на компе минимальный набор - наш контейнер с LAMP и директории с проектами.
Реальный пример
Для примера покажу как теперь можно заценить новую версию Wordpress:
  1. Копируем наш шаблон проекта:
    cp -R ~/dockertest ~/wordpress
  2. Скачиваем архив с wordpress и распаковываем его в ~/wordpress/www
  3. Опционально правим ~/wordpress/db/db.txt где указываем желаемые реквизиты: название БД, имя пользователя и пароль
  4. Стартуем контейнер:
    sudo docker run -v ~/wordpress/:/var/www/srv/ -p 80:80 -t -i rhamdeew/lamp /bin/bash
  5. В контейнере:
    cd /var/www/srv/
  6. В контейнере:
    ./start.sh
  7. В браузере открывем http://localhost/ и приступаем к установке Wordpress, если в п.2 ничего не меняли то во время установки указываем в качестве реквизитов БД везде test
Различные улучшения и вариации
Конечно данное решение неидеальное и обладает некоторым количеством минусов. К примеру после долгой работы над сайтом можно случайно заглушить контейнер и потерять все изменения в БД. Тут в качестве решения можно выгружать БД например по крону. Думаю что можно скрипт stop.sh как то повесить на запуск при остановке контейнера, но пока до этого не дошел. Кстати start.sh также можно воткнуть куда-нибудь в init-скрипты.
Можно пойти дальше и сделать 2-3 контейнера с разными версиями ПО, но схожими настройками - для масштабных тестов вообще ок.
Тут еще должно быть 100500 примеров использования, но если вы вольетесь в данную тему то вероятно придумаете варианты и получше моих =)

Bitrix. Очистить корзину. Ajax.

Шаблон формы авторизации:


<a href="#" class="delete-cart-link">очистить корзину</a>

Ajax скрипт:


$(document).ready(function (){

 $.ajax({
  type: 'POST',
  url: "/include/cart.php",
  data: {mode:'delcart'},
  dataType: 'json',
  success: function(result){
   if(result.status){
    location.href = "/personal/cart/";
    return false;
   }
  },
 });
});

Обработчик /include/cart.php


<?

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

$result = array();

$result['status'] = false;

$result['message'] = '';



if (isset($_POST['mode'])){

 $mode=htmlspecialcharsbx($_POST['mode']);

 switch($mode)

 {

 case 'delcart':

  CModule::IncludeModule("sale");

  CSaleBasket::DeleteAll($_SESSION["SALE_USER_ID"]);

  $result['status']=true;

  break;

 }

}



exit(json_encode($result));



require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/epilog_after.php");

Bitrix. Авторизация по номеру телефона

Шаблон формы авторизации:


 <form id="fnt" name="system_auth_form<?=$arResult['RND']?>" method="post" target="_top" action="#"  data-ajax-href="/include/auth.php">

  <input type="hidden" name="mode" value="login" />

  <?if (strlen($arParams["BACKURL"]) > 0 || strlen($arResult["BACKURL"]) > 0):?>

  <input type="hidden" name="backurl" value="<?=($arParams["BACKURL"] ? $arParams["BACKURL"] : $arResult["BACKURL"])?>" />

  <?endif?>

  <input type="text" name="USER_LOGINt" maxlength="255" required placeholder="+7">

  <input type="password" name="USER_PASSWORD" maxlength="255">

  <input type="checkbox"  name="USER_REMEMBER" id="USER_REMEMBER" checked>

  <input type="submit" name="Login" class="" value="вход" />

 </form>


Ajax скрипт:


$(document).ready( function(){

  var form_item5 = $('#fnt');

  form_item5.validate({

   rules: {

    USER_LOGIN: {required: true}

   },

   messages: {USER_LOGIN: 'Ошибка в форме'},

   errorClass: 'error',

   validClass: 'valid',

   invalidHandler: function(event, validator) {},

   errorPlacement: function(error, element) {

    var cur = element;

    error.addClass('error-message').insertAfter(cur);

   },

   submitHandler: function(form,event) {

     var msgdata=$("#fnt").serialize();

     $.ajax({

      type: 'POST',

      url: form_item5.attr('data-ajax-href'),

      data: msgdata,

      dataType: 'json',

      success: function(result){

       if(result.status){

        $.fancybox.open('<div  id="popup-success">\

        <div class="title">Здравствуйте '+result.message+'!</div>\

        </div>',{wrapCSS: 'fancybox-popup', padding: ['0','0','0','0'], closeClick  : false,'beforeClose': function() { location.href = result.backurl; }, hideOnContentClick: false });

        form_item5.get(0).reset();

        form_item5.find('.valid').removeClass('valid');

       }

      }

     });

     event.preventDefault();

   }

  });

});


Обработчик /include/auth.php



<?

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");



global $USER;

if(!is_object($USER)) $USER = new CUser;

$result = array();

$result['status'] = false;

$result['message'] = '';

if (isset($_POST['mode'])){

 $mode=htmlspecialcharsbx($_POST['mode']);

 switch($mode)

 {

 case 'login':

  if(!$USER->IsAuthorized())

  {

   $user_tel = htmlspecialcharsbx($_POST['USER_LOGINt']);

   $filter = Array("PERSONAL_PHONE" => $user_tel);

   $sql = CUser::GetList(($by="id"), ($order="desc"), $filter);

   if($sql->NavNext(true, "f_"))

   {

    if($_POST['USER_REMEMBER']=="on") $rem="Y"; else $rem="N";

    $arAuthResult = $USER->Login($f_LOGIN, $_POST['USER_PASSWORD'], $rem);

    $result['status']=true;

    $result['message']=$f_NAME;

    $result['backurl']=$_POST['backurl'];

    $APPLICATION->arAuthResult = $arAuthResult;

   }

  }

  break;

 }

}

exit(json_encode($result));
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/epilog_after.php");

Авторегистрация пользователя (продолжить без регистрации)



 if ($arResult["POST"]["~WITHOUTREG"]==1)
{
$login='User'.bitrix_sessid();
$pwd='Pwd'.bitrix_sessid();
$email=bitrix_sessid().'_autoReg';
$name='';
$lastname='';
COption::SetOptionString("main","captcha_registration","N");
COption::SetOptionString("main","new_user_registration_email_confirmation","N");
$arAuthResult = $USER->Register($login,"","",$pwd,$pwd,$email);
LocalRedirect($arParams["PATH_TO_ORDER"]);
COption::SetOptionString("main","captcha_registration","Y");
COption::SetOptionString("main","new_user_registration_email_confirmation","Y");
}

Bitrix. Фильтр товаров по дате

Создаем свойство для времени. У меня это PROPERTY_2174 и поехали...
global $arrFilter;
if (!is_array($arrFilter)) $arrFilter = array();
$arrSale=array('broken_package'=>'Нарушена упаковка','damage'=>'Царапина на корпусе','broken_complect'=>'Нарушена комплектность','defect'=>'Брак');
if(isset($_GET['tab'])){
 if($_GET['tab']=='new') {$arrFilter=array_merge($arrFilter, array('>PROPERTY_2174' => array ( 0 => date("Y-m-d 00:00:00", strtotime('-14 day'))), '<=PROPERTY_2174' => array ( 0 => date("Y-m-d 00:00:00"))));}
 if($_GET['tab']=='hit') {$arrFilter=array_merge($arrFilter, array("=PROPERTY_1990" => array ( 0 => '163', ))); }
 
}
?>
IncludeComponent(
 "bitrix:catalog", 
 "catalog", 
 array(
  "IBLOCK_TYPE" => "offers",
  "IBLOCK_ID" => $ib["ID"],
  "TEMPLATE_THEME" => "site",
  ...
  "FILTER_NAME" => "arrFilter",
  ...
 ),
 false
);


Авторизация на сайте по e-mail'у

Сохранение значения свойств элемента информационного блока.



require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
$ELEMENT_ID = 97517;  // код элемента
$PROPERTY_CODE = "HIT";  // код свойства
$PROPERTY_VALUE = 163;  ///"Y";  // значение свойства
$IBLOCK_ID = 241;

//вывод праметров элемента
$res = CIBlockElement::GetByID($ELEMENT_ID);
echo "".var_export($res->GetNext())."";
//end вывод праметров элемента

// Вывод сыойств до изменения
$db_props = CIBlockElement::GetProperty($IBLOCK_ID, $ELEMENT_ID, "sort", "asc", array());
echo "".var_export($db_props)."";
//end Вывод сыойств до изменения

// Установим новое значение для данного свойства данного элемента CIBlockElement::SetPropertyValues
$dbr = CIBlockElement::GetList(array(), array("=ID"=>$ELEMENT_ID), false, false, array("ID", "IBLOCK_ID"));
if ($dbr_arr = $dbr->Fetch())
{
  $IBLOCK_ID = $dbr_arr["IBLOCK_ID"];
  CIBlockElement::SetPropertyValues($ELEMENT_ID, $IBLOCK_ID, Array('HIT'=>163), false);
}
//end Установим новое значение для данного свойства данного элемента CIBlockElement::SetPropertyValues

// Вывод сыойств после изменения
$db_props = CIBlockElement::GetProperty($IBLOCK_ID, $ELEMENT_ID, "sort", "asc", array());
echo "".var_export($db_props)."";
//end Вывод сыойств после изменения?>


// Установим новое значение для данного свойства данного элемента CIBlockElement::Update
$el = new CIBlockElement;$PROP = array();
$PROP['HIT'] = $PROPERTY_VALUE;  // свойству с кодом 12 присваиваем значение "Белый"
$arLoadProductArray = Array(
  "MODIFIED_BY"    => $USER->GetID(), // элемент изменен текущим пользователем
  "IBLOCK_SECTION" => false,          // элемент лежит в корне раздела
  "PROPERTY_VALUES"=> $PROP,
  "ACTIVE"         => "Y",            // активен
  );
$res = $el->Update($ELEMENT_ID, $arLoadProductArray);
//end Установим новое значение для данного свойства данного элемента CIBlockElement::Update

// Вывод сыойств после изменения
$db_props = CIBlockElement::GetProperty($IBLOCK_ID, $ELEMENT_ID, "sort", "asc", array());
echo "".var_export($db_props)."";
//end Вывод сыойств после изменения

//end Установим новое значение для данного свойства данного элемента CIBlockElement::SetPropertyValueCode
CIBlockElement::SetPropertyValueCode($ELEMENT_ID, $PROPERTY_CODE, $PROPERTY_VALUE);
//end Установим новое значение для данного свойства данного элемента CIBlockElement::SetPropertyValueCode

// Вывод сыойств после изменения
$db_props = CIBlockElement::GetProperty($IBLOCK_ID, $ELEMENT_ID, "sort", "asc", array());
echo "".var_export($db_props)."";
//end Вывод сыойств после изменения?>


Atom установка пакетов через прокси


apm config set https-proxy http://login:pass@ip:port
apm config set http-proxy http://login:pass@ip:port

проверяем
apm config get https-proxy
apm config get http-proxy

Настройка виртуального хоста для Nginx


В моем случае настройка производится на дистрибутиве Linux Debian 6.0.


Устанавливаем программное обеспечение:
1# apt-get install apache2 nginx libapache2-mod-rpaf
После этого меняем параметры соединений, поскольку нам необходимо запустить Apache на другом порту. В нашем случае — это 8080, но вы можете использовать любой на ваш вкус. Для изменения порта правим строчки в конфигурационном файле /etc/apache2/ports.conf:
1
2
NameVirtualHost *:8080
Listen 8080
Так же необходимо внести соответствующие изменения в файлы виртуальных хостов. Для примера создадим виртуальный хост sample.ru.
В целях повышения производительности можно отключить Keep Alive соединения. Для этого поправим директиву в файле /etc/apache2/apache2.conf
1
KeepAlive off
Важно: Если у вас дистрибутив Linux не Debian или Ubuntu, то расположение конфигурационных файлов и их имена могут отличаться. Например, в большинстве случаев все настройки хранятся в общем конфигурационном файле /etc/apache2/httpd.conf. Так же в некоторых дистрибутивах Linux и Unix сам Apache может располагаться в иных директориях. Возможные варианты:
  • /etc/apache2
  • /etc/httpd
  • /usr/local/etc/apache2
  • /usr/local/etc/httpd
  • /usr/local/etc/www
  • /usr/local/apache2
  • /usr/local/httpd
  • /usr/local/www
Это те варианты, которые мне встречались в практике на различных платформах. Далее, все настройки будут приводиться в привязке к дистрибутивам Linux Debian и Linux Ubuntu, а вы самостоятельно делайте поправку на свой случай.

Создание виртуального хоста в apache

Создаем новый файл /etc/apache2/sites-available/sample.ru. В файл помещаем следующий текст:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<VirtualHost *:8080>
    ServerAdmin webmaster@sample.ru
    ServerName www.sample.ru
    ServerAlias sample.ru
     DocumentRoot "/var/www/sample.ru/"

        <Directory /var/www/sample.ru>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
        </Directory>
     ErrorLog ${APACHE_LOG_DIR}/sample.ru-error.log
    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn
    CustomLog ${APACHE_LOG_DIR}/sample.ru-access.log combined
</VirtualHost>
Важно не забыть поставить порт 8080 в директиве VirtualHost!
Активизируем наш виртуальный хост и перезапускаем апач:

1
2
# a2ensite sample.ru
# /etc/init.d/apache2 restart
Теперь наш виртуальный хост доступен по адресу:

Верный REMOTE_ADDR для Apache

В связке с Nginx Apache будет распознавать REMOTE_ADDR как адрес локального хоста 127.0.0.1, даже несмотря на то, что в настройках Nginx мы будем передавать явно REMOTE_ADDR. Для решения этой проблемы достаточно установить модуль Apache RPAF. В Debian он обычно включен в метапакет Apache, поэтому его достаточно просто активировать и перезапустить Apache:
?
1
2
# a2enmod rpaf
# /etc/init.d/apache2 restart

Настройка Nginx

В нашем случае настройка Nginx будет ограничена минимальным объемом работы, необходимым только для эффективной работы Nginx связки с Apache.
Для начала, объясню общую идею всей нашей работы. Nginx принимает запросы от пользователей на 80 порту, далее принимает решение перенаправить запрос к Apache или обработать его самостоятельно. К Apache уходят запросы связанные с отображением динамического содержимого, например: обработка php-скриптов. Статическое содержиное Nginx отдает самостоятельно без участия Apache. К статическому у нас отностяся файлы картинок, текстовые файлы, таблицы стилей, JavaScript файлы, иконки, XML-файлы и пр. Будьте осторожны с обработкой запросов к файлам html. Дело в том, что на сайтах с включенным ЧПУ запрос к html файлу через модуль Apache mod_rewrite может приводить к запуску скрипта для возврата корректного содержимого. Во избежании ошибок запросы к html файлам тоже должен обрабатывать Apache.
Ранее мы отключили у Apache поддержку Keep Alive. В связке с Nginx такая мера дает ощутимый припрост производительности. Apache обработав запрос и вернув содержимое Nginx, отключается и переходит к обработке других запросов, а процесс Nginx уже самостоятельно занимается отправкой результата пользователю. Ресурсов процесс Nginx практически не потребляет, поскольку фактически работает только со статикой. Apache же может жрать просто огромное количество ресурсов.
Приведу пример одного из моих проектов, который имеет более 10 тыс. посетителей в сутки. Запросов, соответственно к сайту просто коллосальное количество. Сайт работает на достаточно ресурсоемком движке Bitrix. Одно обращение к сайту отхватывает от 300Мб до 2,5Гб оперативной памяти. Если проект запустить без Front-end, то сайт при текущей загруженности будет тормозить по-черному, если вообще сможет обрабатывать запросы. Что мы получаем в итоге работы связки. Сервер достаточно мощный, поэтому даже ресурсоемкие запросы обрабатывает мгновенно. Apache обработав запрос, сразу отдает содержимое Nginx и освобождается для обработки следующего запроса. Nginx, обрабатывая запрос к конкретной странице, уже использует всего 0,5-2Мб оперативной памяти. Ощутимая разница! За счет этого нагруженный проект вполне себе нормально живет. Конечно, в приведенном примере есть еще особенности настройки MySQL сервера, но тема настройки MySQL выходит за рамки данной статьи. Обязательно сделаю статью и на тему базовой настройки MySQL для работы с Bitrix на больших проектах.
Кстати, если говорить о Bitrix, то тема настройки Front-end на серверах с сайтами под Bitrix крайне актуальна, особенно, если Интернет-магазин реализован на этой CMS. При всей громоздкости Bitrix, эта CMS уверено набирает популярность, поскольку имеет массу дополнений для работы с 1С:Предприятием. Административная часть вполне дружелюбна для пользователя, особенно в сравнении с CMS распространяемыми по лицензии GPL. 1С программисты могут создавать выгрузки товаров из 1С:Предприятия в любых разрезах и с любыми параметрами руководствуясь просто стандартами обмена данными 1С.
Итак, перейдем непосредственно к настройке.

Основной конфигурационный файл Nginx /etc/nginx/nginx.conf

Собственно, тут делаем минимальные изменения. Если каких-то директив у вас не хватает, просто добавьте их в соответствующие разделы файла. Чуть ниже я разъясню назначение некоторых директив и их значений.
?
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
#Пользователь под которым работает процесс
user www-data;
# Количество рабочих процессов, зависит от ваших задач и ресурсов оборудования
worker_processes  5;
# Общий лог для ошибок
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
    # Максимальное количество рабочих соединений
    worker_connections  1024;
    # multi_accept on;
    # Метод обработки соединений, разъяснение - ниже
    use epoll;
}
http {
    include       /etc/nginx/mime.types;
    access_log    /var/log/nginx/access.log;
    # Задаёт таймаут при чтении заголовка запроса клиента
    client_header_timeout    3m;
    # Задаёт таймаут при чтении тела запроса клиента
    client_body_timeout        3m;
    # Задаёт таймаут при передаче ответа клиенту
    send_timeout        3m;
    # Задаёт таймаут, в течение которого keep-alive соединение
    # с клиентом не будет закрыто со стороны сервера
    keepalive_timeout        3m;
    # Разрешает или запрещает использовать sendfile()
    sendfile        on;
    #tcp_nopush     on;
    #keepalive_timeout  0;
    #keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Методы обработки соединений директива use раздела events

С выбором метода обработки соединений нужно быть внимательным. Разные методы поддерживаются разными операционными системами.  nginx поддерживает различные методы обработки соединений. Если на платформе доступно сразу несколько методов, nginx обычно сам выбирает наиболее эффективный метод. Однако, при необходимости можно явно выбрать метод обработки соединений с помощью директивы use. Если не уверены, лучше директиву вообще отключить.
Поддерживаются следующие методы обработки соединений:
  • select — стандартный метод. Модуль для поддержки этого метода собирается автоматически, если на платформе не обнаружено более эффективного метода. Можно принудительно разрешить или запретить сборку этого модуля с помощью параметров —with-select_module и —without-select_module.
  • poll — стандартный метод. Модуль для поддержки этого метода собирается автоматически, если на платформе не обнаружено более эффективного метода. Можно принудительно разрешить или запретить сборку этого модуля с помощью параметров —with-poll_module и —without-poll_module.
  • kqueue — эффективный метод, используемый во FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и Mac OS X. Во многих русскоязычных руководствах по настройке Nginx в качестве Front-end для Apache встречается указание именно этого метода, поскольку большинство статей тупо переводные и изначально писались админами FreeBSD или OpenBSD.
  • epoll — эффективный метод, используемый в Linux 2.6+. В некоторых старых дистрибутивах, например SuSE 8.2, есть патчи для поддержки epoll ядром 2.4.
  • rtsig — real time signals, эффективный метод, используемый в Linux 2.2.19+. По умолчанию в общесистемной очереди событий может одновременно находиться не более 1024 сигналов. На нагруженных серверах может потребоваться увеличить размер очереди с помощью параметра ядра /proc/sys/kernel/rtsig-max. Однако, начиная с Linux 2.6.6-mm2, этого параметра уже нет и для каждого процесса существует отдельная очередь сигналов, размер которой ограничивается с помощью RLIMIT_SIGPENDING и может быть изменён с помощью worker_rlimit_sigpending.
  • /dev/poll — эффективный метод, используемый в Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ и Tru64 UNIX 5.1A+. При переполнении очереди nginx сбрасывает её и начинает обрабатывать соединения с помощью метода poll до тех пор, пока ситуация не нормализуется.
  • eventport — event ports, эффективный метод, используемый в Solaris 10.

Настройка виртуального хоста для Nginx

У самого Nginx, как и у Apache есть свои виртуальные хосты. Поэтому для нашего сайта нам нужно указать виртуальный хост sample.ru. Создаем файл /etc/nginx/sites-available/sample.ru. В файл помещаем содержимое:
?
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
server {
    listen   80; ## listen for ipv4
    #listen   [::]:80 default ipv6only=on; ## listen for ipv6
    server_name  sample.ru www.sample.ru;
    access_log  /var/log/nginx/sample.ru-access.log;
    # Максимальный размер тела запроса клиента
    client_max_body_size 10M;
    location / {
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout    120;
        proxy_send_timeout    120;
        proxy_read_timeout    180;
    }
    # Статику Nginx отдает самостоятельно без участия Apache
    location ~* \.(ico|docx|doc|xls|xlsx|rar|zip|jpg|jpeg|txt|xml|pdf|gif|png|css|js)$ {
        root   /var/www/sample.ru/;
    }
}
Теперь активизируем виртуальный хост и перезапускаем Nginx:
?
1
2
# ln -s ../sites-available/sample.ru ../sites-enabled/sample.ru
# /etc/init.d/nginx restart

Итог настройки Nginx в качестве Front-end для Apache

Если все сделали без ошибок, связка должна заработать. На нагруженных проектах эффект будет виден сразу.

Поиск по этому блогу