ГлавнаяОптимизацияОптимизация vps

Как оптимизировать VPS чтобы не тормозили сайты? Оптимизация vps


Настройка дешевых VPS на максимальную производительность

С таким запросом к нам обратился Михаил.  У него на виртуальном сервере десяток сайтов, суммарным трафиком около 2к хостов в сутки.  И VPS с минимальным  тарифом у хостера с 1 гб  оперативной памяти, одним ядром CPU и 20 Gb SSD.  Сайты на WordPress.   На сервере кроме этого также стоит панель управления хостингом ISP Manager Lite 5.

vpsadm.ru помогает!

Клиент изначально обратился за настройкой сжатия, которое требуется при оптимизации сайта под Google Pagespeed Insights.   Он пытался включить сжатие самостоятельно в настройках сайтов через панель ISPM, но Гугл упорно не хотел «видеть»  что сжатие включено.

Кроме того, среди жалоб  оказались и другие проблемы:  VPS периодически зависал, в часы пик сайты открывались очень медленно, в логах были ошибки.

Что такое Google Pagespeed Insights?

Google Pagespeed Insights это хороший инструмент, который позволяет вебмастерам оценить производительность своего сайта. Гугл показывает состояние основных  настроек вебсервера, таких как сжатие файлов для уменьшения трафика и ускорения сайта, кэширование на стороне клиента — в браузере (а еще есть серверное кэширование Nginx), оптимизацию изображений, javascript, css.  Таким образом, через этот инструмент можно очень быстро сделать аудит сайта по которому специалисту сразу же становится понятно, где и что нужно изменить, для того, чтобы сайт стал работать лучше, по мнению Google.  К счастью, его мнение совпадает с мнением большинства пользователей.

Как включить сжатие и кэширование на сайте?

Как оказалось в итоге, сжатие было включено не до конца, поскольку панель управления от ISP просто  не позволяет настолько гибко настраивать вебсервер. При подключении к консоли сервера через SSH  и исследовании конфигурации Nginx, быстро выяснилось, что сжатие на самом деле-то и не включено, поскольку отстутствует важная для этого директива gzip_types.

Для того чтобы включить сжатие, достаточно добавить в файл конфигурации виртуалхоста следующие строки.gzip on;gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;Это можно сделать также и для всего вебсервера, чтобы не копировать один и тот же код во множество файлов для разных сайтов. Вообще, хороший тон — это создавать один файл конфигурации для любого количества сайтов.Опционально можно указать степень сжатия. У клиента можно это было делать красивым бегунком в панели управления, и стоял уровень пять.

gzip_comp_level 5;

Вообще, nginx   поддерживает  9 уровней сжатия, как и gzip, через который оно делается.  5-6й уровень считается оптимальным по соотношению сжатие/производительность. Поскольку при дальнейшем увеличении уровня сжатие будет улучшено очень мало, в то время как это существенно увеличит нагрузку на процессор.  Поэтому рекомендуется вообще не указывать уровень сжатия, либо указать его не более 5-6.

Теперь поговорим о клиентском кэшировании.

Что такое кэширование с точки зрения Google Pagespeed?

Это указание для браузера, через который будет открыт сайт, какие файлы и на какой срок он может сохранить на диске в кэше браузера. Это делается для того, чтобы при последующих посещениях данного сайта не перекачивать не изменившиеся файлы сайта — скрипты (js), таблицы стилей (css), изображения шаблона и элементов управления. Таким образом, после первого открытия большая часть интерфейса не будет скачиваться и страницы сайта будут открываться значительно быстрее, порой в несколько раз.

Именно это Гугл требует включить на вебсервере. Для разных разных вебсерверов это делаетс по-разному для Nginx рецепт прост.

Нужно использовать expires.

Например так:location ~* \.(js|css|png|jpg|jpeg|gif|ico|woff)$ {expires max;log_not_found off;}Этот вариант сообщает браузеру клиента кэшировать описанные типы файлов насовсем — max. Вместо max можно указать количество часов — 2h, дней (3d)  или месяцев (1m). Кроме того, в этой конфигурации даётся указание на записывать в лог вебсервера сообщения с 404 ошибкой для этих файлов. Например, если будет запрошен файл картинки или скрипта, которых уже нет на сервере.  В некоторых случаях, это также помогает снизить нагрузку на сервер. Особенно когда на сайте произошли существенные изменения и поисковые боты в попытках проиндексировать ищут старые файлы на сервере.   Отключив логгирование этих событий мы снижаем нагрузку.  Кстати, есть даже особый способ атак, который основан на этом — запрашивать у вебсервера множество страниц, которых заведомо не существует на сайте.

Как включить сжатие и кэширование для вебсервера Apache?

В некоторых случаях используется именно этот вебсервер. Хотя nginx сейчас что называется «в тренде», старичок Apache 2 еще используется многими хостерами и вебмастерами.   Как минимум в качестве бэкенда. Здесь  придётся сделать отвлечение на анатомию сервера.

Что ещё за бэкенд?

Дело в том, что серверное программное обеспечение и сами информационные системы, в том числе и сайты, обычно разделяют на backend и frontend.  Бэкенд — это  «задняя» часть — от английского back —  которая скрыта от пользователя и представляет собой основу сайта — база данных и исполняемые файлы CMS — чаще всего на php. Так вот, backend отвечает как раз за работу этих частей сайта. В то время как фронтенд — это перед, лишь то, что видит посетитель сайта или сервиса — его интерфейс. Это непосредственно то, что отображается в браузере — html-код страницы, стили, javascript  изображения, контент.  В упомянутом мной контексте nginx — это обработчик фронтенда, он прекрасно умеет отдавать статические элементы. Но для исполнения php-кода  сайта необходим обработчик, а nginx этого не умеет.  Так вот, apache — умеет отдавать и фронтенд и бэкенд — такой себе универсал.  Но делает это весьма посредственно.  Я об этом рассказал, поскольку дальше в кейсе это будет иметь значение.

Итак, для того чтобы сконфигурировать вебсервер apache под Google Pagespeed Insights  нужно также  включить сжатие и кэширование

Это можно сделать как для всего вебсервера, так и для каждого сайта в отдельности.

Также это можно делать в разных местах. Простейший путь — добавить в файл .htaccess такой код:

# сжатие text, html, javascript, css, xml: <ifModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript </ifModule> # Включаем кэш в браузерах посетителей <ifModule mod_headers.c> # Все html и htm файлы будут храниться в кэше браузера один день <FilesMatch "\.(html|htm)$"> Header set Cache-Control "max-age=43200" </FilesMatch> # Все css, javascript и текстовые файлы будут храниться в кэше браузера одну неделю <FilesMatch "\.(js|css|txt)$"> Header set Cache-Control "max-age=604800" </FilesMatch> # Все флэш файлы и изображения будут храниться в кэше браузера один месяц <FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$"> Header set Cache-Control "max-age=2592000" </FilesMatch> # Отключаем кеширование php и других служебных файлов <FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$"> Header unset Cache-Control </FilesMatch> </IfModule>

Эффект от этих настроек можно увидеть в нашей инфографике:

Оптимизация сайта на Apache включением сжатия и кэширования

 

Итак, сжатие и кэширование включено, сайты заработали пошустрее, оценка google pagespeed insights местами «позеленела».  Но проблемы были не только в этом, поэтому будем разбираться дальше.

Исследуем системные логи

Там сразу же замечаем проблему — apache валится с ошибкой о нехватке памяти — out of memory.

Ошибка при зависаниях Apache

Feb 18 21:40:50 server kernel: Out of memory: Kill process 17304 (httpd.itk) score 37 or sacrifice childFeb 18 21:40:50 server kernel: Killed process 17304, UID 500, (httpd.itk) total-vm:413800kB, anon-rss:23732kB, file-rss:884kBFeb 18 21:40:52 server kernel: nginx invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0Feb 18 21:40:52 server kernel: nginx cpuset=/ mems_allowed=0Feb 18 21:40:52 server kernel: Pid: 1402, comm: nginx Not tainted 2.6.32-504.3.3.el6.x86_64 #1Feb 18 21:40:52 server kernel: Call Trace:Feb 18 21:40:52 server kernel: [<ffffffff810d40c1>] ? cpuset_print_task_mems_allowed+0x91/0xb0Feb 18 21:40:52 server kernel: [<ffffffff81127300>] ? dump_header+0x90/0x1b0Feb 18 21:40:52 server kernel: [<ffffffff8122eabc>] ? security_real_capable_noaudit+0x3c/0x70Feb 18 21:40:52 server kernel: [<ffffffff81127782>] ? oom_kill_process+0x82/0x2a0Feb 18 21:40:52 server kernel: [<ffffffff811276c1>] ? select_bad_process+0xe1/0x120Feb 18 21:40:52 server kernel: [<ffffffff81127bc0>] ? out_of_memory+0x220/0x3c0Feb 18 21:40:52 server kernel: [<ffffffff811344df>] ? __alloc_pages_nodemask+0x89f/0x8d0Feb 18 21:40:52 server kernel: [<ffffffff8116c69a>] ? alloc_pages_current+0xaa/0x110Feb 18 21:40:52 server kernel: [<ffffffff811246f7>] ? __page_cache_alloc+0x87/0x90Feb 18 21:40:52 server kernel: [<ffffffff811240de>] ? find_get_page+0x1e/0xa0Feb 18 21:40:52 server kernel: [<ffffffff81125697>] ? filemap_fault+0x1a7/0x500Feb 18 21:40:52 server kernel: [<ffffffff8114eae4>] ? __do_fault+0x54/0x530Feb 18 21:40:52 server kernel: [<ffffffff8114f0b7>] ? handle_pte_fault+0xf7/0xb00Feb 18 21:40:52 server kernel: [<ffffffff8144a610>] ? sock_aio_write+0x0/0x1c0Feb 18 21:40:52 server kernel: [<ffffffff8118dc1b>] ? do_sync_readv_writev+0xfb/0x140Feb 18 21:40:52 server kernel: [<ffffffff8114fcea>] ? handle_mm_fault+0x22a/0x300Feb 18 21:40:52 server kernel: [<ffffffff8104d0d8>] ? __do_page_fault+0x138/0x480Feb 18 21:40:52 server kernel: [<ffffffff8152ff7e>] ? do_page_fault+0x3e/0xa0Feb 18 21:40:52 server kernel: [<ffffffff8152d335>] ? page_fault+0x25/0x30Feb 18 21:40:52 server kernel: Mem-Info:Feb 18 21:40:52 server kernel: Node 0 DMA per-cpu:Feb 18 21:40:52 server kernel: CPU 0: hi: 0, btch: 1 usd: 0Feb 18 21:40:52 server kernel: Node 0 DMA32 per-cpu:Feb 18 21:40:52 server kernel: CPU 0: hi: 186, btch: 31 usd: 30Feb 18 21:40:52 server kernel: active_anon:101903 inactive_anon:101945 isolated_anon:32Feb 18 21:40:52 server kernel: active_file:219 inactive_file:338 isolated_file:204Feb 18 21:40:52 server kernel: unevictable:8 dirty:0 writeback:20 unstable:0Feb 18 21:40:52 server kernel: free:12243 slab_reclaimable:2314 slab_unreclaimable:10948Feb 18 21:40:52 server kernel: mapped:334 shmem:9 pagetables:20381 bounce:0Feb 18 21:40:52 server kernel: Node 0 DMA free:4644kB min:668kB low:832kB high:1000kB active_anon:5084kB inactive_anon:5320kB active_file:0kB inactive_file:48kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15368kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:16kB slab_unreclaimable:212kB kernel_stack:0kB pagetables:376kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:101 all_unreclaimable? noFeb 18 21:40:52 server kernel: lowmem_reserve[]: 0 994 994 994Feb 18 21:40:52 server kernel: Node 0 DMA32 free:44328kB min:44384kB low:55480kB high:66576kB active_anon:402528kB inactive_anon:402460kB active_file:876kB inactive_file:1304kB unevictable:32kB isolated(anon):128kB isolated(file):816kB present:1018072kB mlocked:32kB dirty:0kB writeback:80kB mapped:1332kB shmem:36kB slab_reclaimable:9240kB slab_unreclaimable:43580kB kernel_stack:2208kB pagetables:81148kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1536 all_unreclaimable? noFeb 18 21:40:52 server kernel: lowmem_reserve[]: 0 0 0 0Feb 18 21:40:52 server kernel: Node 0 DMA: 15*4kB 5*8kB 30*16kB 7*32kB 8*64kB 6*128kB 2*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 4644kBFeb 18 21:40:52 server kernel: Node 0 DMA32: 552*4kB 3961*8kB 314*16kB 31*32kB 9*64kB 2*128kB 2*256kB 2*512kB 2*1024kB 0*2048kB 0*4096kB = 44328kBFeb 18 21:40:52 server kernel: 18537 total pagecache pagesFeb 18 21:40:52 server kernel: 17815 pages in swap cacheFeb 18 21:40:52 server kernel: Swap cache stats: add 20488036, delete 20470221, find 33545864/35447252Feb 18 21:40:52 server kernel: Free swap = 0kBFeb 18 21:40:52 server kernel: Total swap = 502780kBFeb 18 21:40:52 server kernel: 262141 pages RAMFeb 18 21:40:52 server kernel: 7054 pages reservedFeb 18 21:40:52 server kernel: 53978 pages sharedFeb 18 21:40:52 server kernel: 237397 pages non-shared

Но вся память на сервере не используется,  а ему всё равно не хватает.  Именно это приводит к зависаниям сервера в часы пик.

