Изглежда, че имам пренебрегвани, за да напишете нова статия в доста време! Срам ме. Но, благодарение на един уебсайт прекъсване, Аз бях най-накрая имам малко повече добри неща, които да споделят с вас.
Моята предишна конфигурация Nginx се превръща в кошмар за поддържане и WordPress стана бавно, тъй като децата са били Apache е убит от OOM. Това се дължи на погрешно кеш PHP (PHP XCache да бъдат точни) , че са решили да вземат всички налични малко памет от моята система, въпреки че Макс-искания за дете определен ниска (преди да бъде почистена).
Това, заедно с моите усилия в търсенето на най-бързо решение за всичко и въвеждането на нови Облак сървъри от OVH, доведе мен днешната статия.
Кое е по-бързо – Лак или Nginx?
Първото нещо, което исках да направя, е да се случи всичко кеширане преди нещата да изблъска към Apache. Това, защото исках да се премахнат и двете PHP XCache и WordPress Супер Кеш плъгин бях с, така че да се увеличи WordPress съвместимост, но сложността спад.
Отначало помислих, за използването на Лак – или като единствено предния край, или между Nginx и Apache (мотивите по-късно). Също, Имах намерила моите ръце на Облак сървъри OVH на докато те все още са в “алфа”, и използва това като база за изграждане на система за база данни за уеб сървъри.
Следните изпитвания, бяха извършени по тези Облак сървъри – Mc 256 (256 MBytes на гарантираните RAM, 2 Gbyte обща памет с излишък разменя за SSD на), 4 CPU ядра и 5 GBytes на място за съхранение. Операционната система е Ubuntu 10.04 LTS. Продукцията на / Ргос / cpuinfo е както следва (X4 за краткост):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU E5504 @ 2.00GHz
stepping : 5
cpu MHz : 1995.000
cache size : 4096 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm
bogomips : 3990.00
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Материалната инсталиране на Apache извършва в продължение на един прост “Здравей свят” PHP скрипт, използване “AB-C 100 -N 100000 HTTP:/ / Хост /“:
Concurrency Level: 100
Time taken for tests: 29.548 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 25009500 bytes
HTML transferred: 3901482 bytes
Requests per second: 3384.27 [#/sec] (mean)
Time per request: 29.548 [ms] (mean)
Time per request: 0.295 [ms] (mean, across all concurrent requests)
Transfer rate: 826.55 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 12 39.1 12 1960
Processing: 9 18 49.6 14 2036
Waiting: 1 15 45.9 12 1966
Total: 14 29 65.9 26 2159
С лак пред Apache, нещата наистина започват да изглеждат добре:
Concurrency Level: 100
Time taken for tests: 13.489 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 28315282 bytes
HTML transferred: 1100594 bytes
Requests per second: 7413.64 [#/sec] (mean)
Time per request: 13.489 [ms] (mean)
Time per request: 0.135 [ms] (mean, across all concurrent requests)
Transfer rate: 2049.99 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 6 2.2 6 71
Processing: 2 7 1.9 7 70
Waiting: 1 6 2.0 5 66
Total: 3 13 3.1 13 81
В 2.48x повече от това, Apache може да изпрати по своя собствена, Това е силно впечатляващо подобрение и лакове заслужава слава. Но в 1 GBytes оперативна памет за кеширане, би тя наистина да бъде по-ефективна и по-бързо от Nginx? Следните резултати кажа …
Concurrency Level: 100
Time taken for tests: 9.438 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 27706648 bytes
HTML transferred: 5201248 bytes
Requests per second: 10595.55 [#/sec] (mean)
Time per request: 9.438 [ms] (mean)
Time per request: 0.094 [ms] (mean, across all concurrent requests)
Transfer rate: 2866.87 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 4 1.0 4 56
Processing: 2 6 9.7 5 253
Waiting: 0 5 9.7 5 253
Total: 5 9 9.7 9 257
… една различна история. Въпреки че това не е някакъв научни изследвания, които трябва да се вземат по номинална стойност, Аз лично намерени разликата доста значителни – особено след като никога не Nginx използва повече от 60 Mbytes на RAM и разчита най-вече на файлова система за кеширане. 1.39x по-бързо от лакове, 3.46x по-бързо от Apache само по себе си. Това е още по-впечатляващи!
Малко Лак хрумване на Ubuntu
отново, и не мога да кажа това достатъчно често, Това са само числа, получени на моята система – си пробег може да варира. Лак определено е достоен претендент — на един въпрос АЗ излизам насреща на Ubuntu е, че Лак разбил при опит за тест с повече от 1000 едновременни връзки. Това не е трябвало да се случи в производствена среда!
Виновникът се очертава като потребител на профила “отворен дескриптори файл” ограничаване. Sockets също отчитат тази стойност и когато лакът удари граница е починал, а ungracefully. Можете ръчно да се разреши с помощта на ulimit:
ulimit -n 65535
Но вие сте по-добре, като се използва / И т.н. / за сигурност / limits.conf картотекирам. Тя е добре документирана, така че не трябва да бъде трудно да го разбера. Ще продължи с моя блог…
Конфигурацията
Така че решихме да водят Nginx като предния край на Apache, но този път – за разлика от по-рано – активирате кеширането на Nginx. Правейки това тук, по-скоро, отколкото да работи с кеширане плъгини и множество други банди / СПИН, поддържа цялата конфигурация чисто и просто. Скоро може да бъде оставен сам да тече, тъй като обикновено се, без специални измама. Единственото изключение е Memcache магазин, , тъй като базата данни се намира на друг сървър и са свързани чрез VPN.
Първо инсталиран Nginx, Apache, PHP5 и Memcache по обичайните канали, , както следва:
apt-get install nginx libapache2-mod-php5 memcached \
php5-mysql php5-curl php5-gd php5-idn php-pear php5-imagick \
php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming \
php5-ps php5-pspell php5-recode php5-snmp php5-sqlite \
php5-tidy php5-xmlrpc php5-xsl php5-json
Update Nginx
Версията Nginx, предоставени от хранилището Ubuntu е 0.7.65. Както и да е, функция, въведени във версия 0.7.66/stable -proxy_no_cache – ще дойде удобен опростяване на конфигурация. 0.7.67 Твърди също така малък въпрос, която се отнася главно до Windows машини, но е добре да има кръпка, независимо. Така че съм съставен Nginx до последната стабилна версия, както следва:
# apt-get install libc6 libpcre3 libpcre3-dev libpcrecpp0 libssl0.9.8 libssl-dev zlib1g zlib1g-dev lsb-base
wget http://www.nginx.org/download/nginx-0.7.67.tar.gz
tar -xf nginx-0.7.67.tar.gz
cd nginx-0.7.67
./configure \
--user=www-data \
--group=www-data \
--sbin-path=/usr/sbin \
--conf-path=/etc/nginx/nginx.conf \
--error-log-path=/var/log/nginx/error.log \
--pid-path=/var/run/nginx.pid \
--lock-path=/var/lock/nginx.lock \
--http-log-path=/var/log/nginx/access.log \
--http-client-body-temp-path=/var/lib/nginx/body \
--http-proxy-temp-path=/var/lib/nginx/proxy \
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi \
--with-debug \
--with-http_stub_status_module \
--with-http_flv_module \
--with-http_ssl_module \
--with-http_dav_module \
--with-http_gzip_static_module \
--with-http_realip_module \
--with-mail \
--with-mail_ssl_module \
--with-ipv6
make && make install
Да, това е буквално нарязани & паста. Той презаписва на двоични файлове инсталирани от ап-получите, и ние щастливо да продължат да използват официалния скрипт първоначално предоставени от Ubuntu / Debian. Защо направи живота труден?
Конфигуриране на PHP и Apache
В този момент, конфигуриране на PHP и Apache към съдържание сърцето си. Единственото нещо, което трябва да направите с Apache е да го преместите на друго пристанище и за предпочитане да го съхранявате на 127.0.0.1. Това означава, че трябва да редактирате / файл etc/apache2/ports.conf:
NameVirtualHost *:8080
Listen 127.0.0.1:8080
И конфигуриране на вашия сайт(С) съответно:
<VirtualHost *:8080>
... etc ...
</VirtualHost>
Ако използвате SSL (HTTPS://), Това ще се обработва от Nginx, а не Apache. Тъй като това вече е получаване на доста дълго, Ще пропуснете SSL в този блог.
Конфигуриране Nginx
Започваме със създаването на няколко директории, които ще бъдат използвани от Nginx:
mkdir /etc/nginx/includes
mkdir -p /var/cache/nginx/tmp
mkdir /var/cache/nginx/cached
chown -R www-data:www-data /var/cache/nginx
След това променяте файла / И т.н. / nginx / nginx.conf , както следва:
user www-data;
worker_processes 4;
worker_rlimit_nofile 16384;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 2000;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 75 20;
gzip on;
gzip_vary on;
gzip_comp_level 3;
gzip_min_length 4096;
gzip_proxied any;
gzip_types text/plain 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/*;
}
на worker_processes променлива се определя в зависимост от броя на ядрата на процесора в моята система, 4 В този случай. Има няколко ощипвам TCP и Gzip компресия е разрешена за допълнителни типове файлове, , а не само HTML. За останалата част, Това е доста посредствен.
Основната кон на Nginx ще бъде пълномощник и свързаните с кеш. Защото аз обичам да поддържам нещата добре sectioned, по този начин лесно за конфигуриране, Аз създадох следния / И т.н. / nginx / conf.d / proxy.conf картотекирам, които ще бъдат включени от Nginx от включват изявление:
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
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;
proxy_max_temp_file_size 56m;
proxy_temp_path /var/cache/nginx/tmp;
proxy_cache_key $scheme$host$request_uri;
proxy_cache_path /var/cache/nginx/cached levels=2:2 keys_zone=global:64m inactive=60m max_size=1G;
proxy_cache_valid 200 302 30m;
proxy_cache_valid 301 1h;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
proxy_pass_header Set-Cookie;
на proxy_set_header променливи са там, за да ви помогне да определите периода на разследването на действителния заявителя уеб страница, вместо да получава една от Nginx. Ти просто трябва да се включат% (X-Предаден-За) I Влезте в един от форматите Apache, вместо на приемащата (% З).
Както и да е, Аз лично инвалиди всякакъв достъп влезете в Apache, защото всичко трябва да мине през Nginx така или иначе и повишава ефективността Apache е smidgen (Ти направи това, коментира извършват всички CustomLog редове в конфигурацията на Apache). Направих напуснат ApacheErrorLog поддръжка, само за тези случаи, както и за PHP съобщения за грешка.
Досието по-горе също така определя една зона Nginx прокси кеш нарича “в световен мащаб” с proxy_cache_path променлива. Същата променлива определя също боклука време (60 минути) и максималния размер на кеша (на диска, 1 Gbytes).
на proxy_cache_key е просто един наниз от “httpmyatus.co.uk / therequests.php” , които ще бъдат хеширан и след това се използва за да го изтеглите по-късен етап. Аз съм остаряла кеш позволява да бъде връчен в случай на някои грешки, Например, когато неочаквано умира Apache е.
Важен малко, което е доста досадно да разбера, е proxy_pass_header Частта за “Set-Cookie” заглавна. WordPress включва “Set-Cookie” заглавия в 302 HTTP отговори (който се използва за точка на браузъра на ново място) – някои се мръщят на тази практика и Nginx не е изключение. Ето защо ние трябва да специално да позволя това минава през, или друго, което няма да можете да влезете в своя WordPress Admin или потребителите оставят коментари.
Включва
в / И т.н. / nginx / включва папка ние създадохме по-рано, добави два файла. Първата е помощник за сайтове, които използват WordPress. Тъй като / И т.н. / nginx / включва папка не е автоматично да бъдат включени, можем да бъдем селективни за включвания, и освен по някои Време, когато тези функции не се използват. Това е/ И т.н. / nginx / включва / wordpress.inc картотекирам:
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_") {
set $no_cache 1;
}
if ($http_user_agent ~* "(2\.0 MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine\/3\.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA\/WX310K|LG\/U990|MIDP-2\.|MMEF20|MOT-V|NetFront|Newt|Nintendo Wii|Nitro|Nokia|Opera Mini|Palm|PlayStation Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian OS|SymbianOS|TS21i-10|UP\.Browser|UP\.Link|webOS|Windows CE|WinWAP|YahooSeeker\/M1A1-R2D2|NF-Browser|iPhone|iPod|Android|BlackBerry9530|G-TU915 Obigo|LGE VX|webOS|Nokia5800)" ) {
set $no_cache 1;
}
proxy_no_cache $no_cache;
Това е един много прост файл, действително. Първата част проверки, ако има някои определени бисквитки, свързани с коментар авторите или тези, които са влезли в WordPress Admin. Ако това е така, променливата $ No_cache е настроено на 1. Втората проверка е за мобилните потребители, като Nokia, iPhone, и т.н.. Това е полезно, в случай, че имат мобилен издание WordPress, като на разположение през някои плъгини.
Ако във всяка точка на $ No_cache е 1, променливата proxy_no_cache става истина. Скоро продукцията на все още може да бъде кеширана, но тя няма да бъде връчен на крайния потребител (Така винаги пресни).
Забележка: Тъй като продукцията от Apache все още може да бъде кеширана в този случай (но не се обслужват), то е напълно възможно, ако страницата не е поискано преди, може да се използва за запълване на кеша (и по този начин служи на по-късен етап).
например, Да речем, че някой посещения / Някои / страница с мобилен браузър. Това може да бъде първото посещение на тази страница и ще бъде кеширана. Някой, който използва редовно браузър (казвам, Firefox или Opera) , ще бъде представен с този мобилен кеширана версия, причинява някои несъответствия.
Можете да го решим чрез добавяне $ HTTP_USER_AGENT до proxy_cache_key отчет в proxy.conf файл, описани по-рано. Недостатъкът тук е повишен съхранение кеш изискване, като всяка версия на браузъра получава своя кеширана версия. Що се отнася до влезлите в WordPress администратор / потребител, никога не ще той да се представи кеширана версия – така че това важи само ако сте с помощта на мобилната версия на WordPress.
Вторият файл е помощник, който е почти универсален за всички сайтове (но все още могат да се контролират в съответствие с актуалната сайтове-достъпни / * файлове). Това е/ И т.н. / nginx / включва / default_proxy.inc картотекирам:
# Enable caching:
proxy_cache global;
# Default:
location / {
proxy_pass http://127.0.0.1:8080;
}
# Rarely changed items can remain cached longer:
location ~* \.(jpg|jpeg|png|gif|ico|css|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
proxy_cache_valid 200 3h;
proxy_pass http://127.0.0.1:8080;
}
# Deny access to .ht* files:
location ~ /\.ht {
deny all;
}
Първата променливаproxy_cache информира Nginx да се използва “в световен мащаб” зона ние определено по-рано през/ И т.н. / nginx / conf.d / proxy.conf картотекирам. Ако не е там, нищо няма да бъдат кеширани страници и просто преминават през.
По-нататък се казва Nginx да изпратите всичко, за да Apache, но ще позволи на изображения и няколко други статични файлове да бъдат кеширани по-дълго от първоначално определената. Последната част разказва Nginx да блокира достъпа до файлове, като например . Htaccess или . Htpasswd право на равнището на Nginx на – Скоро така не трябва да и спестите малко процесорна мощ.
А по подразбиране сайт
Можете да използвате включва файлове за изграждането на много малки уебсайт конфигурационния файл. За пример, / И т.н. / nginx / сайтове-достъпни /подразбиране може да изглежда нещо подобно на това:
server {
listen 80;
server_name _;
root /var/www/sites/default/public;
index index.html index.htm;
access_log /var/www/sites/default/logs/access.log;
error_log /var/www/sites/default/logs/nginx.error.log;
# Includes:
include /etc/nginx/includes/wordpress.inc;
include /etc/nginx/includes/default_proxy.inc;
}
Всичко се предава на Apache и кеширана, в зависимост от wordpress.inc файл, той позволява. Скоро ще се справят с останалата част. Вие най-вероятно ще трябва да промените директорията, но това е основно го.
WordPress
Има малко, че трябва да се направи с WordPress. Най-важното нещо е да се изключат всички действително кеш WordPress може да се използва, като Супер Кеш WordPress. Вече не е необходимо и само дава Apache / PHP повече работа за вършене. Както и да е, Както беше отбелязано по-рано, Аз не включват Memcache.
Причината е, че в моя случай, всеки сървър Облак работи на разстояние от една и съща база данни MySQL клъстер. За да се избегнат излишни или повтарящи се движения SQL, демона Memcache ще проведе тези в RAM памет (или в случай на облака – RAM или SSD). Това става с използването на обектно-cache.php файла, като Райън Boren, която може да бъде получена от този сайт. Този файл трябва да бъде поставен в $ WP-ROOT $ / WP-съдържание / директория.
За всичко останало, WordPress може да се обикновени, но са станали мехури бързо, както е показано в следващата продукция.
Изпълнение
Имам клъстерирани един облак сървър с един специален сървър. За кратко време (както и в, полуден) Използвах HAProxy като мястото на влизане. HAProxy е супер-бърз, но аз бях подразни от малкото въпрос, който причинил сеч въпроси. Nginx е по-наравно с HAProxy, въпреки че може да има малко повече трептене, така че сега използва 2x Nginx <–> съчетание (Nginx + Apache) combination. Уит на (Nginx + Apache) част от тази настройка конфигурирани точно както е описано по-горе, Имам възможност да получат следните скорости (въз основа на 100 едновременни връзки, 50,000 искания и за интервала поддръжка):
Concurrency Level: 100
Time taken for tests: 6.694 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 2822197200 bytes
HTML transferred: 2806393092 bytes
Requests per second: 7469.02 [#/sec] (mean)
Time per request: 13.389 [ms] (mean)
Time per request: 0.134 [ms] (mean, across all concurrent requests)
Transfer rate: 411700.31 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 0.4 2 16
Processing: 3 11 0.8 11 27
Waiting: 1 3 1.2 3 25
Total: 6 13 0.8 13 32
В 3.29 Gbps @ 7469 искания за секунда, Считам, че това е доста добре функциониращи настройка. Добре подготвени за следващия си проект!
Подобни публикации:
