Clientexec.com биллинг панель
Billingserv биллинг панель
Вышел патч Blesta 5.0.4
Мы рады объявить о выпуске Blesta 5.0.4, в которой исправлены ошибки, обнаруженные в ветке 5.0. Большое спасибо всем, кто участвовал в помощи по улучшению Blesta, сообщая и подтверждая ошибки на наших форумах и в чате Discord, мы ценим вашу помощь!
Примечания к выпуску доступны по адресу docs.blesta.com/display/support/5.0.4
Релизы исправлений могут применяться только к второстепенному релизу, которому они принадлежат. Применяйте этот патч, только если вы используете 5.0.0, 5.0.1 или 5.0.2. Если вы используете более раннюю версию, вы должны загрузить полную версию. Если вы еще не обновились до 5.0, мы настоятельно рекомендуем выполнить обновление непосредственно до последней версии полного патча, то есть 5.0.3.
Billingfox.net биллинг панель
ubersmith биллинг панель
Yandex.Cloud Solution Library for Amazon Web Services
Мы знаем, что многим компаниям важна возможность работать с двумя облачными провайдерами одновременно. Для разработчиков, которые хотят развернуть проект в Yandex.Cloud и Amazon Web Services, мы подготовили набор рекомендаций и примеров кода для основных сценариев и задач.
Единое хранилище данных для распределённых сервисов и приложений, продвинутая маршрутизация в зависимости от локации пользователя, масштабируемая инфраструктура с использованием Kubernetes — эти и другие задачи мы помогаем решить компаниям, которые хотят использовать преимущества обеих облачных платформ.
Подробнее в разделе Решения → cloud.yandex.ru/solutions/yc-solution-library-for-aws
Сразу на GitHub → github.com/yandex-cloud/yc-solution-library-for-aws
Как мы ускорили работу консоли в два раза
Спойлер: задачу помогли решить неочевидная метрика пользовательского ожидания и интерактивный график
Комфортное взаимодействие с облаком напрямую зависит от скорости работы облачных сервисов. Один из ключевых сервисов Yandex.Cloud — консоль, через которую пользователи решают задачи.
Скорость работы консоли влияет не только на наши бизнес-процессы, но и на бизнес-процессы заказчиков. Количество сервисов также важно для бизнеса. Поэтому Yandex.Cloud растет супербыстро: в 2020 году появились восемь новых сервисов. В какой-то момент платформа развивалась так интенсивно, что каждый месяц мы выпускали по сервису.
Скорость развития отразилась на скорости работы консоли. Она замедлилась, и мы стали получать негативный фидбек от пользователей. Надо было принимать меры. Начали с аналитики: собрали данные, запланировали задачи на улучшение. Это принесло результаты: за несколько месяцев консоль стала работать в два раза быстрее. Рассказываем в деталях, как мы этого достигли.
Свежий взгляд на аналитику
Для начала мы придумали построить график скорости всех страниц консоли. Задача усложнялась тем, что в консоли больше сотни страниц. У каждой страницы свои критерии загрузки, поэтому иногда приходилось делать разметку вручную.
Нам было важно знать, где пользователи проводят больше всего времени и какие страницы надо ускорить первыми. Эти данные взяли за основу и стали строить систему визуальной аналитики.
Хотелось всегда держать перед глазами удобный график скорости работы консоли, видеть всю консольную аналитику и максимально быстро определять источник торможения.
В основу графика легли две метрики:
Разработчик Евгений Сорокин: «Сперва ввод метрики пользовательского ожидания был неочевидным. Казалось, что нужно концентрироваться на самых частотных запросах. Но практика показывала, что дело не в них: вызовов в Object Storage могло быть до 1к в секунду, но при этом сервис работал супербыстро».
Благодаря данным и метрикам мы локализовали проблемы в бэкенде и на фронтенде, сформировали список доработок на каждой стороне и отдали его ответственным командам.
Параллельный фикс
Что влияет на скорость работы консоли? Она складывается из множества параметров: размера статики, рендеринга компонентов. Наиболее чувствительна для пользователя скорость работы API.
Мы учли эти факторы, и в наших руках появился инструмент диагностики, который позволил быстро выявлять источник торможения. Проблемы скорости работы консоли стали устранять параллельно с клиентской и серверной сторон.
Что сделали на фронтенде
Что сделали на бэкенде
Как устроен график: расследует и показывает
Данные графика коррелируют с синтетическими тестами, сделанными до и после оптимизации.
Самая крутая фича графика, кроме измерения скорости работы консоли — отслеживание источника торможения. Мы следим за деградацией сервиса в реальном времени и быстрее выявляем и устраняем проблемы.
График скорости работы консоли видят все, это улучшает скорость и качество взаимодействия между командами разработки облачного сервиса. Панель графика интерактивна и позволяет проваливаться в низкоуровневые метрики. Можно посмотреть динамику скорости конкретных страниц.
Если мы заметили замедление работы страницы или сервиса, то можем проанализировать, какие методы API на это повлияли.
Распределение скорости запросов в API по времени:
стало
Роль пользователей
График строится на основе пользовательских метрик, которые мы собираем. Он отражает реальную скорость работы сервиса у конечных потребителей.
Мы открыты для обратной связи. Пишите нам не только о проблемах: предлагайте, как улучшить, ускорить и сделать еще удобнее интерфейс, с которым вы работаете.
Сообщить об ошибке в работе консоли → console.cloud.yandex.ru/support/create-ticket
Предложить идею → cloud.yandex.ru/features
Комфортное взаимодействие с облаком напрямую зависит от скорости работы облачных сервисов. Один из ключевых сервисов Yandex.Cloud — консоль, через которую пользователи решают задачи.
Скорость работы консоли влияет не только на наши бизнес-процессы, но и на бизнес-процессы заказчиков. Количество сервисов также важно для бизнеса. Поэтому Yandex.Cloud растет супербыстро: в 2020 году появились восемь новых сервисов. В какой-то момент платформа развивалась так интенсивно, что каждый месяц мы выпускали по сервису.
Скорость развития отразилась на скорости работы консоли. Она замедлилась, и мы стали получать негативный фидбек от пользователей. Надо было принимать меры. Начали с аналитики: собрали данные, запланировали задачи на улучшение. Это принесло результаты: за несколько месяцев консоль стала работать в два раза быстрее. Рассказываем в деталях, как мы этого достигли.
Свежий взгляд на аналитику
Для начала мы придумали построить график скорости всех страниц консоли. Задача усложнялась тем, что в консоли больше сотни страниц. У каждой страницы свои критерии загрузки, поэтому иногда приходилось делать разметку вручную.
Нам было важно знать, где пользователи проводят больше всего времени и какие страницы надо ускорить первыми. Эти данные взяли за основу и стали строить систему визуальной аналитики.
Хотелось всегда держать перед глазами удобный график скорости работы консоли, видеть всю консольную аналитику и максимально быстро определять источник торможения.
В основу графика легли две метрики:
- Время первого открытия консоли — Time To Interactive (TTI). В этом режиме, который условно назвали холодным, мы учитываем полную загрузку консоли со стилями и скриптами.
- Время перехода между страницами. В этом режиме учета — горячем — статика уже загружена. Учитывается только время ответа API и рендеринг.
Разработчик Евгений Сорокин: «Сперва ввод метрики пользовательского ожидания был неочевидным. Казалось, что нужно концентрироваться на самых частотных запросах. Но практика показывала, что дело не в них: вызовов в Object Storage могло быть до 1к в секунду, но при этом сервис работал супербыстро».
Благодаря данным и метрикам мы локализовали проблемы в бэкенде и на фронтенде, сформировали список доработок на каждой стороне и отдали его ответственным командам.
Параллельный фикс
Что влияет на скорость работы консоли? Она складывается из множества параметров: размера статики, рендеринга компонентов. Наиболее чувствительна для пользователя скорость работы API.
Мы учли эти факторы, и в наших руках появился инструмент диагностики, который позволил быстро выявлять источник торможения. Проблемы скорости работы консоли стали устранять параллельно с клиентской и серверной сторон.
Что сделали на фронтенде
- Сократили объемы поставляемой в браузер статики. Оптимизировали размер статики для первой загрузки и стали загружать пользователю только то, что ему нужно в данный момент.
- Избавились от большей части запросов, блокирующих интерфейс. То, без чего нельзя обойтись, стали загружать параллельно, где это возможно.
Что сделали на бэкенде
- Оптимизировали логику запросов для открытия консоли.
- Ускорили критичные для открытия консоли методы API.
- Вынесли часть запросов с сервера на клиент, чтобы не блокировать первое открытие консоли.
Как устроен график: расследует и показывает
Данные графика коррелируют с синтетическими тестами, сделанными до и после оптимизации.
Самая крутая фича графика, кроме измерения скорости работы консоли — отслеживание источника торможения. Мы следим за деградацией сервиса в реальном времени и быстрее выявляем и устраняем проблемы.
График скорости работы консоли видят все, это улучшает скорость и качество взаимодействия между командами разработки облачного сервиса. Панель графика интерактивна и позволяет проваливаться в низкоуровневые метрики. Можно посмотреть динамику скорости конкретных страниц.
Если мы заметили замедление работы страницы или сервиса, то можем проанализировать, какие методы API на это повлияли.
Распределение скорости запросов в API по времени:
стало
Роль пользователей
График строится на основе пользовательских метрик, которые мы собираем. Он отражает реальную скорость работы сервиса у конечных потребителей.
Мы открыты для обратной связи. Пишите нам не только о проблемах: предлагайте, как улучшить, ускорить и сделать еще удобнее интерфейс, с которым вы работаете.
Сообщить об ошибке в работе консоли → console.cloud.yandex.ru/support/create-ticket
Предложить идею → cloud.yandex.ru/features
Лицензии WHMCS Kneecaps: больше нет поддержки
WHMCS постепенно усиливает давление на пользователей устаревших лицензий. Сначала они прекратили продажу собственных лицензий в 2016 году, а осенью прошлого года запретили передачу (продажу) собственных лицензий. В сегодняшнем электронном письме пользователям (ниже) они объявили, что пользователи с имеющейся лицензией не смогут приобретать или продлевать поддержку.
Мы пишем вам, чтобы сообщить о важных изменениях в собственных лицензиях. Сегодня мы прекращаем поддержку собственных лицензий. Что это означает для вас и вашей существующей лицензии:
- Ваша лицензия WHMCS будет продолжать работать так же, как и сегодня. Вы можете продолжать запускать установку WHMCS, используя имеющуюся лицензию, сколько захотите.
- Вы не сможете приобрести или продлить поддержку своей лицензии WHMCS, вступает в силу немедленно.
- Если у вас есть действующее соглашение о поддержке с WHMCS для вашей лицензии, мы продолжим соблюдать это соглашение о поддержке до истечения срока его действия.
Если у вас нет поддержки для вашей лицензии WHMCS, и вам требуется поддержка продукта или вы хотите перейти на текущую версию, вам необходимо будет перейти на нашу стандартную модель лицензии. Вы можете получить стандартную лицензию, войдя на портал для клиентов WHMCS (https://www.whmcs.com/members)
Продолжайте вводить новшества, создавать, разрабатывать, проектировать и размещать, и знайте, что мы продолжаем инвестировать, чтобы улучшить опыт WHMCS.
Если вам нужна помощь с нашей стандартной моделью лицензии и какая лицензия лучше всего подходит для вас, мы здесь, чтобы помочь. Вы можете связаться со службой поддержки клиентов, открыв билет на www.whmcs.com/submit-a-ticket
Команда WHMCS
Что, какие тарифы делать ?
Вышла новость
hostsuki.pro/news/scale-dedicated-servers-ovh.html
Сейчас получается (модель как бы прижилась, 1000/2000 идеальная цена вышла, хотя многие покупают и по 24 или 48 озу, а вот на 64 озу никто не купил)
- 8 озу — 1000р, 16 озу — 2000р
- И сервер на 1 гигабите в Hetzner
- 12 ядер у Райзен 9, 24 потока. ОЗУ 128.
- Самый популярный пока что получается. Эпики недавние не так популярны. И даже 9900k который за 500р, тоже не так хотят, как Райзен 9. Список всякого что мы делали.
Допустим в ОВХ можно купить
- Epyc 7642 [48c/96t] (3.3GHz) / 1 ТБ DDR4 ECC 2933MHz / 4x 1.92 TB NVMe
1024 / 128 = 8 серверов типо можно заменить.
Но если купить с 1 гигабитом? То это не дело.
Нужно значит покупать с 10 гигабитами сервер. Но тогда будет 16 озу не 2000р, а 4000р уже.
Т.е. параметры одинаковые. Но зато ОВХ все такое. Можно дохуя IP бесплатных туда вешать еще. Плюс ддос защита лучше чем в Hetzner.
Если покупать в ОВХ на 256 озу или 512 озу — то уже дороже чем Hetzner выходит даже без 10 гигабитного канала.
В итоге, брать эти ОВХ ?
Или продолжать покупать дешевые дедики на 128 озу и просто кол-вом расти? Как в свое время я рос 1245/6700k или все же покупать новые на терабайт которые еще и заполнять нужно дольше, чем мелкие.
Минусы
- Долго заполнять. Нужно больше заказов. Кто-то хочет за свой % накрутки привлекать клиентов ?
- Много клиентов на одном сервере, риски.
Плюсы
- Можно сделать наконец-то шаредовый 10 гигабитный канал.
- Больше шаред ядер на дешевую ВМ-ку за 4000р.
- Много IP
- Защита и firewall
Можно вообще вот такой сделать
- 2x Epyc 7532 [64c/128t] (3.3GHz) / 2 TB DDR4 ECC 2400MHz / 6x 3.84 TB NVMe
- тоже с 10 гигабитами
НО зато кол-во ядер в разы меньше с учетом того сколько долей ВМ будет. А значит процессор будет проигрывать. Плюс 178000р нужно сразу клиентуры найти.