Клиент также жалуется, что показывается ошибка 502 — Bad Gateway.  Такое случается, когда Apache не успевает обрабатывать поступающие запросы.    Пробуем включить на сервере ещё один тип кэширования — APC.  Это особый модуль PHP, который выполняет «прекомпиляцию» кода  и сохраняет результат его выполнения в оперативной памяти.  Затем, повторные запросы к одним и тем же страницам не приводят к исполнению того же самого кода, если в нем не было изменений, а позволяют вебсерверу отдать уже готовый результат из кэша.

Итог — страницы стали открываться  шустрее, но иногда всё равно показывается 502 ошибка.  В частности в консоли администратора WordPress.   Оно и понятно, эта часть сайта наиболее сильно может нагружать вебсервер, поскольку при обращении к ней серверу приходится выполнять десятки, а то и сотни php-скриптов. Благо, что пользователи туда не ходят.

Но проблема имеется, остаётся моё любимое средство — убрать apache и заменить его на обработчик php-fpm.

Замена apache на php-fpm (fastcgi)

Это быстрый сервер, который умеет выполнять  только php-код, но не умеет отдавать статические файлы и html-код. Но нам это и не нужно — у нас есть отличный обработчик фронтенда в виде вебсервера Nginx. Более того, я считаю моветоном, ставить Nginx перед apache.  Ну это всё равно что засунуть в шасси и кузов болида  формулы-1 старый двигатель от «Жигули».    Машина может ехать быстро — но двигатель чихает  и не тянет.    Однако, хостеры и многие системные администраторы используют именно такую схему.  Почему? Потому что так проще, ведь php-fpm несколько сложнее в настройке.

В чем же преимущества Apache?

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

А недостатки?  Apache не тянет нагрузку. Там где появляется нагрузка — она будет расти в геометрической прогрессии. Даже на очень мощных серверах сайты могут «тормозить».  По моей оценке — apache может выдерживать нагрузку лишь в сотни посещений. Если перед ним поставить nginx  для отдачи статики — тысячи.  Но там где нагрузка в десятки тысяч посещений — apache начинает захлёбываться.  Это могут подтвердить и многочисленные бенчмарки.

То же самое мы видим и здесь.

Результат оптимизации сервера

Далее наступает важная часть работы — наблюдение и отладка того, что мы накрутили.   Возможно, я вас сейчас удивлю, но работа системного администратора заключается в совершении ошибок.  Совершаем, наблюдаем, исправляем. Пробуем, пробуем, пробуем. Так и сяк, итерация за итерацией.  Порой десятки вариантов, десятки программ, сотни настроек и их значений.  Разумеется, каждая последующая итерация отладки будет показывать лучший результат.

На что способен nginx+php-fpm?

Я помню готовил систему документооборота к нагрузочному тестированию.    Система как раз таки работала на apache, в результате было выявлено, что требования, предъявляемые заказчиком способна выдержать только эта связка — nginx+php-fpm. Причём, нам бы даже не помогли мощные сервера с десятками гигагерц и ядер CPU и сотнями Gb оперативной памяти.  Потребовалось спроектировать  архитектуру  системы из  20 серверов, чтобы выдерживать 20 тысяч одновременных подключений.  Apache не выдерживал даже 2 тысячи, и делал это в разы медленней fpm.   Php-fpm справлялся, но потребовалось масштабировать его на десять хостов. И перед ними стоял один-единственый балансировщик с nginx,  который легко принимал на себя всю нагрузку и при этом даже не напрягал оборудование.  А вот серверы для обработки php были нагружены на 50%.

Тогда тестирование проводили не кто-нибудь, а независимые эксперты из компании Hewlett Packard. Они специализируются на инструментах для нагрузочного тестирования — у них есть такой продукт Load Runner.  Вот им и тестировали.  Это был конкурс на выбор системы электронного документооборота, участвовали 5 систем.  Уж и не помню какие там были результаты у других систем, но мы требования заказчика выдержали.

Тем более что наш менеджер схитрил — нам было дано задание оптимизировать и тестировать  до тех пор, пока система не будет выдерживать 20 тысяч одновременных пользователей.  А оказалось, что у заказчика предъявлялось требование  в 10 тысяч. Стоит ли говорить,  что в итоге построенная нами распределенная система показала,  что нагружена она всего лишь на 30% под тестами HP. Имея такой запас прочности эта система легко победила в конкурсе и была выбрана заказчиком. 

Всё это хорошо, а что же получил клиент в рассматриваемом здесь кейсе?

Клиент получил «зелёные» оценки почти по всем десяти сайтам. Исключением стали только три сайта, на которых Гугл «забраковал» неоптимизированные изображения.

Как было до настройки VPS

Примерно вот так выглядели результаты тестов Pagespeed Insights когда мы получили VPS в работу:

Оценка Google и скорость загрузки до оптимизации

А вот так выглядел график нагрузки VPS в панели ISP manager:

 

Нагрузка на VPS от вебсервера Apache

Как видно по графику, нагрузка на CPU зашкаливает 70% процентов практически постоянно.  А это, как минимум, тревожный звонок.   Ну и, собственно, проблемы, в виде тормозящих сайтов и вылетающих ошибок, клиенту приходилось перезагружать сервер.  К слову, весь сервер-то и не нужно, достаточно рестартануть апач (httpd в службах centos).

Вот так мы его перенастраивали:

Смена apache на fpm, график нагрузки

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

Вот такую картину мы видим  в течение двух дней после:

Работа оптимизированного VPS

Снижение нагрузки в два-три раза  очевидно, друзья.  А то и более.  Сервер утилизируется теперь процентов на 30, и выдержит  даже если на сайтах будет многократный рост трафика.  Хотите я вам скажу сколько он выдержит? А ведь это самый дешевый тариф у хостера, рублей за 200.    Впс,  настроенный таким образом,  выдержит до 20 тысяч (20k, карл!) суточного трафика.  Это при использовании wordpress с плагином wp-supercache, а все мы знаем насколько прожорлив WP.

Как растет нагрузка на сервер?

Как растет нагрузка на сервер?

Откуда инфа?  И   как он выдержит 20000, если  он показывает 30% загруженности при 2000 посещений.  Вот такая хитрая математика, друзья.  Дело в том, что нагрузка на оборудование и софт сервера не растёт линейно.  Она растёт по своеобразной  отрицательной экспоненте, что ли. Мы пока ещё исследуем этот вопрос, но есть очень много затей на эту тему, так что заглядывайте почаще, может мы и найдем такую формулу.

