• avatar fadich
  • 0
Это описано в разделе «Runtime constraints on resources» https://docs.docker.com/reference/run/. Флаг -m или --memory.
1. У Oracle Linux бесплатная подписка на обновления. http://public-yum.oracle.com
Ответ почему не CentOS простой: для Oracle Linux как правило быстрее выходят обновления, что особенно критично для обновлений безопасности. Но все это можно делать практически так же на CentOS.
2. Монструозная конфигурация нужна из-за Mono, который очень любит Ram + из-за количества тулов и сервисов, которые использует OnlyOffice. K тому же не следует забывать, что OnlyOffice разворачивает сразу 3 сервера в docker, а для 3х серверов 8 гб ram – не много.
3. Не очень понял вопрос. Все что в обзоре доступно в версии Open.
В преднастроенном шаблоне Oracle Linux в InfoboxCloud файла подкачки нет, поэтому он создается скриптом согласно требованиям OnlyOffice.
Вопросы возникли следующие
1. По каким критериям выбран именно Oracle Linux разве у него не платная подписка на репозиториии
2. На основании каких тестов выбрана такая монструозная конфигурация
3. Разве в версии Опен данного продукта уже отрелизили редактор новой версии
В скрипте установки присутствует команда по созданию файла подкачки. Зачем это необходимо, если в /etc/fstab уже определена ФС типа swap?
Каким образом возможно определить количество ресурсов (например, ОЗУ), которые будут доступны приложению в контейнере?
Поменяли, спасибо.
  • avatar fadich
  • 0
Логичней было бы поменять местами пункт 2 и 3, быстрее бы был апдейт.
Есть план добавить базовый анализ ответа, пока без описания правил по коду ошибки, далее посмотрим, если еще будут запросы — постараемся сделать. Только что выкатили новую версию. infoboxcloud.ru/community/blog/iaas/228.html
Да, любой.
Многое уже улучшили, многое в планах infoboxcloud.ru/community/blog/iaas/228.html
Учтем ваши пожелания, спасибо за отзыв. Планируем в этом году еще раз обновить инструмент тестирования.
Мы еще не начали тестирование, но оно стремительно приближается.
Прошел практически месяц с момента Вашего поста, но пока мне как подавшему заявку на тестирование не пришло письмо «счастье» о том, что можно попробывать эту «Сверх секретную разработку». Это я оди такой или вы все еще не начали тестирвание
Существует возможность добавить опрос http-ресурсов по конкретной линке, возможно к этому же добавить написания правил для анализа ответа.
Плюсом считаю присутствие графиков по истории мониторинга
По вопросам пользователей: В статье есть намек: будет предоставлен виртуальный сервер. Почему мы не можем дождаться релиза и почему об этом стоит беспокоиться пользователям, даже тем, кто ищет максимально доступное решение — расскажем в письме участникам тестирования. Технически изменения очень велики в основе технологии. Будет как минимум 3 вау-фактора. Но нельзя делать анонс раньше времени. И главное — после выхода в продакшн цены будут очень доступные. Есть сегмент Enterprise и те, кому необходимо в любой момент времени изменять кол-во потребляемых ресурсов – для таких пользователей отлично подходит Облачная инфраструктура infoboxcloud.ru (гибкое облако по адекватным ценам и без скрытых платежей за транзакции с возможностью изменения cpu/ram/диска и др. в любое время независимо от других параметров). А есть те, кто хочет сильно дешевле, меньше возможностей, но очень надежно. Для них эта технология. В письме участникам расскажем больше. Пользователям выделенных серверов и классических VPS такая надежность не снилась.
  • avatar thunder
  • 0
и еще, я правильно понимаю, что могу добавить ЛЮБОЙ сайт для мониторинга? даже который мне не пренадлежит?
  • avatar thunder
  • 0
Пиьсмо уже написал) Продублирую все же езе раз:

В списке — добавить редактирование периода опроса, чтобы не надо было удалять-создавать
Добавить все же алерты на почту-джаббер-смс при недоступности сервриса/порта
Добавить возможность кастомных портов и протоколов, либо хотябы расширять текущий список. например до джабббер портов, IMAP/POP3 + SSL/TLS. Так же SSH
добавить возможность (?) опроса http ресурсов, например /nginx_status (не по порту, а конкретно линк), вохможно к этому же добавить вохможность написания правил для анализа ответа
Графики?
«выбор»\добавление сервера очень странное, можно бы их акка их также читать.
ИМХО, при заходе на страницу статистики по серверу, оно каждый раз проверяет или оно подгружает из какогото сервиса по проверке? если первое, то… :)

Спасибо.
Прочитал вашу статью с советами по оптимизации вордпресса на хабре, и решил добавить пару пунктов. Аккаунта на хабре у меня нет, поэтому регистрируюсь и пишу тут.

Решив продолжить тон, заданный в вашей статьей, основная масса моих советов так же не сильно сложна, но некоторые потребуют правки кода шаблона и плагинов. Некоторые советы применимы не только к сайтам на 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» для самых важных страниц. В хроме страница, на которую указали подобным образом, будет загружена и отрендерена в отдельной скрытой вкладке. После клика пользователя по ссылке, эта страница откроется мгновенно. Фаерфокс такую страницу полностью не отрисовывает, но загрузит ее так же чуть быстрее.
Из минусов — могут быть ложные попадания. Страница может загрузится в скрытой вкладке, а пользователь может не перейти по такой ссылке. Может выйти лишней нагрузкой на сервер.
Ну и подобная вкладка не всегда будет работать как надо — хром подобным образом открывает только одну ссылку из всех открытых в данный момент вкладок.

Предварительная загрузка контента фактически хоть и не ускоряет работу сайта, но создает впечатление более быстрой работы сайта для пользователя.