@xenolog12 фев 2012 в 20:29

Наблюдения за vBulletin или попытки кэширования динамического контента

6 мин

3.2K

Nginx *

Из песочницы

+19

Комментарии 31

@edogs 12 фев 2012 в 20:56

memcached не пробовали включить для vbulletin? В конфиге включается и настраивается. Учитывая что у Вас vds, то даже при 64-128мб памяти под него получается очень неплохой результат (до 5 раз легко).

А с аттачментами есть вариант перекладывать их в статику (требуется несложный php скрипт: взять из БД, переложить в статику, подправить текст сообщения), а не кэшировать, получается даже лучше и что немаловажно — помогает даже на вирт.хостинге и apache.

@xenolog 12 фев 2012 в 21:42

мемкэш там есть, но возможно его надо как-то по особенному готовить.

# memcached-tool 127.0.0.1 stats
#127.0.0.1:11211   Field       Value
         accepting_conns           1
               auth_cmds           0
             auth_errors           0
                   bytes       33678
              bytes_read   465894263
           bytes_written 26183402959
              cas_badval           0
                cas_hits           0
              cas_misses           0
               cmd_flush           0
                 cmd_get    17470932
                 cmd_set       43413
             conn_yields           0
   connection_structures          72
        curr_connections          21
              curr_items          32
               decr_hits           0
             decr_misses           0
             delete_hits           0
           delete_misses           0
               evictions           0
                get_hits    17470784
              get_misses         148
               incr_hits           0
             incr_misses           0
          limit_maxbytes    33554432
     listen_disabled_num           0
                     pid        1336
            pointer_size          32
               reclaimed           0
           rusage_system 3819.461353
             rusage_user  606.043867
                 threads           4
                    time  1329082836
       total_connections       17047
             total_items       42633
                  uptime      281571
                 version       1.4.5

@edogs 12 фев 2012 в 21:50

32Мб маловато, вдс не позволяет хотя бы 64 отдать? Особенно если мемкэшед использует не только форум.
И, простите за дурацкий вопрос, но то что он на сервере есть это понятно, а в конфиге vbulletin он прописан и включен?

@xenolog 12 фев 2012 в 21:54

да можно наверное и 64 отдать. Будет ли отдача — вот в чем вопрос. Для меня вообще было откровением, что архивы так усердно кто-то шерстит.

@edogs 12 фев 2012 в 22:00

Архивы шерстят всякие гугло-яндексы, т.к. в них находится чисто контент и минимум хлама, поисковики от этого тащатся и пруться.

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

@xenolog 12 фев 2012 в 22:01

не, в нашем случае именно люди.
я тоже первым делом на роботов подумал.

@DemRo 13 фев 2012 в 01:29

Много раз видел, что гугл в результатах поиска выводил архивные версии страниц выше обычных.

@xenolog 12 фев 2012 в 22:00

да, совсем забыл. memcached в конфиге прописан:

$config['Datastore']['class'] = 'vB_Datastore_Memcached';
$i = 0;
// First Server
$i++;
$config['Misc']['memcacheserver'][$i]           = '127.0.0.1';
$config['Misc']['memcacheport'][$i]             = 11211;
$config['Misc']['memcachepersistent'][$i]       = true;
$config['Misc']['memcacheweight'][$i]           = 1;
$config['Misc']['memcachetimeout'][$i]          = 1;
$config['Misc']['memcacheretry_interval'][$i] = 15;

@edogs 12 фев 2012 в 22:03