Так вот, значит,  рост нагрузки замедляется  при её увеличении.  Это связано с особенностями построения программ, сайтов, и даже железа.  До некоторого момента,  такой системе без разницы — обработать 1 запрос,  10 запросов или 1000  — нагрузка будет почти одинаковой, сервер и сайты на нем практически не замечают роста.    Затем, наступает какой-то  перегиб,  и рост нагрузки становится действительно линейным. Вот тут-то и нужна максимальная оптимизация. А когда информационная система отлажена — дальнейший рост нагрузки для неё замедляется, потому как происходит своеобразное наложение и совмещение функций —  один и тот же исполняемый код используется многократно,  работают всевозможные кэши, система, что называется «разогрета».

Ну дак, заявление  о 20к трафика на 1гб RAM  VPS   чем-то обосновано?  Да друзья, я таким же образом оптимизировал VPS c 512 Мб ОЗУ  и 1 CPU. На нём работал 1 сайт на wordpress, который выдерживал около 5000 визитов и 15000 хитов в сутки.  Да он и по сей день работает, хотя проект  и переживает не лучшие времена и  трафика там  на данный момент существенно меньше. Так вот, при 5к трафа при глубине просмотра 3 страницы на посетителя,  VPS показывал всего лишь 50% загруженность.

Да вот статистика того сайта:

 

Быстро ли работают сайты после оптимизации?

Действительно, мы как-то отвлеклись, расписывая все эти подробности. Проблема клиента была в тормозящих сайтах и 502 ошибке,  что ему за дело до всех этих интересных выкладок и графиков.

Сайты стали открываться вот так:

Оценка Google Pagespeed того же сайта после оптимизации VPS

Это тот же самый сайт, который был показан ранее в статье.

А вот это уже другой сайт. Удивительно, но Гугл порой считает, что даже 0,27 секунды — это долгое время ответа сервера.  Этот сайт тоже на WordPress.

Оценка pagespeed после оптимизации сервера

Итого, скорость отклика улучшилась с 2-секунд, до 0,2 секунды, в некоторых случаях.    Меж тем, некоторые коллеги упорно не желают верить в то, что это работает, и даже возник спор в  топике на серче.   Собственно, тот спор и послужил почвой для этого кейса.  Но не думаете же вы, что я нарисовал всё это в фотошопе, друзья? :)

Куда обращаться в случае чего?

В спортлото пишите!

Шучу.

Можно заявку оставить на сайте vpsadm.ru,  можно писать по контактам,  указанным там же. Консультироваться можно  в комментариях, а можно постучаться опять же в скайп.  Можно и на любом форуме, где у нас есть топик, куда можно попасть из блока отзывов на сайте vpsadm.   Например, на mfc.guru люди так и получают бесплатные консультации.

 

Кстати, подписывайтесь на обновления, следующая статья будет об увеличении дискового пространства на VPS засчёт подключения внешних файловых систем, облачных или с других VPS.

answit.com

Как ускорить работу VPS-сервера для форекс

Здравствуйте, дамы, господа, соратники и просто товарищи форекс-трейдеры! Как известно, если вы применяете в своей торговле советники, то есть те же роботы, то без VPS-сервера вам никак не обойтись. Базовая инструкция уже есть на нашем сайте, поэтому сегодня мы поговорим о том, как можно немного оптимизировать работу с VPS-сервером. Какие программы для этого нужны, какие «хаки» можно применить, чтобы сервер работал чуточку быстрее, а управлять им было чуточку удобнее.

Оптимизация системы

Первая программа, которая нам потребуется – Auslogics BoostSpeed Premium (скачать можно на любом торрент-трекере). Программа очищает диск от ненужных файлов, дефрагментирует реестр, удаляет лишний мусор.

Устанавливается программа, как и любая другая для Windows, ничего сложного. В 9 версии сразу после запуска исполняемого файла начинается установка программы в каталог по-умолчанию – дополнительно ничего подтверждать не нужно. Принципиальной же разницы между новыми и старыми версиями нет, суть одна и та же. Это во-первых, очищение компьютера от мусора и, во-вторых, небольшая оптимизация в реальном времени.

При запуске программы осуществляется автоматическая проверка. Программа выдает оценку состояния системы (все плохо) и определяет, сколько и чего можно удалить. Чтобы исправить обнаруженные проблемы, нажимайте «Исправить все» (Repair all).

Программа ударяет сразу по трем фронтам: размер диска, стабильность работы и скорость ПК. Если вы захотите перезапустить проверку компьютера, это можно сделать с вкладки «Диагностика» (Diagnostics). Благо, делать это нужно не так часто – программа сама проводит анализ и напоминает о необходимости проверки примерно раз в неделю.

После сворачивания программы в трей, она будет продолжать работать над оптимизацией оперативной памяти, в чем можно убедиться, зайдя на вкладку «Ускорение» (Live Speedup). Справа от графика загрузки памяти можно включать/отключать дополнительные настройки ускорения, такие как: оптимизация памяти, оптимизация работы процессора, автоматическая дефрагментация и оптимизация сервисов.

Помимо основных функций программы, много полезных утилит содержит вкладка «Инструменты» (All Tools). Здесь расположен список вспомогательных инструментов для оптимизации работы системы.

Нормальный браузер

Что еще следует установить, так это нормальный браузер. Самый легкий вариант – Google Chrome. Это особенно удобно, если вы пользуетесь Хромом на домашнем компьютере, тогда войдя под той же учетной записью, все ваши закладки, пароли и история вкладок будут синхронизироваться на обоих устройствах. Если вы предпочитаете какой-либо другой браузер – смело ставьте его. Подойдет та же Opera или Mozilla Firefox.

Архиватор WinRar

Также совсем нелишним будет скачать архиватор WinRAR. Особенно, если вы постоянно скачиваете какие-либо файлы стратегий, советников, которые нужно предварительно распаковывать. Если не устанавливать винрар, придется распаковывать архив сначала на домашнем компьютере, затем запаковывать в zip, чтобы перенести на VPS-сервер, что совсем не удобно. Лучше облегчить себе жизнь и поставить архиватор непосредственно на VPS. Свежую версию также без труда можно найти в сети.

Облачное хранилище

Также, хорошим решением будет установить клиент облачного хранилища на собственном компьютере и на VPS. Скорее всего, вы уже используете какое-либо решение для хранения файлов в облаке, как вариант, Яндекс Диск – в России самое популярное решение. Небольшой объем, как и у других, предоставляется бесплатно. Это также может быть Dropbox, Google Drive, OneDrive от Microsoft и другие – принципиальной разницы нет.

Единственное, при установке на VPS вам нужно будет выбрать для синхронизации не всю систему, а одну отдельную папку, например, «Файлы для VPS». Это нужно для того, чтобы, скажем, ваши сотни фотографий не загружались на VPS, а загружались только файлы, необходимые для торговли (советники, шаблоны, индикаторы). То есть, вы закидываете файлы в папку у себя на компьютере, и они появляются на VPS – все просто и даже быстрее, чем копировать файлы напрямую.

Вывод

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

