• DONATE to NULLED!
    Вы можете помочь Форуму и команде, поддержать финансово.
    starwanderer - модератор этого раздела будет Вам благодарен!

Помощь Оптимизация wordpress или что-то еще?

Статус
В этой теме нельзя размещать новые ответы.

UFOS

Создатель
Регистрация
19 Июн 2008
Сообщения
29
Реакции
1
Есть выделенный сервер 2ghz Cor2Duo память 3gb
Установлен Debian 507

Проц конечно слабоват но не думаю, что уж на столько.

На сие деле Висит WordpPress ласт вершн 3.0.4 Включено ЧПУ.
База данного сайта составляет полтора гигабайта. Постоянно оптимизируется раз в 3 часа.

Плагины имеем:
All in One SEO Pack
Customize Meta Widget
Executable PHP widget
FeedMaster (1.7 версия до 2ки пока не стал обновлять всего хватает)
Optimize DB
RusToLat
Simply Exclude
WP-NoRef
WP-SpamFree
WP Missed Schedule
WP Super Cache
XML Sitemap Feed

конфиг апача,

Timeout 40
KeepAlive Off
MaxKeepAliveRequests 200
KeepAliveTimeout 2

StartServers 2
MinSpareServers 2
MaxSpareServers 5
MaxClients 50
MaxRequestsPerChild 0

