Моделирование нагрузки

[rebel25]

У меня босс на sql. Используются кадры, табель, зарплата и укп, акп. Мне поставлена задача выяснить, будет ли работать программа через 5 лет. К этому времени ожидается рост количества работников и пользователей в несколько раз: 50 000 Работников и 300-500 одновременно работающих пользователей.
Скажите, сиквельный босс вообще рассчитан на такие объемы информации?
Мне нужно смоделировать нагрузку на тестовой среде. Допустим работников я размножу, а дальше что, скажите как это вообще делается?

[DUCKKK]

И сейчас есть предприятия, на которых больше 50000 работников.

Число пользователей - около 150-200, наверное.

Пока ни у кого не взорвалось

[RVV]

работников я размножу ..., скажите как это вообще делается?

[Volod]

Однозначно, работать будет, тут с DUCKKK соглашусь, но
по самым скромным подсчетам, если взять из заявленных 2 секунда на расчет ЗП 1 сотруднику то на 50000 уйдет примерно 28 часов.
2 секунды безусловно очень усредненный показатель, который может быть и больше мы же это все понимаем.
Ну и вероятно тут уже можем столкнутся с физическим ограничением железа на чтение - запись.

[DUCKKK]

Точно "все понимаем"? Можно догнать до 1 секунды и даже меньше? Сильно сомневаюсь

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

[Volod]

Я же не просто так написал про среднее значений, в идеале с одним начисление в прямых, безусловно можно сделать и десятые доли и сотые по времени расчета.
Так же, что вы подразумеваете под распараллеливанием? Одновременный запуск по группе работников-отделов ?

[DUCKKK]

Либо одновременный запуск на одной машине нескольких сессий Расчета зарплаты для разных отделов, либо то же самое - на нескольких машинах.

"безусловно можно сделать и десятые доли и сотые по времени расчета" - если Вы будете вот так и дальше утверждать совершеннейшие глупости с зубастыми смайликами - то всякое желание общаться просто пропадает.

SQL Server - всего лишь железка, и у него БЕЗУСЛОВНО есть предел быстродействия.

[Volod]

Мне неизвестна причина вашей неприязни к смайликам, а так же опыт поддержки, я делюсь своим опытом. 2 секунды это намного более реальное значение чем 1.

[DUCKKK]

"2 секунды это намного более реальное значение чем 1." - да, я именно об этом.

А вот "безусловно можно сделать и десятые доли и сотые по времени расчета." - это совершенно нереальное значение в любом случае.

[Antoshes]

DUCKKK
может быть к тому времени уже LIC и SL_UNI_TAX In-Memory будут и скорость, действительно удастся увеличить ?
Есть ли идеи на этот счет у разработчиков?

[DUCKKK]

У разработчиков много идей. Может и удастся.

[GIN]

видел такие БД с пользователями > 300 и численностью рабочего персонала около 50к... как раз проблему озвучивали в долгом расчете з/п, кроме как "параллельного разделения" ничего посоветовать не нашлось... может кто знает ещё какие решения?
_________________
Что бы увидеть свет в конце туннеля, нужно все время копать...

[Joenka]

В БОСС-е расчет по каждому сотруднику сделан через цикл и запуск Z-процедур. Если ВСЕ переписать через SQL и выполнять действия сразу по всем записям таблиц БД, то безусловно будет гораздо быстрее работать, тем более что расчет моей зарплаты ну никак не связан с расчетом дяди Васи из другого отдела (ведь параллельно то расет запускать можно!). Но это не вот прям пальцем щелкнуть - переписывать придется весь функционал расчета, а это годы наработок! Не исключаю, что и переписать "в лоб" тоже не везде получится, так как некоторые операции придется оптимизировать и разбивать на отдельные действия и создание временных таблиц и.т.д.

[Volod]

Выполнить действие СРАЗУ по всем записям БД ?

Не выход.
Все упирается в себестоимость - так сказать оборудования. в вашем варианте сервер может стоить как бы не малых денег. Да и insert все равно нужно будет делать по тем же так сказать всем записям куда то.

[GIN]

По всем сразу считать, на стороне SQL... что то сомнительно и хлопотно очень, во первых даже брать в расчет сколько это трудо-часов составит, ну если конечно какая-то буржуйская контора заплатит за такое... то все равно, скорее всего и тут без "циклов" не обойтись - это раз. Даже если, то какая это таблица (а она будет не одна!) и сколько в ней операций нужно будет проделать, обработка её по всем операциям не намного уменьшит время, тут согласен с Volod - . Два, как минимум это регламентное время запуска расчета, ну и само требование к "железу".

Мое предположение такое, из минимума исходим, (может кто чего добавит, исправит или подскажет где, как, на чем это реализовать):

1. Оптимизация расчета, найти те ВО (в купе с сотрудниками) которые по статистике больше занимают время расчета. Написать "Счетчик" который все это зафиксирует.
2. Разделение расчета, "утилита" (собственно все что угодно) способная запускать сама несколько сессий расчета по своим группам (подразделениям, сотрудникам и т.д.) стандартный расчет. Может быть более гибкая, что бы можно было отметить - "всех" или "по условию".

Думаю, что это и менее затратно и более эффективно? И уменьшит время, не так конечно эффективно, как хотелось бы... но "Без хлеба, без соли никто не обедает".

ЗЫ: Обсуждаем, критикуем