Иногда возникает вопрос, а нужно ли устанавливать антивирус? Как по мне – абсолютно не нужно, и антивирус будет только съедать системные ресурсы. Вряд ли VPS вам нужен для того, чтобы серфить по сомнительным сайтам с контентом для взрослых. Для остальных задач достаточно встроенного в систему фаервола.

С уважением, Власов ПавелTradeLikeaPro.ru

tradelikeapro.ru

Оптимизация VPS для Forex

В этом видеоуроке я покажу, как настроить VPS-сервер Forex, как изменить пароль на сервере и, что сделать, чтобы не потерять свои данные! Так же увидите, как установить терминал MetaTrader 4 и перенести советник со своего компьютера на VPS-сервер Forex!

Оптимизация VPS для Forex - фото.

Зачем нужен VPS-сервер для Forex?

Если не вдаваться в лишние подробности и сказать просто, то VPS-сервер — это компьютер, который подключен к Интернету, но находится не у вас дома! Причем у вас скорость Интернета может быть сравнительно небольшой и нестабильной, а на VPS-сервере делается все возможное, чтобы он работал, как можно быстрее и стабильнее!

Хотя, конечно, нужно понимать, что это все-таки техника и проблемы бывают даже там! Что же поделать, ничто в этом мире несовершенно

Как бы там ни было, для тех, кто работает на Форексе, VPS-сервер незаменимый инструмент! Особенно, если работать на советниках!

Дело в том, что советник должен быть постоянно подключен к Интернету! А это создает определенные неудобства… Если у вас Интернет медленный и нестабильный, то без VPS-сервера для Forex можете даже и не думать что-то зарабатывать на Форексе!

Вам не даст это делать Интернет! Точнее его скорость и непредсказуемость!

Представьте себе ситуацию, когда ваш советник работающий по принципу Мартингейла, не сможет в нужный момент открыть ордер? А ведь это деньги! Реальные! И можно не то что не заработать, можно потерять все до копейки!

Кроме того, нужно чтобы компьютер постоянно находился во включенном состоянии. А это, зачастую, причиняет еще большие неудобства! К тому же жалко ведь технику

У одного из моих партнеров так и было… Из-за проблем с компьютером ушел весь депозит!

Кто знает, тот поймет о чем я говорю

Это был, так сказать, краткий экскурс, предисловие, чтобы вы понимали, что этот видеоурок о VPS-сервере сделан не просто так, а потому что это действительно очень полезный инструмент для успешного трейдера!

В видеоуроке я буду показывать на примере сервера, который у меня есть, то есть VPS-сервер, который предоставляет ДЦ Forex4you.

Это не означает, что и вы обязаны будете там же заказывать себе сервер… Где бы вы не арендовали VPS-сервер, принцип работы и то, что я покажу в видеоуроке идентичны! Хотя Forex4you считается одним из лучших дилерских центров в РФ!

Хотя я все покажу в видеоуроке, но так же объясню и письменно, так как знаю, что многим, у кого медленный Интернет, нелегко смотреть видео. Видеоурок так же будет доступен для скачивания на ваш компьютер и просмотра прямо здесь на блоге! Если у вас хороший Интернет, то можете не читать, а прокрутить прямо к видеоуроку…

Оптимизация VPS для биржы Форекс

  1. Подключение сервера VPS

Итак, через некоторое время после заказа VPS-сервера, вы получите на E-Mail, который указали при регистрации, письмо, где будут данные для работы с сервером. То есть IP адрес, логин и пароль. Хотя в видеоуроке я покажу, как сменить пароль, сохраните эти данные!

Для хранения паролей я всегда рекомендую то, чем пользуюсь сам — Password Commander — бесплатный менеджер паролей. Он удобен тем, что его всегда можно носить с собой на флешке! И к тому же с помощью Password Commander’а можно генерировать очень сложные для взлома пароли!

После того, как вы сохранили полученные по почте данные, заходите в меню Пуск, открывайте «Все программы» и находите папку «Стандартные»! В ней будет то, что нам нужно — «Подключение к удаленному рабочему столу».

То есть, раз VPS-сервер, компьютер, то нам и нужно открыть его рабочий стол, как и на нашем с вами компьютере.

Чтобы вам каждый раз, при подключении, не проходить заново этот сложный путь, кликните на «Подключение к удаленному рабочему столу» правой кнопкой мыши, откроется новое окошко, в котором наведите курсор на «отправить» и в выпадающем меню, выберите «Отправить на рабочий стол(создать ярлык).Потом ярлык найдете на раочем столе и можете определить его на панель быстрого доступа.

После того, как это сделали, кликайте на строчке «Подключение к удаленному рабочему столу» и в открывшемся окне, внизу, увидите маленькую стрелку и рядом надпись «Параметры».  Там, где написано «Пользователь» введите логин из письма, а там, где «Компьютер»  — IP адрес.

Далее переключитесь на вкладку «Локальные ресурсы» и проверьте, чтобы в окошке «Буфер обмена» стояла галочка! Это нам очень пригодиться в будущем, когда будем переносить нужные нам файлы на VPS-сервер!

После всего этого, жмите на кнопку «Подключить», в следующем окошке вводите ваш пароль и последний шаг — нажать на «ок»!

Поверьте мне, все эти действия занимают намного меньше времени, чем вы затрачиваете на чтение того, что я тут написал

Итак, если вы все сделали правильно, то уже, буквально через пару секунд, окажитесь на вашем VPS-сервере!

2. Изменяем пароль на VPS-сервере

Перед вами будет окно, где вам нужно будет изменить только ваш часовой пояс и закрыть его! А вот следующее окно «Диспетчер сервера», уже интересует нас гораздо больше! В первую очередь, здесь нужно изменить пароль доступа к VPS-серверу!

Кто-то рекомендует менять не только пароль к VPS-серверу, но и логин! То есть по умолчанию, ваш логин — «Администратор». И есть версия, что хакерам, зная вам логин, будет легко подобрать пароль для взлома вашего VPS-сервера!

Конечно, менять или не менять, дело ваше, но если вы сгенерируете пароль в Password Commander’е, то все хакеры мира будут отдыхать!  Попытка взломать такой пароль им самим дороже обойдется, чем то, что они захотят похитить у вас!

Так же есть мнение, что на VPS-сервер нужно ставить антивирусник и настроить файервол! Если вы любитель мазохизма, то уверен, вам это понравится! Как это сделать, вы найдете в Интернете! Я же ценю свое и ваше время, поэтому не буду грузить подобной ерундой

Скажу лишь, что если вы будете использовать ваш VPS-сервер для Форекс, то кроме установки терминалов и «прикручивания» советников, вам на сервере больше ничего делать не нужно! То есть не надо использовать его, как почтовый ящик или, как еще один способ выходить в Интернет!

Все установили, настроили, закрыли и забыли! Всю работу с терминалами можно осуществлять не заходя на VPS-сервер! То есть, ВСЕ делается с вашего компьютера! После установки терминалов и запуска советников, единственный случай, зачем вам нужно зайти на VPS-сервер — отключить советник! Или потом его включить! Больше там делать нечего!

Если вы будете следовать этому простому правилу, то вам не грозит головная боль, ни с антивирусником, ни с файерволом! Видите, как все просто?

Но, вернемся к тому, как изменить пароль на сервере!

Тут тоже все донельзя примитивно  Смотрите в левый верхний угол «Диспетчера сервера», видите там строчку «Локальные пользователи»? Нажимайте плюсик слева и левой кнопкой мыши на папке «Пользователи»! Теперь у вас по центру открылись две записи — «Администратор» и «Гость».

«Администратор» — это вы! И вам нужно изменить пароль именно администратора. Кликаете на надписи правой кнопкой мыши и выбираете «задать пароль…» В открывшемся окошке с предупреждением жмете кнопку «продолжить» и в следующем окошке два раза вставляете ваш заранее сгенерированный или придуманный пароль! Все! Теперь после нажатия на «ок», пароль будет изменен и при следующем входе на VPS-сервер, вам уже нужно будет вводить новый!

ВНИМАНИЕ! Обязательно сохраните или запишите новый пароль! Если вы его утеряете, то помните, что его не смогут взломать даже хакеры!  И вам уже никто не поможет!

Итак, теперь вы знаете, как изменить пароль на VPS-сервере!

3. Устанавливаем торговый терминал MetaTrader 4 и советник на VPS-сервер

Закрывайте «Диспетчер сервера» и на рабочем столе увидите ярлык от уже установленного терминала Forex4you MetaTrader 4, дистрибутив mt4setup и другие ярлыки, которые вам не понадобятся… Это я говорю о VPS-сервере от Forex4you! Если вы заказывали в другом месте, то у вас и будет по-другому…

Но все это решается нехитрым способом! Посмотрите на панель быстрого доступа и увидите там папку. Это «Проводник». Кликните на ней и в открывшемся окне слева увидите папку «Загрузки». Открывайте ее и сворачивайте окно VPS-сервера! Подчеркну — не закрывайте, а сворачивайте! Для этого вверху экрана, на синем фоне, нажмите на значке нижнего подчеркивания! То есть сделайте то же самое, что вы делаете с вашими открытыми окнами

Найдите на вашем компьютере советник, который нужен вам для работы и просто скопируйте его! Далее открывайте опять окно VPS-сервера и просто вставляйте советник в папку «Загрузки»! Если у вас  на сервере не стоит терминал MetaTrader 4, то тоже самое проделайте и с ним!

Вот и все! Дальше стандартная процедура установки терминалов и нанесения на них советников! Все это я уже показывал здесь… Ничем не отличается от того. что вы делаете у себя на компьютере!

Когда я впервые знакомился с VPS-сервером, то мне рассказали такую сложную процедуру закачки файлов на сервер, что мне стало не по себе! Пришлось напрячь мозги и поисковик, чтобы найти способ проще. Действительно оказалось все очень просто! Помните проверяли галочку в окошке «Буфер обмена»? Так вот она нужна именно для того. чтобы просто копировать файлы с вашего компьютера на сервер!

Вот, в принципе и все! Долго писал, вы долго читали, но делать все это намного быстрее! Я специально не стал делать скрины, описал все, как можно подробнее. Если, что-то непонятно, то посмотрите видеоурок или спросите в комментарии к этой статье.

Источник: sergmedvedev.ru.

Видео

Видео урок об оптимизации VPS для Forex:

forexlf.ru

Чеклист по оптимизации VPS на PHP/Mysql/Nginx / Хабр

Как обеспечить более высокую производительность VPS сервера, который работает на Nginx + PHP + Mysql? В этой статье приведен чеклист основных настроек, которые позволят существенно оптимизировать работу сервера. Настройка займет не более 10 минут и не требует ничего, кроме редактирования конфигурационных файлов. Примеры настроек приведены для операционной системы Debian 7 и VPS сервера с 1 процессором и 512Мб оперативной памяти.
Nginx
Настройки выполняются в файле /etc/nginx/nginx.conf, а также в настройках виртуального хоста (обычно в папке /etc/nginx/sites-enabled)Количество воркеров Количество воркеров nginx'a должно совпадать с количеством ядер:worker_processes 1; Cache-Control заголовки Установка заголовков Cache-Control позволит существенно разгрузить Ваш сервер от повторных обращений к файлам которые не изменяются (или изменяются редко, например css/js/jpg/png/gif):location ~* \.(css|js|png|gif|jpg)$ { expires max; } Access log Лишние дисковые операции из-за записи логов нам не нужны, отключаем:access_log off; Unix socket'ы Включаем unix-сокеты для работы с PHP:location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm.sock; # также необходимо настроить php-fpm, см. ниже fastcgi_index index.php; include fastcgi_params; }
PHP
Настройки выполняются в файле конфигурации fpm php-fpm.conf, который в нашем случае находится тут /etc/php5/fpm/pool.d/www.conf.Unix socket'ы Убеждаемся, что php-fpm работает с unix-сокетами, а не с tcp:listen = /var/run/php5-fpm.sockAPC Устанавливаем расширение APC — внутренний кеш PHP, который позволит существенно сэкономить ресурсы парсеру PHP:apt-get install php-apc
Настройка MySQL
Все настройки MySQL выполняются в файле my.cnf, который обычно находится тут /etc/my.cnf.key_buffer Если Вы используете только MyISAM таблицы, устанавливайте это значение в 30%...40% всей доступной оперативной памяти на сервере:key_buffer = 128Minnodb_buffer_pool_size Если Вы используете только InnoDB таблицы, устанавливайте это значение максимально возможным (80% доступной памяти). В нашем случае устанавливаем:innodb_buffer_pool_size = 350M

Внимание, устанавливать такое знание можно только значительно уменьшив '''key_buffer'''. Т.е. между этими двумя настройками нужно сделать выбор, который зависит от типа используемых таблиц (MyISAM либо InnoDB).

innodb_flush_log_at_trx_commit Значительного ускорение записи для таблиц innoDB можно добиться установкой этого параметра в 0, когда буфер записи будет сбрасываться на диск не после каждой операции, а раз в секунду:innodb_flush_log_at_trx_commit = 0innodb_flush_method Установка этой опции в O_DIRECT позволяет избежать двойного кеширования (она выключает операционный кеш для файлов данных MySQL):innodb_flush_method = O_DIRECTthread_cache_size Эта опция определяет размер кеша для созданных тредов. Подбирается экспериментально, но лучше стартовое знание увеличить до 16:thread_cache_size = 16query_cache_size Включаем внутренний кеш MySQL:query_cache_size = 16М

Значение стоит увеличивать по мере необходимости. Не стоит забывать, что кеш перестает работать эффективно на таблицах, которые часто обновляются.

Резюме
В качестве резюме — краткий список с выделенными наиболее важными настройками:
Источники
Приведенные статьи содержат более подробное описание данных настроек, а также дополнительные методы оптимизации серверной части.

habr.com

Оптимизация VPS за счет MySQL

За счет MySQL как оказалось можно снизить потребляемое количество ОЗУ практически на 100Мб (+-) заранее хотелось бы сказать, что у MySQL есть файлы предустановленых конфигураций:

Данные конфигурации расположены здесь:

/usr/share/doc/mysql-server-x.x.x

Для VPS оптимальным будет являться my-medium.cnf, в данном случае нам нужна секция [mysqld]:

[mysqld]socket = /var/lib/mysql/mysql.sockskip-lockingkey_buffer_size = 16Mmax_allowed_packet = 1Mtable_open_cache = 64sort_buffer_size = 512Knet_buffer_length = 8Kread_buffer_size = 256Kread_rnd_buffer_size = 512K

данная концигурация более подходит для серверов с 256Мб ОЗУ, подправим их с учетом для сервера с 512Мб ОЗУ можно добавить \ изменить пару настроек:

key_buffer_size = 64Mtable_open_cache = 512record_buffer = 1Mmax_connections = 100sort_buffer_size = 32Mquery_cache_limit = 2Mquery_cache_size = 64Mquery_cache_type = 1thread_cache_size = 4

елси у VPS меньшее кол-во памяти (к примеру 384) то можно уменьшить значения key_buffer_size до 32M, table_open_cache до 32, query_cache_size до 32M (данными параметрами можно варьировать в зависимости от ситуации), далее если не используется InnoDB то в эту же секцию добавляем:

skip-innodb

Примечание: после обновления на mysql 5.5 эта директива перестала работать

У меня взаимодействие с MySQL происходит через сокет, поэтому можно добавить параметр:

skip-networking

Касательно зависимости ситуаций, здесь для более точной диагностики можно использовать скрипты, результат работы которых, будет сообщать о тех или иных некорректных параметрах, благодаря к примеру скрипту mysqltuner.pl мне удалось добиться практически оптимальных результатов для моего MySQL, хотелось бы отметить, что ключевыми параметрами для потребления памяти являются - key_buffer_size и max_connections, чем больше значения, тем больше памяти будет расходоваться, в конечном итоге, сервер может просто встать, что и было в моем случае на первых порах...

Итак - tuning-primer.sh, загружаем:

wget http://day32.com/MySQL/tuning-primer.sh

меняем разрешения:

chmod u+x tuning-primer.sh

запускаем:

./tuning-primer.sh

mysqltuner.pl, загружаем:

wget http://mysqltuner.com/mysqltuner.pl

меняем разрешения:

chmod +x mysqltuner.pl

запускаем:

./mysqltuner.pl

После всех манипуляций, дефрагментируем таблицы:

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

если выдаст ошибку вида:

mysqlcheck doesn't support multiple contradicting commands

то необходимо попробовать:

mysqlcheck -u root -p --auto-repair --optimize --all-databases

 

sys-adm.in

[Услуги] - Администрирование, поддержка и оптимизация VPS и dedicated

Итак, друзья, пора бы рассказать о новостях.1. Я прекратил свою деятельность в штате компании, где трудился на протяжении последних трёх лет. Отныне я буду заниматься исключительно своими и вашими проектами. Просто потому что мне так больше нравится, надоело сидеть "у дяди" в офисе. Не хватало свободы, было слишком много усталости от ночной и дневной работы. Теперь я не буду распыляться и дела будут делаться ещё эффективней. И даже, зацените такой криатифф, господа:

Кстати, этот мобильный номер доступен по whatsapp, где я готов с удовольствием пообщаться с клиентами, как реальными, так и потенциальными. Это может быть ещё удобней и оперативней, нежели скайп, поскольку скайп я не использую на мобильном.

2. Вышла долгожданная статья об использовании внешних хранилищ, подключении яндекс диска к VPS. Можно ознакомиться по ссылке: http://answit.com/uvelichenie-diska-na-vps-zaschyot-vneshnih-faylovyih-sistem/. Это удобно использовать для хранения изображений, видео, pdf или любого другого объёмного статического контента. Это удобно использовать для бэкапов, чтобы не загромождать основной диск на ВПС бэкапами.

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

3. Завёл топик на сёрче. Возможно кому-то будет удобней общаться со мной там, кто-то больше доверяет тамошним отзывам и репутации. Не буду давать ссылку, меня легко найти там в разделе "работа для вебмастера">"администриров ание серверов".

 

nulled.in

Как ускорить и оптимизировать WordPress на Linux VPS

Все уже описано. К счастью, не обо всем еще подумано (С. Лец).

Не имеет значения, если вы работаете в небольшом блоге или веб – сайте, если высокий трафик на основе WordPress, оптимизация WordPress должна быть одним из главных приоритетов. Скорость загрузки страниц настолько важна сегодня, что даже алгоритм ранжирования Google, был адаптирован к этому. Кроме того, медленный сайт означает меньше посетителей, и это главная причина которой вы должны быть обеспокоены. В этом посте мы сделаем краткий обзор некоторых из ключевых методов оптимизации, которые могли бы помочь вам, чтобы получить увеличить быстродействие вашего WordPress сайта и Linux VPS.

Методы оптимизации WordPress будут ограничены услугами хостинга, который вы используете. Если вы используете общий хостинг, то вы будете иметь небольшой контроль над вашей установкой сервера и вы не сможете выполнять расширенные методы оптимизации. Обратите внимание, что многие провайдеры VPS не дадут вам полный контроль (корневой доступ) к вашему VPS. Именно поэтому мы всегда рекомендуем использовать наш Linux VPS хостинг, который работает на SSD накопителях для быстрого запуска вашего WordPress веб – сайта. Если вы получаете VPS от нас, вы будете иметь полный контроль (корневой доступ) над сервером для выполнения оптимизации на стороне сервера. Мы рекомендуем перейти от общего к VPS как можно скорее. Вы увидите множество улучшений производительности вашего сайта, даже за счет перехода на VPS в одиночку, без какой – либо дальнейшей оптимизации.

LEMP (Linux, Nginx, MySQL / MariaDB и PHP)

Используя солидный стек программного обеспечения, как LEMP, безусловно, поможет вам получить лучшее из вашей установки WordPress. Стек LEMP состоит из Nginx, который используется для запуска самых оживленных сайтов в Интернете. Это позволит значительно повысить производительность вашего WordPress сайта и сервера. Если у вас нет установлен LEMP на вашем WordPress сервере, идти вперед и установите Nginx, MySQL и PHP-FPM с помощью нашего гида. Вы можете найти больше советов по производительности, улучшения WordPress и Nginx здесь. Запуск последней версии программного обеспечения тоже очень важно, поэтому убедитесь , что весь ваш код WordPress, Nginx и другое серверное программное обеспечение в актуальном состоянии . Обновление PHP на PHP 7 будет очень полезным тоже, так как PHP 7 считается в два раза быстрее, чем PHP 5.6. Кроме того, в соответствии с некоторыми критериями, PHP 7 использует 30% меньше памяти и обслуживает более 3х запросов.

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

Кэширование

Кэширование очень важно, если вы хотите ускорить ваш WordPress сайт. Осуществляя несколько хороших методов кэширования вы можете повысить производительность в несколько сотен раз. Мы рассмотрим некоторые из наиболее эффективных методов кэширования.

Кэширование на стороне сервера

Добавление кэширования как OPcache к вашему PHP улучшит значительно работу. Это очень простой метод, как OPcache поставляется с ядром PHP по умолчанию. Просто убедитесь, что ваш PHP версии выше, чем 5.5, хотя мы рекомендуем использовать PHP 7 с WordPress.

Плагины кэширования

Для кэширования ваши посты и страницы в WordPress преобразуются в статические файлы. Установка плагина кэширования в WordPress довольно проста, так же, как и любой плагин кэширования в WordPress. Тем не менее, вам, возможно, придется позаботиться о конфигурации после установки. Почти все плагины кэширования предоставляют документацию пользователя, так что вы можете легко узнать, как настроить плагин для максимальной производительности. Вы можете проверить наш учебник для w3 total cache здесь.

Категория плагинов кэширования для WordPress можно найти на https://wordpress.org/plugins/tags/caching.

Кэширование браузера

Другой метод кэширования, который можно реализовать для вашего WordPress сайта является использование кэширования браузера. Браузер кэширования означает, что веб-браузер клиента будет загружать и хранить активные файлы, такие как CSS, JS и изображений в локальном запоминающем устройстве в течение определенного промежутка времени, что может уменьшить количество запросов для каждой страницы и значительно уменьшит нагрузку на сервер. Чтобы включить кэширование браузера просто добавьте строки ниже в ваш файл .htaccess:

## EXPIRES CACHING ## <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpg "access 1 year" ExpiresByType image/jpeg "access 1 year" ExpiresByType image/gif "access 1 year" ExpiresByType image/png "access 1 year" ExpiresByType text/css "access 1 month" ExpiresByType text/html "access 1 month" ExpiresByType application/pdf "access 1 month" ExpiresByType text/x-javascript "access 1 month" ExpiresByType application/x-shockwave-flash "access 1 month" ExpiresByType image/x-icon "access 1 year" ExpiresDefault "access 1 month" </IfModule> ## EXPIRES CACHING ##

Если вы используете Nginx вместо Apache в качестве веб – сервера, добавьте следующие строки в блоке сервера для вашего доменного имени:

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 365d; }

Другие методы оптимизации WordPress

Многие из методов, которые мы упоминали ранее, не могут быть выполнены, если вы находитесь на виртуальном хостинге, поскольку оптимизация на стороне сервера и требует особого доступа к среде хостинга. Вы можете сделать следующие оптимизации даже на общем хостинге.

Добавить GZIP сжатие

Сжатие Gzip необходимо для того, чтобы уменьшить размер данных, которые отправляются с вашего сервера. Включение сжатия Gzip довольно легко, просто добавьте строки ниже в ваш файл .htaccess:

<IfModule mod_deflate.c> # Compress HTML, CSS, JavaScript, Text, XML and fonts AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/vnd.ms-fontobject AddOutputFilterByType DEFLATE application/x-font AddOutputFilterByType DEFLATE application/x-font-opentype AddOutputFilterByType DEFLATE application/x-font-otf AddOutputFilterByType DEFLATE application/x-font-truetype AddOutputFilterByType DEFLATE application/x-font-ttf AddOutputFilterByType DEFLATE application/x-javascript AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE font/opentype AddOutputFilterByType DEFLATE font/otf AddOutputFilterByType DEFLATE font/ttf AddOutputFilterByType DEFLATE image/svg+xml AddOutputFilterByType DEFLATE image/x-icon AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/javascript AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/xml # Remove browser bugs (only needed for really old browsers) BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html Header append Vary User-Agent </IfModule>

В случае, если вы используете Nginx, добавьте следующие строки в файле конфигурации Nginx:

gzip on; gzip_comp_level 2; gzip_http_version 1.0; gzip_proxied any; gzip_min_length 1100; gzip_buffers 16 8k; gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript; # Disable for IE < 6 because there are some known problems gzip_disable "MSIE [1-6].(?!.*SV1)"; # Add a vary header for downstream proxies to avoid sending cached gzipped files to IE6 gzip_vary on;

Используйте только необходимые плагины

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

Используйте хорошие темы

Если вы используете хорошо кодированную тему для сайта WordPress, у вас больше шансов иметь веб-сайт с быстрой загрузкой. Некоторые разработчики тем, как правило, включают в себя фишки, которые влияют на производительность. Есть так много хорошо кодированных WordPress темы там и платные и бесплатные. Вам просто нужно сделать быстрые исследования, и вы, скорее всего, выберете тему, которая поможет вам ускорить время загрузки вашего сайта WordPress. Если у вас есть время, можете прочитать интересные статьи о темах в WordPress.

Оптимизация изображения

Да, изображения имеют важное значение. Но, подумайте о том, как плохо образы могут повлиять на скорость загрузки вашего сайта. Не оптимизированные и большие изображения будут загружаться медленно, что может привести к тому, что посетитель покинет сайт. Чтобы сэкономить время, пропускную способность и улучшить ранжирование поисковой машины вам нужно позаботиться о графике, отображаемых на вашем сайте. Использовать оптимизацию изображений с помощью некоторых из WordPress плагинов, разработанных по этой причине, как например WP Smush.

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

Минимизировать CSS и файлы JavaScript

Минимизация файлов CSS может быть хорошим, особенно если вы не в состоянии объединить их в единый оптимизированный файл. То же самое касается файлов JS. Скорее всего, есть много плагинов, которые могут помочь вам в этом, в том числе, нашего ранее упомянутого плагина W3 Total Cache.

Сеть доставки контента

Иногда географическое расстояние между сервером, где размещен ваш сайт и посетители вашего сайта могут влиять на скорость загрузки. Общим решением этой проблемы является использование сеть доставки контента или CDN. Используя услугу CDN вы можете разгрузить статические файлы, а также изображения, так что ваши посетители сайта могут иметь лучший опыт. Это позволит снизить нагрузку на сервер и позволит значительно повысить производительность сайта.

Всего вам наилучшего! Если у вас есть вопросы или идеи по производительности сайта, пишите в комментарии.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Просмотров: 201

Если статья понравилась, то поделитесь ей в социальных сетях:

andreyex.ru

Prostoy-Site | Все права защищены © 2018 | Карта сайта