Требования к оборудованию (минимальная конфигурация) : Artix

Поскольку система работает на Ubuntu 10/14, но требует MySQL, то оттуда и будут проистекать требования к системе.
Хотелось бы узнать какие-то реально работающие примерные конфигурации (процессор/память/диск)

Как уже писал в соседней ветке, Артикс "комфортно" работает на конфигурациях CPU 800 MHz / RAM 256 Mb, встречаются у наших клиентов гораздо более древние системники с 128 Мб RAM. В "лабораторных" условиях мы тестировали работу Артикс на очень слабом железе, программа "работала" и на 566 MHz CPU и 64 Мб RAM, но нормальной такую работу уже точно не назовешь. Таким образом, 800/256 - это некий условный минимум для работы Артикс с "простым" дисконтом (скидки уровня "желтых ценников" и т. д.). При выборе конфигурации нужно учитывать, насколько сложной будет дисконтная схема. Если планируется одновременная работа нескольких акций со сложными алгоритмами типа "На каждый 5й товар в чеке скидка 20%, при этом сортировать товары по убыванию цены, исключать товары из специального каталога и давать такую скидку не более 4х раз в чеке", то нужно учитывать, что при добавлении товара в чек будет идти пересчет всего дисконта и на слабых конфигурациях будут наблюдаться "тормоза".

Так рекомендуемое железо какое?

Какое железо требуется на сервер? Памяти/винты/проц.

Хотелось бы примера типа: "на столько то касс, требуется такой-то сервер"

Для кассового сервера системные требования представлены в таблице

Вложения

Cистемные требования сервер+Loyalty.pdf (206.3 Кб, 315 просмотров)

Комфортно на 256Мб может работать касса с базой весьма скромного размера. В противном случае начнет уходить в подкачку MySQL. Либо на нормальных кассах вхолостую будет терзать диск.

Для примера, у одного из наших клиентов есть кассы с 256Мб RAM, справочник баркодов ~40000 позиций, справочник допцен ~40000, довольно простой дисконт (простые скидки, минимум наборов). Касса работает вполне приемлемо по скорости. Естественно, в момент активной загрузки справочников происходит много операций insert/update в БД, касса начинает притормаживать, но как правило такая загрузка делается регламентно, один раз в день. Основные ресурсоемкие операции происходят во время пересчета дисконта (при добавлении каждой новой позициив чек), загрузки справочников и обновления конфигурации кассы через puppet-сервер. Как правило, сложную дисконтную схему обычно можно оптимизировать по скорости выполнения (простейший пример из практики - не заводить на каждый товар отдельную акцию, а собирать эти товары в отдельный каталог и задавать акцию на каталог, это существенно ускоряет расчет). Тяжелые операции по загрузке и обновлению кассы можно планировать на не рабочее время.