Сегодня день дурацких вопросов… но все же (просто ненормально иметь тормоза при мемкэшед и кэширующихся аттачментах в среднем по палате), выше
$config['Datastore']['class'] = 'vB_Datastore_Memcached';
нет случайно
/*
начала комментария?

@xenolog 12 фев 2012 в 22:12

нету :)
с мемкэшем в этой виртуалке работать некому.
там единственный сайт с PHP — этот форум, все остальное — склад статики. html, картинки…

дал 128 метров рамяти — днем будет видно к чему приведет.

@sdevalex 12 фев 2012 в 21:15

Для аттачментов лучше использовать заголовок X-Accel-Redirect в Nginx. Кешировать тогда вообще ничего не нужно, а разграничение прав к файлам останется.

@xenolog 12 фев 2012 в 21:51

хм… хорошая идея. надо будет попробовать.

А не встречал руководства по написанию плагинов для этого vB?
хочу чтобы он помимо куки сессии добавлял куку что в данный момент пользователь залогинен. Тогда на основании ее отсутствия можно будет закэшировать форум для всех гостей.

@edogs 12 фев 2012 в 21:58

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

Не знаем как для 4-ки, а в 3-шке однозначно было — если нет печенек bbsessionhash и нет печенек bbuserid, то пользователь однозначно не залогинен. Сессионная печенька ставилась с 0 временем жизни, а bbuserid ставилась если юзер логинился с галкой «запомнить меня».

@xenolog 12 фев 2012 в 22:07

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

@NickyX3 13 фев 2012 в 07:51

Не волнуйтесь. bbsessionhash vB использует всегда. Для генерации странички кто и где онлайн, ибо гости там тоже учитываются. Залогиненный юзер всегда имеет bbuserid и никак иначе.

@xenolog 13 фев 2012 в 08:03

хм… мой опыт описанный выше говорит что это не так.
Не всегда есть bbsessionid. Но вопрос не в том всегда он есть или не всегда, а в том что по нему нельзя отличить залогиненных пользователей от гостей.

я, конечно, поубивал лишнее из заголовков, но не Set-Cookie. А кука bbuserid — это кука автоматической авторизации. К ней еще парная с хешем пароля должна быть. Она будет стоять только тогда, когда посетитель ставил при авторизации галку «запомнить меня»

@NickyX3 13 фев 2012 в 08:15

тут мы сделали у себя небольшой «чит»- кастомная форма афторизации, в которой галка ставится автоматически, кхе-кхе. Но тут специфика — мы используем базу форума для сквозной авторизации на сайте

@NickyX3 13 фев 2012 в 08:34

И еще, кастом аватары в vB надо вываливать на диск, они отлично отдаются статикой через nginx.

@xenolog 14 фев 2012 в 20:26

Для аттачментов лучше использовать заголовок X-Accel-Redirect в Nginx.

После некоторых размышлений возник вопрос. Пока чисто теоретический. А так ли уж хорошо в данном случае будет это решение. Да, кэшировать ничего не надо, однако на каждый запрос посетителем аттача будет дергаться PHP. А с кэшем — не будет. С другой стороны все эти запросы будут легкими…

А с третей стороны — их тоже никто не мешает закэшировать…

@Isis 12 фев 2012 в 21:37

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

@xenolog 13 фев 2012 в 10:44

но тогда яндекс-картинки, если я правильно понимаю, пойдут лесом

@VBart 13 фев 2012 в 08:28

Как топик про nginx с конфигом, так обязательно демонстрация неумения правильно написать даже простейшее регулярное выражение… печально это. =(

location ~ /archive/*.css$ {
    autoindex off;
    ssi     off;
}

Сюда попадет какой-нибудь example.com/some/archive///acss
но не попадет example.com/some.css очевидно.

Смысл autoindex off; для location в который по задумке должны попадать видимо только файлы (?) остается загадкой. У вас где-то выше включен ssi?

location ~ /archive/.*$ {

А тут вы, либо вы хотели просто location ~ /archive/, либо (скорее всего) location /archive/. Хвост в виде ".*$" — просто трата процессорных тактов впустую.

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

    location /archive/ {

        location ~ \.css$ {
        ...
        }

        ...
    }

И для чего двоеточия между переменными в fastcgi_cache_key? А fastcgi_index index.php; в location = /attachment.php к чему вообще?

@VBart 13 фев 2012 в 08:32

Сюда попадет какой-нибудь example.com/some/archive///acss
но не попадет example.com/some.css очевидно.

Сюда попадет какой-нибудь example.com/some/archive///acss
но не попадет example.com/archive/some.css очевидно.

@xenolog 13 фев 2012 в 11:14

location ~ /archive/*.css$ {
autoindex off;
ssi off;
}

Сюда попадет какой-нибудь example.com/some/archive///acss
но не попадет example.com/some.css очевидно.

example.com/archive/some.css прекрасно попадает:
запрос:

(Request-Line)	GET /archive/archive.css HTTP/1.1
Host	forum.domain.com
User-Agent	Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0
Accept	text/css,*/*;q=0.1
Accept-Language	ru,ru-ru;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding	gzip, deflate
DNT	1
Connection	keep-alive
Referer	http://forum.domain.com/archive/index.php/t-95047.html
Cookie	bblastvisit=1320665750; bblastactivity=0; __utma=197402040.1863018890.1320676652.1320676652.1321889456.2; __utmz=197402040.1320676652.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=105643271.354523356.1320845750.1320845750.1321953025.2; __utmz=105643271.1320845750.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); bbuserid=75; bbpassword=9df20b27837d2fab3bd5c9e379r16833; google=1; PHPSESSID=dn2726be2jia5rfo604d0lbq80; uid=ZCuiGU854reB81LoBEAkAg==

