Size: a a a

Архитектура ИТ-решений

2021 January 26

Y

Yury in Архитектура ИТ-решений
Gennadiy Kruglov
Последовательность действий такая:
1. выполняете вертикальное масштабирование (железо почти всегда дешевле оптимизации)
2. оптимизируете решение
3. выполняете горизонтальное масштабирование
версия Бизнес- не позволяет масштабировать
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Yury
обрезать пик - в пиковую нагрузку не продавать столько много. при этом теряется и маржа. и приобретаемая дополнительная мощность во все оставшееся время будет простаивать. кроме того достаточно высокая цена новой версии и ежегодных платежей
Так себе решение. Но нужно учитывать бизнес-модель
источник

m

morlord in Архитектура ИТ-решений
Yury
версия Бизнес- не позволяет масштабировать
вертикальное то позволит. а за горизонтальным надо тырпрайз брать.
но могу сказать так - пока есть возможность лучше перелезть на что-то получше
источник

AK

Andrei Kharytonenka in Архитектура ИТ-решений
направьте все запросы в очередь и распределите нагрузку по времени
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
morlord
вертикальное то позволит. а за горизонтальным надо тырпрайз брать.
но могу сказать так - пока есть возможность лучше перелезть на что-то получше
Почему?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andrei Kharytonenka
направьте все запросы в очередь и распределите нагрузку по времени
Очередь в кассу?
источник

AK

Andrei Kharytonenka in Архитектура ИТ-решений
Gennadiy Kruglov
Очередь в кассу?
разные варианты есть. возможно надо будет немного изменить юзер экспириенс
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andrei Kharytonenka
разные варианты есть. возможно надо будет немного изменить юзер экспириенс
А скорее всего сделать редизайн (много чего переписать) вслед за UX
источник

m

morlord in Архитектура ИТ-решений
может конечно у нас спецы что-то не так сделали, но у нас не смогли нормально отмасштабировать это дело и поддержка битрикса\внедренцев ничем помочь не смогла.
у нас мариядб стоит. при настройке мастер-мастер скорость работы упала(как визуально,так и по метрикам самого битрикса) сейчас стоит мастер-слейв, но кардинально жизнь нам это не упрощает
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
morlord
может конечно у нас спецы что-то не так сделали, но у нас не смогли нормально отмасштабировать это дело и поддержка битрикса\внедренцев ничем помочь не смогла.
у нас мариядб стоит. при настройке мастер-мастер скорость работы упала(как визуально,так и по метрикам самого битрикса) сейчас стоит мастер-слейв, но кардинально жизнь нам это не упрощает
Есть гарантии, что на чём-то другом спецы сделают всё так? Вы стоимость миграции и риски учитываете?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Купите железа и оптимизируйте. Потом думайте о чём-то другом. На чём-то другом с очень высокой вероятностью придётся пройти похожий путь.
источник

m

morlord in Архитектура ИТ-решений
Gennadiy Kruglov
Есть гарантии, что на чём-то другом спецы сделают всё так? Вы стоимость миграции и риски учитываете?
есть. у нас сейчас и своя разработка есть, на которой(ПО) работает раза в 2(если уже не больше) сотрудников. системы сопоставимые по функционалу. таких проблем не испытывает
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
morlord
есть. у нас сейчас и своя разработка есть, на которой(ПО) работает раза в 2(если уже не больше) сотрудников. системы сопоставимые по функционалу. таких проблем не испытывает
Если честно, звучит не очень убедительно
источник

Y

Yury in Архитектура ИТ-решений
Gennadiy Kruglov
Купите железа и оптимизируйте. Потом думайте о чём-то другом. На чём-то другом с очень высокой вероятностью придётся пройти похожий путь.
железо уже максимальное
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Yury
железо уже максимальное
Пункты 2 и 3. Потом по частям переезд. Те что больше всего "тормозят", в первую очередь
источник

SL

Sergey Lukin in Архитектура ИТ-решений
я, конечно, не знаю сложности вашего сайта и бизнес процессов которые он поддерживает.
но может поставить кеширующий реверс прокси который хотя бы на  часть запросов будет из кэша выдавать.
( у вас же есть "анонимные пользователи" ? )
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Sergey Lukin
я, конечно, не знаю сложности вашего сайта и бизнес процессов которые он поддерживает.
но может поставить кеширующий реверс прокси который хотя бы на  часть запросов будет из кэша выдавать.
( у вас же есть "анонимные пользователи" ? )
Это часть п.2 в моём понимании
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Переписал п.2 в - "оптимизируете решение"
источник

Y

Yury in Архитектура ИТ-решений
спасибо всем откликнувшимся. есть над чем думать
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Более сложный вариант, сразу после п.2, - идентификация узких мест и вынос их в отдельные компоненты с последующим горизонтальным масштабированием этих компонентов.

Но если технический долг высокий ( Big Ball of Mud), то это будет сделать сложно. Кто-то это назвал бы сплитом монолита на микросервисы.
источник