Документация Timetta
Общие сведения
Надёжность и безопасность
Покупка лицензии
Регистрация в Timetta
Приложения и лицензии
Приобретение и расширение лицензии
Начало работы
Вход в Timetta
Блокировка учётной записи
Личные настройки
Замещение пользователя
Жизненные циклы и воркфлоу
Технологии ИИ
Роли в системе
Проекты
Концепции
Структура проектов
Логика прав доступа
Рекомендации для коммерческой компании
Публикация плана
Управление рисками
Типовой процесс работы с проектом
Валюта проекта
Версионирование
Типы учёта проекта
Учёт в разрезе юридических лиц
Типы показателей проекта
Принципы прогнозирования
Рекомендации по анализу изменений показателей проекта
Примеры работы с версиями проектов
Управление по контрольным точкам
Компоненты
Программы проектов
Программы
Портфели проектов
Работа с портфелем
Инструкции
Создание проекта
Создание тарифов для клиентов
Создание плановых показателей проекта
Создание тарифов для проектов
Формирование команды проекта
Формирование списка работ проекта
Просмотр структуры работ по ссылке
Ввод оценки затрат
Заполнение ресурсного плана
Ввод оценки выручки
Наследование проекта
Оценка выставления счетов и получения оплат
Оценка счетов от субподрядчиков и оплат субподрядчикам
Копирование проекта
Создание версий проекта
Использование Мастера выручки
Создание, редактирование и удаление периодических затрат
Изменение типа учёта проекта
Слияние версий проекта
Задачи
Часто задаваемые вопросы
Права на типы задач
Финансы
Ресурсы
Таймшиты
Клиенты
Вики
Использование вики-пространств
Логика прав доступа к вики-пространствам
Работа со страницами
Затраты
Отчёты и аналитика
FAQ
Типы отчётов
Тип отчёта «Акты»
Тип отчёта «Баланс отсутствий»
Тип отчёта «Бронирование»
Тип отчёта «Биллинг»
Тип отчёта «Версии проектов»
Тип отчёта «Задачи»
Тип отчёта «Задачи проектов»
Тип отчёта «Затраты»
Тип отчёта «Заявки на затраты»
Тип отчёта «Заявки на отсутствия»
Тип отчёта «История ставок пользователей»
Тип отчёта «Запросы ресурсов»
Тип отчёта «Навыки пользователей»
Тип отчёта «Пользователи»
Тип отчёта «Проводки»
Тип отчёта «Ресурсный план»
Тип отчёта «Ресурсный план (по версиям)»
Тип отчёта «Проекты»
Тип отчёта «Сертификаты пользователей»
Тип отчёта «Счета»
Тип отчёта «Счета (строки)»
Тип отчёта «Таймшиты»
Тип отчёта «Таймшиты детально»
Тип отчёта «Финансы»
Тип отчёта «Структура работ»
Тип отчёта «Центры затрат проектов»
Тип отчёта «Задания воркфлоу»
Тип отчета Клиенты
Тип отчета «Контакты»
Тип отчёта «Сделки»
Тип отчёта «История состояний сделок»
Тип отчёта «Взаимодействия»
Использование отчётов
Группировка данных источника
Группировка данных в отчёте
Типы виджетов
Общие отчёты и шаблоны
Настройка отчёта
Экспорт отчётов
Пользовательские настройки отчёта
Вычисляемые поля
Особые колонки отчётов с временными рядами
Использование панелей мониторинга
Публикация панелей
Фильтры источников данных
Настройка и администрирование
Типовой порядок настройки системы
Язык формул и выражений
On-premises
С чего начать
Поставка on-premises
Доступ к докер-реестру
Создание баз данных
Конфигурация приложений
Создание сертификата
Инициализация БД и первый вход
Установка PostgreSQL на отдельной ВМ
Порядок обновления
Сайзинг
Методика нагрузочного тестирования
API
Общие сведения
Аутентификация
Reporting API
Ограничения
История изменений
Термины и определения

Сайзинг

Обновлено: 26.06.2024

Средняя инсталляция Кластер Kubernetes / OKD Кластер PostgreSQL Кластер Redis Кластер шины сообщений Крупная инсталляция Кластер Kubernetes / OKD Кластер PostgreSQL Кластер Redis Кластер шины сообщений Горизонтальное масштабирование

Важно

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

Рекомендации ниже являются ориентировочными и усредненными значениями.

Средняя инсталляция

  1. Зарегистрированных пользователей — 200–400.
  2. Пиковое использование — 20–40 пользователей одновременно.

Кластер Kubernetes / OKD

  • Предполагаем, что все контейнеры с компонентами Timetta запускаются в кластере с одной нодой и число подов — 1 на контейнер.
  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2-4.
  • RAM: 16GB.

Примечание

Для отказоустойчивости число подов и хостов можно увеличивать.

Кластер PostgreSQL

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 4.
  • RAM: 16GB.
  • SSD накопители, прирост — 50Gb в год.

Кластер Redis

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2.
  • RAM: 8-16GB.
  • SSD накопители (постоянное хранилище) 50Gb.

Кластер шины сообщений

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2.
  • RAM: 8-16GB.

Крупная инсталляция

  1. Зарегистрированных пользователей — 2 000–3 000.
  2. Пиковое использование — 200 пользователей одновременно.

Кластер Kubernetes / OKD

  • Предполагаем, что все контейнеры с компонентами Timetta запускаются в кластере с двумя нодами. Требования к одной ноде. Для контейнера с API запускать 2+ пода.
  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 4-8.
  • RAM: 16-32GB.

Кластер PostgreSQL

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 4-8.
  • RAM: 16-32GB.
  • SSD накопители, прирост — ~500Gb в год.
  • 2 инстанса — один для балансировки нагрузки на чтение и построение отчетов.

Примечание

Для отказоустойчивости кластера PostreSQL рекомендуется использовать кворумную репликация (quorum-based synchronous replication) и минимум два инстанса. При этом важно в строках соединения указать оба хоста.

В целях тестирования, отладки и эксплуатации мы используем пуллер соединений Odyssey и все показатели даны для кластера с данным пуллером.

Кластер Redis

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2.
  • RAM: 16-32GB.
  • SSD накопители (постоянное хранилище) 100Gb.

Кластер шины сообщений

  • Модель CPU: Intel Ice Lake (Xeon Gold 6338).
  • Число vCPU (с доступностью 100%): 2.
  • RAM: 8-16GB.

Примечание

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

Горизонтальное масштабирование

  1. Все компоненты Timetta — stateless и могут быть горизонтально масштабированы. Таким образом для масштабирования можно использовать более число нод и большее число подов.
  2. Прежде всего рекомендуется увеличивать число контейнеров для API (ввиду обработки большого числа относительно простых запросов).
  3. Reporting API часто обрабатывает «сложные» запросы и увеличение числа контейнеров не ведет к росту производительности.
Предыдущая
 Порядок обновления
Следующая
Методика нагрузочного тестирования 

Содержание

Средняя инсталляция Кластер Kubernetes / OKD Кластер PostgreSQL Кластер Redis Кластер шины сообщений Крупная инсталляция Кластер Kubernetes / OKD Кластер PostgreSQL Кластер Redis Кластер шины сообщений Горизонтальное масштабирование
Ничего не найдено

Перейти на русскую версию?