ogseo.com

От: ogseo.com

:D то не остана кой да се добавя, всички са там, просто да ги класираме по минуси
 
От: ogseo.com

Хостгатора нещо се дънят напоследък, няколко последователни неадекватни отговора от съпорта, бавничко взе да работи :) виж делтата не съм ги пробвал
 
Нямаше ли такава тема преди семица? Казаха, че го ъпдейтват нещо, сигурно още не са свършили :)
 
От: ogseo.com

Я споделете повече отзиви за делтата ?
 
значи ситуацията е следната натовари единия хостинг резнаха го премситхме базата на друг хостинг разнаха ремоут аксеса до базата бяха включени вскякави кеширания но от един момент като почна да товари и неиска да смъква сега мислим някаква друга опция но май 2500 са много за всякакъв впс
 
От: ogseo.com

1. W3 Total Cache? Кеширането на базата с APC при мен свърши чудеса. След като от load average 4++ паднах на 0.8-0.9, определено се забелязва разлика.
2. Малко човъркане из my.cnf? Има доста променливи които биха повлияли за по-добра и гладка работа.
Ей това е моят конф на машинка с 2048 рам, на която позволявам mysql да смуче около 600мб рам:
Код:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

log-slow-queries = /var/log/mysql-slow.log
long_query_time = 1
bulk_insert_buffer_size = 16M
join_buffer=2M
key_buffer=256M
max_allowed_packet=64M
max_connections=500
max_heap_table_size = 64M
myisam_sort_buffer_size=128M
query_cache_limit = 16M
query_cache_size = 256M
query_cache_type = 1
query_prealloc_size = 1M
query_alloc_block_size = 2M
read_buffer_size=2M
read_rnd_buffer_size=2M
record_buffer=2M
safe-show-database
skip-innodb
skip-locking
skip-networking
sort_buffer=4M
table_cache=8129
thread_cache_size=2084
thread_concurrency=8
tmp_table_size = 64M
max_join_size = 4294967295
[mysqldump]
max_allowed_packet = 64M

[myisamchk]
key_buffer = 128M
sort_buffer = 128M
read_buffer = 64M
write_buffer = 64M

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
 
От: ogseo.com

memcached е може би най-добрия вариант за кеширане, само че трябва ръчно да си го вграждаш в кода, според точно ситуацията. Демек за къстъм писани системи.
За случая с WP има някакви готови плъгини, ама май не са по-добри...
 
От: ogseo.com

W3 Total Cache работи както с memcached, така с APC, както и с eAccelerator. От всичките оп-код оптимизатори, най-съм доволен от APC, за това и препоръчах именно него.
Когато търсих оптимизатор, четох ето тази статия тук. Първоначално ползвах eAccelerator, но както е написано в дъното на статията, доста често ми се случваше да получавам segmentation faults и за това реших да премина на APC.
Ей тук има още малко информация за двете цък.
Впрочем основната разлика между APC и Memcached е, че първото се зарежда като модул в php, а второто си върви като отделен даемон.
 
Memcached и APC са две коренно различни неща. Да, APC може да изпълнява и функция, подобна на memcached - да кешира данни, но основната му цел е съвсем друга - PHP accelerator.

APC is a free, open, and robust framework for caching and optimizing PHP intermediate code.

При тежки скриптове, с много php файлове за парсване се постигат изумителни резултати само с инсталирането на APC. Както ктомов отбеляза, load & cpu usage падат няколко пъти.

Мемкеш служи единствено за кеширане на данни - например резултати от тежки или често повтарящи се заявки към базата, генерирани html страници и т.н. Изключително бърз е и не консумира почти нищо от процесора.
 
От: ogseo.com

Коренно различни са спрямо принципа им на работа, но се използват за едно и също нещо - улекотяване на работата извършвана от php и mysql, като кешират информацията.
APC, кешира извършваните операци като от php скриптовете като заявки към базата данни и върнатите резултати, като по този начин при повторно извикване на същата страница/скрипт, нуждата от извършване на същите тези заявки не същестува по простата причина, че вече са запазени като генерирани файлове и се показва само резултата от тях.
Относно Memcached - по-ясно от vaskoa, не мога да го кажа.
Като подкрепа на твърдението ми, че APC е практически задължително ако разполагаш с VPS или Dedicated сървър, ще дам малко статистика:
Код:
File Cache Information
Cached Files	445 ( 46.6 MBytes)
Hits	765476
Misses	4448
Request Rate (hits, misses)	299.81 cache requests/second
Hit Rate	298.08 cache requests/second
Miss Rate	1.73 cache requests/second
Insert Rate	0.17 cache requests/second

Код:
User Cache Information
Cached Variables	9098 ( 97.3 MBytes)
Hits	224235
Misses	34632
Request Rate (hits, misses)	116.92 cache requests/second
Hit Rate	101.28 cache requests/second
Miss Rate	15.64 cache requests/second
Insert Rate	20.58 cache requests/second
Cache full count	0

И това е от 15:30. Чистя кеша на 3 часа, защото ми се получава голяма фрагментация - не разполагам с много рам :)
 
От: ogseo.com

И разликата след само 20 минути:
Код:
File Cache Information
Cached Files	665 ( 71.7 MBytes)
Hits	1077559
Misses	4668
Request Rate (hits, misses)	293.68 cache requests/second
Hit Rate	292.42 cache requests/second
Miss Rate	1.27 cache requests/second
Insert Rate	0.18 cache requests/second
Cache full count	0
Код:
User Cache Information
Cached Variables	5060 ( 66.9 MBytes)
Hits	322925
Misses	50005
Request Rate (hits, misses)	111.96 cache requests/second
Hit Rate	96.95 cache requests/second
Miss Rate	15.01 cache requests/second
Insert Rate	18.77 cache requests/second
Cache full count	1
 
Re: От: ogseo.com

APC, кешира извършваните операци като от php скриптовете като заявки към базата данни и върнатите резултати, като по този начин при повторно извикване на същата страница/скрипт, нуждата от извършване на същите тези заявки не същестува по простата причина, че вече са запазени като генерирани файлове и се показва само резултата от тях.

Това е вярно единствено ако някой ръчно имплементира кеширането на въпросните променливи и операции в скрипта, който ползва (или сложи нужните плугини и т.н). Например:

PHP:
$heavyResult = $database->query('select * from 30 000 000 rows table order by rand() limit 100')->fetchAll();
се променя на

PHP:
if( ! $heavyResult = $cachingEngine->get('blabla') ){
  $heavyResult = $database->query('select * from 30 000 000 rows table order by rand() limit 100')->fetchAll();
  $cachingEngine->add('blabla', $heavyResult);
}
при първото отваряне на скрипта данните ще се вземат от базата, при всяко следващо - от кеша. А какво ще се използва за кеширащ енджин вече е въпрос на личен избор - apc, memcached, sqlite, може дори и текстов файл.

Тоест оптимизацията, за която говорим може да се раздели на две неща:

- инсталиране на APC (или друг accelerator) - това може да свали товара и до 20 пъти чрез премахване на нуждата сървъра да компилира мегабайти php код за всеки рикуест.
- имплементиране на кеширане на данните - ръчно или с плугини. Тук вече може да се избере между apc или мемкеш.
 

Горе