Столкнулся с одной проблемой.
На сайте установлен плагин main url, который после перенесения сайта на сервер с чистым nginx отказывается работать. Конфиг для nginx брал на этом сайте, все в принципе работает, даже при включении плагина NiceURL rewrite нормально обрабатывает урлы.
Включить NiceURL и отказаться от ручных урлов не выход, так как часть страниц проиндексирована со стандартными урлами а NiceURL меняет все урлы.
Подскажите есть ли выход.

LiveStreet 0.5.1 у нас работает в связке nginx+php-fpm+mariadb, заметил проблему с капчей при регистрации, если даже ввести верно код капчи, выдаёт сообщение, что он таки не правельный. Данная проблема пока замечена была только в firefox.
В какую сторону копать?

Недавно перешел с шаред хостинга на VPS и столкнулся с проблемой что VPS работает не очень быстро, при том что тариф взял не самый дешевый (1600MHz и 1024Mb). Перекопал кучу сайтов чтобы разобраться как все сделать лучшим образом, думаю многие с этим сталкивались, хочу сэкономить ваше время и подытожить важные моменты по настройке.
Для тестирования производительности изначально использовал приложение siege, когда меня там цифры стали более-менее радовать, уже начал использовать для тестов замечательный сайт loadimpact.com (количество бесплатных проверок ограничено, не злоупотребляйте сразу). Привожу картинки как было и как стало (сразу хочу заметить увеличение производительности не только из-за настройки nginx).
1. Debian 5 (64) nginx + apache + php-fcgi + eAccelerator + memcache (Апач по сути только для ISPmanager использовался)

2. Debian 5 (32) nginx + apache + mod_php + APC + memcache


Читать дальше →

Всем привет!

Недавно столкнулся с задачей отказаться от apache на сервере по причине нехватки оперативной памяти. Было решено использовать связку nginx + fcgi. Проблема, с которой я столкнулся при настройке сервера nginx для livestreet — отсутствие у движка единой точки входа. После курения мануала у меня получился вот такой конфиг:

<server {
    set             $path_to_project /var/www/girlstogether.ru;
    server_name     yourservername.ru;
    listen          80;

    access_log      /$path_to_project/logs/access.log;
    root            $path_to_project/htdocs;
    autoindex       off;

    location ~ \.php$ {
        try_files $uri  = 404
        fastcgi_pass    127.0.0.1:9000;
        include         fastcgi_params;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME  $path_to_project/htdocs$fastcgi_script_name;
    }

    location @main {
        fastcgi_pass    127.0.0.1:9000;
        fastcgi_index   index.php;
        include         fastcgi_params;
        fastcgi_param   SCRIPT_FILENAME  $path_to_project/htdocs/index.php;
    }

    location / {
        try_files $uri
                  @main;
        allow all;
    }
}

Видно что тут есть проблемы с дублированием и, возможно, с безопасностью.
Кто нибудь сталкивался с подобной задачей? Как решали?

upd: try_files $uri = 404 (из первого комментария)

Сегодня нас качественно досили, перекрыли ботов фильтрами, но CPU до положенного уровня не сбросилось, ставить апач статус не хотелось.
Стали смотреть почему не падает CPU до положенных нашему серверу 1-3%.
Оказалось проблема с выдачей статистики, (в нашем случае изображений) другим сайтам.
Другими словами, запретим hotlinking для всех, кроме othersite.com — «дружественного» сайта. В конфиг nginx дописываем:

location ~ \.(jpg|jpeg|bmp|jif|bmp|gif|png)$ {
                root   /path/to/public_html/;
                valid_referers server_names none blocked www.othersite.com *.othersite.com;
                if ($invalid_referer) {
                return 403;
                }
            }

В общем после этого CPU упала, и разгрузилось 10% RAM.
Но после дидоса думаю снимать, так как картинки все же картинками, это беклинки и трафик, которые мы так любим.

Проблема началась недавно. Имеется выделенный сервер от Masterhost и никаких претензий по работе на сервере не замечалось. Но недавно после того, как мы стали сотрудничать с новым сис админом он начал настраивать сервер под себя (говорит что старые конф. не трогал) и вот я стал замечать, что во время написания большого топика с изображениями (загружаем с помощью multupload) после нажатия опубликовать браузер начинает долго Грузиться, открываю другой браузер и вижу, что материал уже опубликован почти за секунду, но тот браузер в котором я загружал продолжаем грузится как будто чего то ожидает и после длительного ожидания минут 2-4 либо переходит на главную страницу либо пишет 504 Bad Gateway NGINX, от браузера ничего не зависит поскольку эту процедуру проделывал с разными браузерами, в одном пока грузит в другом уже все загружено. В чем может быть причина? Может виновата скорость моего интернета или сис админ где то не правильно что то настроил и теперь происходит конфликт между NGINX и Apache?

Добрый День!
Прочитал ряд заметок что на связке Debian+ Apache+Nginx+eAccelerator+ Memcache люди имеют Full Time — 0,2 секунды.
Мне такого результата достичь не удалось. Стою в сторонке с вполне скромными 0,8 секунды. Nginx,eAccelerator,Memcache — дефолтные настройки

Отсюда вопрос к сведущим специалистам, не могли бы Вы сформировать мануал, либо опубликовать свои настройки Nginx,eAccelerator,Memcache.

В общем у меня при ошибке 404 перед страницей выводилось шестнадцатеричное число и после страницы — 0. Так, как магическое число все выводилось до заголовка, то весь дизайн ехал выглядел… отвратительно, не говоря уже об общей «неправильности».

Так вот, поиск показал, что это частая проблема связки nginx, ошибки 404 и размера тела ответа. Возникает эта проблема от того, что LiveStreet предполагает использование протокола HTTP/1.1, хотя это может быть не так.
Фиксить легко, надо всего лишь указать в ответе правильный протокол через $_SERVER['SERVER_PROTOCOL'], а не просто HTTP/1.1

Т.е. для livestreet'а надо править файл /classes/actions/ActionError.class.php и менять там

"HTTP/1.1 404 Not Found"

на

"{$_SERVER['SERVER_PROTOCOL']} 404 Not Found"

Никаких негативных последствий это нести не должно, т.ч. возможно этот фикс засунуть непосредственно в livestreet?

На VPS была увеличена оперативная память с 256 до 512. Так как памяти стало больше, было решено также увеличить лимит для eaccelerator с 32 до значения в 128. Но после перезагрузки вываливается ошибка 502 при попытке зайти на сайт. Сервер был установлен по «местной» инструкции, соответственно настройки eaccelerator лежат по следующему пути /etc/php5/apache2/php.ini (если это важно конечно).

Собственно в чем может быть проблема, посоветуйте куда копать?