ответ:

(Status-Line)	HTTP/1.1 200 OK
Server	nginx/1.1.13
Date	Mon, 13 Feb 2012 11:06:32 GMT
Content-Type	text/css
Content-Length	2255
Last-Modified	Sun, 05 Sep 2010 07:44:48 GMT
Connection	keep-alive
Keep-Alive	timeout=20
Accept-Ranges	bytes

но за идею с вложенными location — благодарю. Не поведаешь, чем они так повышают производительность и что наследуется от предыдущего уровня location, а что — нет?

@VBart 13 фев 2012 в 11:28

example.com/archive/some.css прекрасно попадает:

Из чего это видно? У вас внутри этого локейшэна autoindex off; и ssi off; — как первое, так и второе вряд ли могут как-то повлиять на обработку css файла (первое так вообще не в состоянии). Зачем они там нужны — непонятно, это был второй вопрос.

URI "/archive/some.css" под регулярное выражение "/archive/*.css$" попадать просто не может,
собственно man pcresyntax для ознакомления.

но за идею с вложенными location — благодарю. Не поведаешь, чем они так повышают производительность

Тем, что location заданные regexp-ами матчаться по очереди выполняя при этом нетривиальные pcre-шный код. Читать: nginx.org/ru/docs/http/ngx_http_core_module.html#location

А location-ы заданные простыми префиксами ищутся по дереву — это гораздо эффективнее.

и что наследуется от предыдущего уровня location, а что — нет?

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

@xenolog 13 фев 2012 в 12:00

example.com/archive/some.css прекрасно попадает:

Из чего это видно? У вас внутри этого локейшэна autoindex off; и ssi off; — как первое, так и второе вряд ли могут как-то повлиять на обработку css файла (первое так вообще не в состоянии). Зачем они там нужны — непонятно, это был второй вопрос.

ну проверяется-то просто. Пишется в location
add_header «X-bla» «blablabla»;
и потом в заголовках ответа смотрится попал или нет.
man pcresyntax — это хорошо, но add_header ошибаться вряд-ли может. Сейчас проверил — попадает как в твоем варианте, так и в моем. но твой — лучше.

да, ssi и autoindex там абсолютно не нужны — скопипастилось при переносе.
Думаю стоит исправить статью.

@VBart 13 фев 2012 в 12:22

А ну, правильно, вы то тестировали /archive/archive.css
если файл будет называться отлично от archive[тут любой символ]css, то не попадет.

/* — значит 0 или более повторений /, у вас 0,

archive.css попадает под /archive/*.css$, т. е. попадет даже запрос example.com/archive.css

@xenolog 13 фев 2012 в 13:17

хм… забавно получилось…

@AlexeyK 13 фев 2012 в 13:20

Начните с кеширования php-опкода.

@xenolog 14 фев 2012 в 11:00

Изначально форум за-xCache-н

@Paskal 14 фев 2012 в 09:51

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий