от 500 до 2000 пользователей мобильного приложения
Предлагаю обсудить ситуация при подключении к одной файловой базе от 500 до 2000 пользователей мобильных приложений.
И так что есть на текущий момент. VDS сервер на SSD 5 ядер CPU 80 GB SSD 6 GB RAM. На нем самописная файловая база.
На текущий момент тестируется 20-30 аппаратов с установленной 1с на борту. Одновременных подключений пока не пробовали но думаю надо будет провести тестирование и проверить работоспособность.
В файловой базе напрямую через веб или тонкий клиент никто не работает только работа через МП.
Сразу скажу что это программа для Учета и контроля больше подробностей рассказать не могу :)
В системе заполняется 2 документа с 10-15 строками и 2-3 фото(качество фото ужимаю до 100-150кб).
Сейчас стоит задача запустить всех работников и подключить к программе. Как только все ринуться в программу и пойдет массовая работа предсказать не могу что может быть. Вот и интересует мнение людей кто что то подобное запускал.
Запускать и работать по регламенту не получиться думал уже про это. Так что одновременных соединений предсказать не могу.
Вопросы о лицензировании сразу опустим :)
И так что есть на текущий момент. VDS сервер на SSD 5 ядер CPU 80 GB SSD 6 GB RAM. На нем самописная файловая база.
На текущий момент тестируется 20-30 аппаратов с установленной 1с на борту. Одновременных подключений пока не пробовали но думаю надо будет провести тестирование и проверить работоспособность.
В файловой базе напрямую через веб или тонкий клиент никто не работает только работа через МП.
Сразу скажу что это программа для Учета и контроля больше подробностей рассказать не могу :)
В системе заполняется 2 документа с 10-15 строками и 2-3 фото(качество фото ужимаю до 100-150кб).
Сейчас стоит задача запустить всех работников и подключить к программе. Как только все ринуться в программу и пойдет массовая работа предсказать не могу что может быть. Вот и интересует мнение людей кто что то подобное запускал.
Запускать и работать по регламенту не получиться думал уже про это. Так что одновременных соединений предсказать не могу.
Вопросы о лицензировании сразу опустим :)
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
возможно получиться по городам нагрузку распределить. но это заход будет по 1000 устр-в.
при подключении одновременно 50 устр-в(надеюсь это максимально будет в течении минуты) думаю при записи документа будет проблема с блокировками. в эту сторону копать наверное.
при подключении одновременно 50 устр-в(надеюсь это максимально будет в течении минуты) думаю при записи документа будет проблема с блокировками. в эту сторону копать наверное.
(3) 50 подключений IIS должен нормально параллельно держать. откуда тут последовательные рассуждения не понятно, видимо зависит от многих факторов.
если инфу нужно только слить, то проблем тут нет. запишите нужный документ и отключитесь, отдельным рег заданием проводите его.
если инфу нужно только слить, то проблем тут нет. запишите нужный документ и отключитесь, отдельным рег заданием проводите его.
задача весьма не тривиальная, решал подобное, это просто ад.
Первое - надо строить слабосвязанные системы, nginx и прочую лабуду.
Ибо веб сервсы в 1с - по сути последовательны, будет очередь, когда будет очередь - будет тупить веб сервер, когда он будет тупить - начнут отваливаться, а потом еще больше соединений и т.д. и т.п.
Тут реально много нюансов, но у меня еще задача была с большими объемами :)
Не думаю что на форуме будут делиться такой информацией, но скажу одно - слабосвязанные системы, если не они - рискуете положить все :)
Первое - надо строить слабосвязанные системы, nginx и прочую лабуду.
Ибо веб сервсы в 1с - по сути последовательны, будет очередь, когда будет очередь - будет тупить веб сервер, когда он будет тупить - начнут отваливаться, а потом еще больше соединений и т.д. и т.п.
Тут реально много нюансов, но у меня еще задача была с большими объемами :)
Не думаю что на форуме будут делиться такой информацией, но скажу одно - слабосвязанные системы, если не они - рискуете положить все :)
(4)
но на http сервисы вешать буду. это уже плюс. думаю при обмене соединение будет 10 сек.
может как один из вариантов распределить соединения внутри базы по регистрам сведений по городам тем самым уменьшить
нагрузку. хотя конечно пока не столкнулся с проблемой искать решения тяжело.
Ибо веб сервсы в 1с - по сути последовательны
но на http сервисы вешать буду. это уже плюс. думаю при обмене соединение будет 10 сек.
может как один из вариантов распределить соединения внутри базы по регистрам сведений по городам тем самым уменьшить
нагрузку. хотя конечно пока не столкнулся с проблемой искать решения тяжело.
эх уж, нет веб сервисов отдельно. есть http сервисы и soap сервисы (то что 1с назвало веб сервисами), это все веб сервисы :) и даже odata, в какой то мере. Отличаются только протоколами передачи, и все.
Тут не важно что выбрать.
Проблема тут совершенно в другом. В любом случае - советую вначале создать тестовую нагрузку, сервис должен держать в твоем случае до 5000 соединений и умножь на то, как надо часто, и проработать минимум сутки и не упасть, когда сделаешь - тогда все поймешь :)
Тут не важно что выбрать.
Проблема тут совершенно в другом. В любом случае - советую вначале создать тестовую нагрузку, сервис должен держать в твоем случае до 5000 соединений и умножь на то, как надо часто, и проработать минимум сутки и не упасть, когда сделаешь - тогда все поймешь :)
Тестирование наше все.
1. Создать базу, в ней запустить 1000 фоновых заданий, которые с периодичностью раз в минуту выполняют запрос к ЦБ аки мобильное приложение.
2. Наблюдать.
3. Результатами наблюдений поделиться с нами.
1. Создать базу, в ней запустить 1000 фоновых заданий, которые с периодичностью раз в минуту выполняют запрос к ЦБ аки мобильное приложение.
2. Наблюдать.
3. Результатами наблюдений поделиться с нами.
1. Фокус-группа из небольшого количества (~50) пользователей, средних, не надо маньяков и лентяев. Запускаем их в базу. Считаем количество соединений в единицу времени с учетом разбиения дня на периоды активности, то есть количество запросов в минуту для каждого периода.
2. Исходя из этого считаем количество запросов в минуту при максимальном количестве пользователей в наиболее загруженный период
3. Делаем нагрузочный тест, который воспроизведет эти запросы. Причем не последовательно одним клиентом, а параллельно. Средств тестирования веб-сервисов (что soap, что обычных get/post) море, выбирайте то что нравится
4. Покупаем сервер 1С и SQL :)
2. Исходя из этого считаем количество запросов в минуту при максимальном количестве пользователей в наиболее загруженный период
3. Делаем нагрузочный тест, который воспроизведет эти запросы. Причем не последовательно одним клиентом, а параллельно. Средств тестирования веб-сервисов (что soap, что обычных get/post) море, выбирайте то что нравится
4. Покупаем сервер 1С и SQL :)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот