• avatar fadich
  • 0
Это описано в разделе «Runtime constraints on resources» https://docs.docker.com/reference/run/. Флаг -m или --memory.
В преднастроенном шаблоне Oracle Linux в InfoboxCloud файла подкачки нет, поэтому он создается скриптом согласно требованиям OnlyOffice.
В скрипте установки присутствует команда по созданию файла подкачки. Зачем это необходимо, если в /etc/fstab уже определена ФС типа swap?
Каким образом возможно определить количество ресурсов (например, ОЗУ), которые будут доступны приложению в контейнере?
Поменяли, спасибо.
  • avatar fadich
  • 0
Логичней было бы поменять местами пункт 2 и 3, быстрее бы был апдейт.
По вопросам пользователей: В статье есть намек: будет предоставлен виртуальный сервер. Почему мы не можем дождаться релиза и почему об этом стоит беспокоиться пользователям, даже тем, кто ищет максимально доступное решение — расскажем в письме участникам тестирования. Технически изменения очень велики в основе технологии. Будет как минимум 3 вау-фактора. Но нельзя делать анонс раньше времени. И главное — после выхода в продакшн цены будут очень доступные. Есть сегмент Enterprise и те, кому необходимо в любой момент времени изменять кол-во потребляемых ресурсов – для таких пользователей отлично подходит Облачная инфраструктура infobox.ru (гибкое облако по адекватным ценам и без скрытых платежей за транзакции с возможностью изменения cpu/ram/диска и др. в любое время независимо от других параметров). А есть те, кто хочет сильно дешевле, меньше возможностей, но очень надежно. Для них эта технология. В письме участникам расскажем больше. Пользователям выделенных серверов и классических VPS такая надежность не снилась.
Прочитал вашу статью с советами по оптимизации вордпресса на хабре, и решил добавить пару пунктов. Аккаунта на хабре у меня нет, поэтому регистрируюсь и пишу тут.

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

Итак, в интернете сейчас очень много статей по оптимизации скорости работы WordPress. И практически все они, на мой взгляд, не корректны.

1. Любая оптимизация должна начинаться с выявления «проблемного места». Почему-то авторы статей этот пункт игнорируют.

Отсюда — перед началом оптимизации стоит выяснить, что тормозит. Для этого можно использовать плагины (к примеру P3 Profiler), сторонние сервисы вроде Pingdom, утилиты на стороне сервера (msqltuner), да даже просто, иногда достаточно открыть сайт в браузере и посмотреть на ошибки в консоли. И только после выявления проблемного места стоит начинать работу.

Давайте представим, что сервер у нас находится в идеальном состоянии. Оптимизация сервера, это все же тема для отдельной статьи. И пройдемся по остальным возможным проблемам.

2. ДНС.
Хоть и решил не трогать настройку сервера, все же не могу не указать этот пункт.
На одном из моих проектов на ресолв доменного имени при первом посещении тратилось больше 4х секунд — днс сервер был физически удален от основной массы пользователей. Поэтому, если днс сервера у вас находятся где-то в Певеке, а основная масса посетителей из совершенно другого региона, стоит это исправить (перенести пользователей ближе к ДНС серверу, или ДНС сервер к пользователям — что будет проще).
Ну или всегда можно воспользоваться CloudFlare CDN

3. Статика
Раз уж обратили внимание на географическое расположение пользователей, стоит посмотреть, как у вас раздаются картинки, скрипты, стили. То есть как у вас раздается контент и статика с сайта. Если скорость загрузки таких файлов медленная, стоит переместить их на CDN, в облако. Это несколько снизит нагрузку на сервер и повысит скорость загрузки этих ресурсов для пользователей.

CDN сейчас достаточно много. Как платных, так и бесплатных. Самый простой вариант — поставить JetPack. Один из модулей этого плагина, Photon, позволяет использовать CDN от WordPress.org для раздачи картинок.
Из минусов — этот плагин работает только с картинками с контента. Стили, скрипты шаблона будут так же раздаваться с вашего сервера.

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

Некоторые js библиотеки можно раздавать с серверов гугла/яндекса. Но не рекомендовал бы менять в шаблоне путь к jQuery, что идет по умолчанию, на путь к гуглу. Если важна возможность автоматического обновления, jQuery лучше отдавать тот, что идет в комплекте с движком.

Если вес картинок на вашем сайте очень большой, стоит воспользоваться плагинами для отложенной загрузки изображений, вроде LazyLoad.

Если использовать CDN в вашем проекте по каким-то причинам невозможно, стоит перенести статику шаблона на отдельный поддомен, без cookies.

4. js
Профилирование js — так же тема для отдельной статьи. Поэтому ограничимся более простыми советами
Бывает плагины на сайте конфликтуют. Из-за ошибок js некоторые скрипты могут перестать работать. К примеру, может перестать работать слайдер, будет казаться, что сайт загружается долго.
Для этого пункта достаточно посмотреть, нет ли у вас ошибок в консоли.

5. шаблон и плагины
у вас могут супер быстро раздаваться картинки, быть идеальный js, но все равно медленно работающий сайт.
Стоит посмотреть на php код шаблона и плагинов.
Можно попробовать визуально выявить «тяжелые» запросы. К примеру, у вас может выводиться блок с выборкой 10 самых комментируемых записей, из категории яблоки, за этот месяц, от автора Иван, в произвольном порядке.
Постоянно делать такой запрос не самое лучшее решение. Лучше воспользоваться codex.wordpress.org/Transients_API — сделать такой запрос с сортировкой по к-ву комментариев и сохранить его в кеш.
Отсортировать в произвольном порядке на стороне php.
При следующих загрузках страницы забирать результат парой «легких» запросов из кэша. И опять же сортировать на стороне php.

Или вы можете брать данные с стороннего сервера (rss или, допустим, обращаетесь к апи инстаграмма). Все эти запросы так же стоит кэшировать. Стоит проверить, какие функции используются для этого в вашем коде. Если curl, стоит заменить на встроенные, вроде wp_remote_get.

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

Бывает, что такой блок у вас может быть сквозным, повторяться на нескольких страницах. Чтоб не дергать каждый раз сервер, при переходе пользователя на следующую страницу, можно после первой загрузки сохранять полученный результат в localStorage, указав короткий «срок жизни» этим данным. На следующей странице брать данные локально с пользователя.

4. Предзагрузка
Такой подход — загрузку и сохранение данных можно применять не только для отдельных блоков. Можно кэшировать полностью целые страницы (если позволяет верстка).
Очень просто это сделать для хрома и фаерфокса — можно добавить rel=«prefetch prerender» для самых важных страниц. В хроме страница, на которую указали подобным образом, будет загружена и отрендерена в отдельной скрытой вкладке. После клика пользователя по ссылке, эта страница откроется мгновенно. Фаерфокс такую страницу полностью не отрисовывает, но загрузит ее так же чуть быстрее.
Из минусов — могут быть ложные попадания. Страница может загрузится в скрытой вкладке, а пользователь может не перейти по такой ссылке. Может выйти лишней нагрузкой на сервер.
Ну и подобная вкладка не всегда будет работать как надо — хром подобным образом открывает только одну ссылку из всех открытых в данный момент вкладок.

Предварительная загрузка контента фактически хоть и не ускоряет работу сайта, но создает впечатление более быстрой работы сайта для пользователя.
Спасибо за интересную статью! Опубликована на главной.
Все верно. Биткоины майнить на CPU совсем невыгодно. Другое дело, что есть пользователи, которые верят в чудо и пытаются. И таких много.
  • avatar fadich
  • 1
Биткоин, давно не фармят на процессорах. Актуально для других криптовалют, например PrimeCoin. Замечу, при теперешней сложности, даже на платном аккаунте, за сутки майнинга ты не окупишь ресурсов затраченных за сутки.
Добавил к задаче, по первому вопросу будет статья. По второму: например так.
Для того, чтобы привязать домен к IP адресу балансировщика и иметь возможность при необходимости добавлять ноды горизонтального масштабирования, не меняя запись в dns. При добавлении нод в Jelastic балансировщик автоматически их подхватит.
Хотелось бы увидеть хорошую статью по эксплуатации memcached. Иии ещё как сделать ssl сертификат в соответствие с требованиями ГОСТ.
А зачем использовать балансировщик при работе только одной ноды? Кстати, он автоматически включится при использование двух и более нод.