вывод mysqltuner

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.51a-24+lenny5
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1515M (Tables: 26)
[!!] Total fragmented tables: 1

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2h 24m 35s (259K q [29.957 qps], 5K conn, TX: 1B, RX: 48M)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 906.0M global + 2.6M per thread (100 max threads)
[OK] Maximum possible memory usage: 1.1G (40% of installed RAM)
[OK] Slow queries: 0% (306/259K)
[OK] Highest usage of available connections: 32% (32/100)
[OK] Key buffer size / total MyISAM indexes: 128.0M/88.4M
[OK] Key buffer hit rate: 99.9% (125M cached / 69K reads)
[OK] Query cache efficiency: 58.5% (140K cached / 240K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (71 temp sorts / 71K sorts)
[!!] Temporary tables created on disk: 48% (63K on disk / 129K total)
[OK] Thread cache hit rate: 97% (157 created / 5K connections)
[OK] Table cache hit rate: 95% (137 open / 143 opened)
[OK] Open file limit used: 8% (180/2K)
[OK] Table locks acquired immediately: 99% (221K immediate / 222K locks)

после 24х часов ничего не меняется. Везде Ок параметры подбирал очень долго.

Что имеем на выходе? Посещаемость 3к уников в сутки.

Загрузка ЦПУ меньше 90% не падает, а почти всегда 100% Памяти благо хватает, бывают попрыгайчики до 3гб со свопом но это когда feedmaster срабатывает и какой нить гуглобот рыщет.

Можно ли что-то с этим сделать? Да знаю оптимально сменить движок на менее ресурсосберегающий, но еще варианты? Может mysql подкрутить? По top только mysql загружает проц на 60-80% остальное Apache. Может плагины сменить на какие либо альтернативные? Уж больно лагадром большой на таком компе...Уже месяц бьюсь с оптимизацией вереща гугль (((

ХельП!
 
кэширование не пробовал настроить нормально?
я вижу что плагин есть -- но что бы при кэшировании так mysql гонял проц - странно
В том то и дело, что кэш есть и на mysql и на wp. Причём спустя сутки mysql загоняет в кэш памяти треть базы. И все равно когда идет запрос к базе где нет кэша всё подпрыгивает. Я даже Апач ограничил на запросы, только потому, что если будет больше то с каждым запросом к базе все хуже и хуже и в конце тачка просто умирает т.е. отжираются все ресурсы памяти. Пробовал связку Apache+nginx вроде легче как то примерно на 10% но это не тот прирост да и фидмастер тупить начинает двоя записи и т.д. Вернул обратно ограничив апач.
 
установи nginx как прокси, и конфиги my.cnf и httpd.conf в студию, мабуть что-нибудь подскажу.

Cor2 на 3к уников более чем достаточно, это в среднем 3-5 юзера в минуту, а это мало для такой нагрузки.
 
установи nginx как прокси, и конфиги my.cnf и httpd.conf в студию, мабуть что-нибудь подскажу.
Cor2 на 3к уников более чем достаточно, это в среднем 3-5 юзера в минуту, а это мало для такой нагрузки.
Ок щас тогда переделаю в фронд и скину конфиги. А по поводу 3-5 юзеров, ониж не просто 1 страничку открыли, по крайне мере спайлог показывает 15к хитов по сайту.
 
Если контент не слишком часто обновляется, можно часть контента в статику перегнать. При изменении или добавлении комментов, обновлять. Я у себя на блогах релизовывал при помощи плагина

Фронтенд конечно nginx, он смотрит, есть ли статический файл, если есть, отдает его, нет дак, стучится на апач. Но были какието глюки с сапой, поэтому переделал все на файлы плагина WP Super Cache. Если у пользователя нет авторизационной куки, то отдается кешированный контент без участия апача. Очень высокий прирост на часто повторяющихся запросах. Выложил бы ща сюда свой конфиг nginx, но смогу позже, если захотите.
 
установи nginx как прокси, и конфиги my.cnf и httpd.conf в студию, мабуть что-нибудь подскажу.
Cor2 на 3к уников более чем достаточно, это в среднем 3-5 юзера в минуту, а это мало для такой нагрузки.
Значит вот proxy.conf
Код:
File: proxy.conf        Line 1 Col 0       494 bytes                        100%
proxy_redirect              off;
proxy_set_header            Host $host;
proxy_set_header            X-Real-IP $remote_addr;
proxy_set_header            X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size        10m;
client_body_buffer_size     128k;
proxy_connect_timeout       90;
proxy_send_timeout          90;
proxy_read_timeout          90;
proxy_buffer_size           4k;
proxy_buffers               4 32k;
proxy_busy_buffers_size     64k;
proxy_temp_file_write_size  64k;
это nginx.conf
Код:
File: nginx.conf        Line 1 Col 0       686 bytes                                                                                                                                                       100%
user www-data;
worker_processes  2;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    gzip_comp_level 3;
    gzip_proxied any;
    gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}
А это конф сайта.
Код:
upstream backend {
  server srvip:8080;
}
server {
        listen   80;
        server_name  www.site.ru site.ru;
        access_log  /var/log/nginx/site.access.log;
        error_log /var/log/nginx/nginx_error.log;
        location / {
        proxy_pass  http://backend;
        include     /etc/nginx/proxy.conf;
        }
        location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js)$ {
        root /var/www/;
    }
}

Добавлено через 2 минуты
Если контент не слишком часто обновляется, можно часть контента в статику перегнать. При изменении или добавлении комментов, обновлять. Я у себя на блогах релизовывал при помощи плагина ***. Фронтенд конечно nginx, он смотрит, есть ли статический файл, если есть, отдает его, нет дак, стучится на апач. Но были какието глюки с сапой, поэтому переделал все на файлы плагина WP Super Cache. Если у пользователя нет авторизационной куки, то отдается кешированный контент без участия апача. Очень высокий прирост на часто повторяющихся запросах. Выложил бы ща сюда свой конфиг nginx, но смогу позже, если захотите.
Контент обновляется ежечасно, где то постов 50 в сутки. Так же были глюки с сапой и фидмастером, а т.к. прирост не особо был большой в связке Apache+nginx выключил его.
 
У вас nginx вообще не использует возможности кеша, чисто наверно помогает с медленными клиентами, те по быстрому забирает ответ у апача и медленно отдает. Я бы на вашем месте включил кеш в nginx, ведь вы скажем в WP Super Cache тоже с какимто диапазоном времени кешируете, также и в nginx сделйте. Если это автоблог, то вообще должно быть пофиг, тк по урлу новой страницы отдасться все равно новый материял, а подумаешь на главной, скажем через полчаса только ссылка обновиться. Зато за эти полчаса не будет ни одного обращения к главной странице в апаче, все будет браться из кеша. Я у себя ставлю кеш в час, если нагрузка очень сильная, то время можно и увеличить.
 
У вас nginx вообще не использует возможности кеша, чисто наверно помогает с медленными клиентами, те по быстрому забирает ответ у апача и медленно отдает. Я бы на вашем месте включил кеш в nginx, ведь вы скажем в WP Super Cache тоже с какимто диапазоном времени кешируете, также и в nginx сделйте. Если это автоблог, то вообще должно быть пофиг, тк по урлу новой страницы отдасться все равно новый материял, а подумаешь на главной, скажем через полчаса только ссылка обновиться. Зато за эти полчаса не будет ни одного обращения к главной странице в апаче, все будет браться из кеша. Я у себя ставлю кеш в час, если нагрузка очень сильная, то время можно и увеличить.
А можно пример конфига? Посмотреть как оно реализовано. И как подружить фидмастер с nginx в таком случае? Вроде все выполняет апач, но при этом фидмастер отказывается постить хотя должен.
 
А можно пример конфига? Посмотреть как оно реализовано. И как подружить фидмастер с nginx в таком случае? Вроде все выполняет апач, но при этом фидмастер отказывается постить хотя должен.
Ну по поводу работы nginx и кеширующих плагинов решается
вставками в "location / {" конфигурации сайта nginx
Код:
#supercache
set $supercache_file '';
set $supercache_uri $request_uri;
		
set $supercache_file /var/www/html/$http_host/www/wp-content/cache/supercache/$http_host/$uri/index.html;
		 
if ($is_args)
{
set $supercache_file '';
}
# only rewrite to the supercache file if it actually exists
if (-f $supercache_file) {
rewrite ^(.*)$ /wp-content/cache/supercache/$http_host$uri/index.html last;
}
		 
set $supercache_file /var/www/html/$http_host/www/static_cache$uri/index.html;
if ($is_args)
{
 set $supercache_file '';
}
# only rewrite to the supercache file if it actually exists
if (-f $supercache_file) {
rewrite ^(.*)$ /static_cache$uri/index.html last;
}

И добавления двух локейшен
Код:
#location $supercache
	location /wp-content/cache/supercache
	
	{
 		gzip_static on;
 		root   /var/www/html/$host/www/;
 		proxy_cache_key $proxy_host-$scheme-$host-$uri-$request_uri-$is_args-$args;
		
		proxy_cache_valid  200 304 1h;
		proxy_cache_valid  301 1h;
		proxy_cache_valid  any 1h;     
		proxy_ignore_headers "Cache-Control" "Expires";
		proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504;
		open_file_cache max=1024 inactive=600s;
		open_file_cache_valid 2000s;
		open_file_cache_min_uses 1;
		open_file_cache_errors on;
		
	}
	location /static_cache
	
	{
 		gzip_static on;
 		root   /var/www/html/$host/www/;
 		proxy_cache_key $proxy_host-$scheme-$host-$uri-$request_uri-$is_args-$args;
		
		proxy_cache_valid  200 304 1h;
		proxy_cache_valid  301 1h;
		proxy_cache_valid  any 1h;     
		proxy_ignore_headers "Cache-Control" "Expires";
		proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504;
		open_file_cache max=1024 inactive=600s;
		open_file_cache_valid 2000s;
		open_file_cache_min_uses 1;
		open_file_cache_errors on;
 
	}

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