Comments 31
memcached не пробовали включить для vbulletin? В конфиге включается и настраивается. Учитывая что у Вас vds, то даже при 64-128мб памяти под него получается очень неплохой результат (до 5 раз легко).
А с аттачментами есть вариант перекладывать их в статику (требуется несложный php скрипт: взять из БД, переложить в статику, подправить текст сообщения), а не кэшировать, получается даже лучше и что немаловажно — помогает даже на вирт.хостинге и apache.
А с аттачментами есть вариант перекладывать их в статику (требуется несложный php скрипт: взять из БД, переложить в статику, подправить текст сообщения), а не кэшировать, получается даже лучше и что немаловажно — помогает даже на вирт.хостинге и apache.
мемкэш там есть, но возможно его надо как-то по особенному готовить.
# 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
32Мб маловато, вдс не позволяет хотя бы 64 отдать? Особенно если мемкэшед использует не только форум.
И, простите за дурацкий вопрос, но то что он на сервере есть это понятно, а в конфиге vbulletin он прописан и включен?
И, простите за дурацкий вопрос, но то что он на сервере есть это понятно, а в конфиге vbulletin он прописан и включен?
да можно наверное и 64 отдать. Будет ли отдача — вот в чем вопрос. Для меня вообще было откровением, что архивы так усердно кто-то шерстит.
Архивы шерстят всякие гугло-яндексы, т.к. в них находится чисто контент и минимум хлама, поисковики от этого тащатся и пруться.
И даже есть 2 мнения, 1-ое что архивы надо запрещать к индексации, т.к. это дубли контента, а 2-ое что надо запрещать к индексации основной форум, т.к. архивы индексируются бодрее.
И даже есть 2 мнения, 1-ое что архивы надо запрещать к индексации, т.к. это дубли контента, а 2-ое что надо запрещать к индексации основной форум, т.к. архивы индексируются бодрее.
да, совсем забыл. 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;
Для аттачментов лучше использовать заголовок X-Accel-Redirect в Nginx. Кешировать тогда вообще ничего не нужно, а разграничение прав к файлам останется.
хм… хорошая идея. надо будет попробовать.
А не встречал руководства по написанию плагинов для этого vB?
хочу чтобы он помимо куки сессии добавлял куку что в данный момент пользователь залогинен. Тогда на основании ее отсутствия можно будет закэшировать форум для всех гостей.
А не встречал руководства по написанию плагинов для этого vB?
хочу чтобы он помимо куки сессии добавлял куку что в данный момент пользователь залогинен. Тогда на основании ее отсутствия можно будет закэшировать форум для всех гостей.
хочу чтобы он помимо куки сессии добавлял куку что в данный момент пользователь залогинен. Тогда на основании ее отсутствия можно будет закэшировать форум для всех гостей.Не знаем как для 4-ки, а в 3-шке однозначно было — если нет печенек bbsessionhash и нет печенек bbuserid, то пользователь однозначно не залогинен. Сессионная печенька ставилась с 0 временем жизни, а bbuserid ставилась если юзер логинился с галкой «запомнить меня».
ну так тут как раз трешка.
Все дело в том, что bbsessionhash стопроцентно наличиствует у залогиненного посетителя, с непонятной — у незалогиненого и со стопроцентной у отлогиневшегося — так что эта печенька здесь неупотребима. я раз 8 перепроверял — все думал что где-то лажаю, однако… приходишь чистым и через некоторое время форум тебе ее подставляет.
Все дело в том, что bbsessionhash стопроцентно наличиствует у залогиненного посетителя, с непонятной — у незалогиненого и со стопроцентной у отлогиневшегося — так что эта печенька здесь неупотребима. я раз 8 перепроверял — все думал что где-то лажаю, однако… приходишь чистым и через некоторое время форум тебе ее подставляет.
Не волнуйтесь. bbsessionhash vB использует всегда. Для генерации странички кто и где онлайн, ибо гости там тоже учитываются. Залогиненный юзер всегда имеет bbuserid и никак иначе.
хм… мой опыт описанный выше говорит что это не так.
Не всегда есть bbsessionid. Но вопрос не в том всегда он есть или не всегда, а в том что по нему нельзя отличить залогиненных пользователей от гостей.
я, конечно, поубивал лишнее из заголовков, но не Set-Cookie. А кука bbuserid — это кука автоматической авторизации. К ней еще парная с хешем пароля должна быть. Она будет стоять только тогда, когда посетитель ставил при авторизации галку «запомнить меня»
Не всегда есть bbsessionid. Но вопрос не в том всегда он есть или не всегда, а в том что по нему нельзя отличить залогиненных пользователей от гостей.
я, конечно, поубивал лишнее из заголовков, но не Set-Cookie. А кука bbuserid — это кука автоматической авторизации. К ней еще парная с хешем пароля должна быть. Она будет стоять только тогда, когда посетитель ставил при авторизации галку «запомнить меня»
Для аттачментов лучше использовать заголовок X-Accel-Redirect в Nginx.
После некоторых размышлений возник вопрос. Пока чисто теоретический. А так ли уж хорошо в данном случае будет это решение. Да, кэшировать ничего не надо, однако на каждый запрос посетителем аттача будет дергаться PHP. А с кэшем — не будет. С другой стороны все эти запросы будут легкими…
А с третей стороны — их тоже никто не мешает закэшировать…
Если у вас аттачи могут просматривать даже гости, то попробуйте поставить правило в robots.txt на запрет этого файла поисковиками, нагрузка снизится.
Как топик про nginx с конфигом, так обязательно демонстрация неумения правильно написать даже простейшее регулярное выражение… печально это. =(
Сюда попадет какой-нибудь example.com/some/archive///acss
но не попадет example.com/some.css очевидно.
Смысл autoindex off; для location в который по задумке должны попадать видимо только файлы (?) остается загадкой. У вас где-то выше включен ssi?
А тут вы, либо вы хотели просто
Подозреваю, что исходная задумка была такой:
И для чего двоеточия между переменными в
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 к чему вообще?Сюда попадет какой-нибудь example.com/some/archive///acss
но не попадет example.com/some.css очевидно.
Сюда попадет какой-нибудь example.com/some/archive///acss
но не попадет example.com/archive/some.css очевидно.
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, а что — нет?
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, а что — нет?
Как обычно, а это все кроме хэндлеров и реврайтов.
example.com/archive/some.css прекрасно попадает:
Из чего это видно? У вас внутри этого локейшэна autoindex off; и ssi off; — как первое, так и второе вряд ли могут как-то повлиять на обработку css файла (первое так вообще не в состоянии). Зачем они там нужны — непонятно, это был второй вопрос.
ну проверяется-то просто. Пишется в location
add_header «X-bla» «blablabla»;
и потом в заголовках ответа смотрится попал или нет.
man pcresyntax — это хорошо, но add_header ошибаться вряд-ли может. Сейчас проверил — попадает как в твоем варианте, так и в моем. но твой — лучше.
да, ssi и autoindex там абсолютно не нужны — скопипастилось при переносе.
Думаю стоит исправить статью.
А ну, правильно, вы то тестировали /archive/archive.css
если файл будет называться отлично от archive[тут любой символ]css, то не попадет.
/* — значит 0 или более повторений /, у вас 0,
archive.css попадает под /archive/*.css$, т. е. попадет даже запрос example.com/archive.css
если файл будет называться отлично от archive[тут любой символ]css, то не попадет.
/* — значит 0 или более повторений /, у вас 0,
archive.css попадает под /archive/*.css$, т. е. попадет даже запрос example.com/archive.css
Начните с кеширования php-опкода.
После таких конфигов понимаю, что можно подучить nginx, особенно конфигурацию кеширования, и найти полноценную работу только по его внедрению и поддержке. Наверное, так после госэкзаменов и поступлю.
Помню, кто-то по поводу регистрации Сысоевым компании предсказывал появление специалистов по nginx — а теперь я понял, что это была бы действительно интересная работа\подработка.
Помню, кто-то по поводу регистрации Сысоевым компании предсказывал появление специалистов по nginx — а теперь я понял, что это была бы действительно интересная работа\подработка.
Sign up to leave a comment.
Наблюдения за vBulletin или попытки кэширования динамического контента