Для забезпечення безперебійної роботи Device Manager (далі ДМ) під навантаженням основна вимога це високопродуктивна дискова підсистема, тому що зберігання чеків/змін/налаштувань стандартно здійснюється у БД SQLite.
CPU: Рекомендовано використовувати саме x64 процесори(x32 версія підтримується лише на Windows та Android). Мінімального порогу до частоти та ядер процесора наразі немає. Додаток працює на всіх системах якщо версія OS не нижче за мінімальну підтримувану.
ОЗУ: У фоновому режимі коли не проводяться чеки додаток використовує не більше 10-30мб оперативної пам'яті. (На OS Linux резервується більше ОЗУ, приблизно до 60мб).
У разі постійної роботи одного ПРРО(проведення чеків) використання ОЗУ може зрости до 15 - 40мб. Відповідно від кількості робочих ПРРО в додатку потрібно розраховувати скільки може знадобитись вільної оперативної пам'яті.
Варто враховувати що при використанні MS SQL або postgres бази може бути кілька з'єднання з БД одночасно відповідно залежно від кількості кас може знадобитись більше оперативної пам'яті.
Наразі значення використання ОЗП на Windows при одночасній роботі 200+ ПРРО - 6-6.3 гб.
ДМ стандартно використовує одну sqlite базу даних для всіх створених ПРРО/пристроїв.
Відповідно від бази даних буде залежати кількість максимально доступних ПРРО для роботи.
На 1 ДМ ми рекомендуємо ставити не більше 3-5 ПРРО з високим навантаженням (орієнтовно 1000 чеків в день по одному ПРРО. При більшій кількості рекомендовано зменшити кількість ПРРО на одному ДМ).
При меншому навантаженні можливо створити до 10 ПРРО.
На SQLite дозволено одночасно використовувати не більше 10 ПРРО. При спробі додати 11 - буде повернуто помилку. Це пов'язано із низькою надійністю самої бази даних та низькою швидкодією при паралельній роботі, відповідно при роботі з великою кількістю ПРРО на одному ДМ на швидкість роботи буде дуже залежати від швидкості накопичувача. Важлива як кількість ПРРО так і кількість чеків за одиницю часу на одному ДМ. Чим більше ПРРО/чеків на одиницю часу - тим більше може бути час очікування відповіді на API запити.
Обмежень по кількості кас як такого немає, застосунок зможе обслуговувати досить велику кількість кас. При потребі створити всі ПРРО на одному сервері рекомендовано додавати ПРРО частинами(по 10, 20 шт, або зручну кількість). Так можна буде відслідкувати скільки ПРРО Ваш сервер зможе обслуговувати.
Максимальна кількість одначасно працюючих ПРРО з середнім навантаженням (200-500 чеків в день по кожному ПРРО) яка перевірялась на MS SQL - 350 кас. Більша кількість - наразі не перевірялась.
На OS Linux було зафіксовано що при великій кількості чеків в секунду можливе різке збільшення використання ОЗУ застосунком до кількох гб при кількості ПРРО та пристроїв більше 70-100!
Обмежень по кількості кас як такого немає, застосунок зможе обслуговувати досить велику кількість кас. При потребі створити всі ПРРО на одному сервері рекомендовано додавати ПРРО частинами(по 10, 20 шт, або зручну кількість). Так можна буде відслідкувати скільки ПРРО Ваш сервер зможе обслуговувати.
Максимальна кількість одначасно працюючих ПРРО з середнім навантаженням (300-800 чеків в день по кожному ПРРО) яка перевірялась на postgresql - 100 кас (+ 100 чекодруків). Більша кількість - наразі не перевірялась.
В даному розділі вказано якими способами можна налаштувати роботу застосунку при великому навантаженні та кількості ПРРО задля стабільної роботи.
Можна змінити субд з якою буде працювати ДМ на MS SQL або Postgresql. Обрати можна яку зручно.
Переваги:
Недоліки:
Детальніше по налаштуванню в інструкції:
Є можливість запустити кілька сервісів ДМ на одному пристрої чи сервері.
На 1 фізичному сервері ми рекомендуємо ставити не більше 20 копій(інстансів) ДМ-а.
Фактично копія(інстанс) використовує всі ті ж самі дані що і основний device manager, основна різниця в:
Детальніше по налаштуванню в інструкції: