Количество одновременно работающих пользователей в базе 1С, по моему опыту варьируется от 0 до 30.

Помнится я наталкивался на статью, о том что наконец-таки смогли добиться результата работы целых 500 пользователей а новой ERP, но что-то я не могу найти где это было. Если кто-то помнит -- киньте ссылку.

Так вот, другой опыт показывает что реально в базе работать более менее комфортно около 50 пользователям, тоже не очень понятно что они там подразумевается под словом "работают".
Все остальные ухищрения подразумевают разделение баз, на центрульную/перефирийную/филиальную и настройку обменов между ними.

у меня три вопроса:
- какие еще методы ускорения 1с? (кроме как поставить железо по-быстрее)
- так сколько пользователей может работать в 1с не мешая друг другу? (в одной конфигурации, в одной ИБ)
- вот тут ( http://www.1c.ru/rus/partners/solutions/solution.jsp?SolutionID=362311 ) пишут что одновременно работающих пользователей 2500!? это ошибка? или они работают каждый со своей таблицей и не пересекаются никак?

(0) Толсто...

(0) >> какие еще методы ускорения 1с? (кроме как поставить железо по-быстрее)

Таки вам 100500 пользователей и бесплатно?

(0) ты готовь платочек побольше. Сейчас тебя заплюют.

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

(0) 500-700 ежедневно... в пик до 1000

(0) Поставить железо побыстрее уже предлагали?

(5) на одной базе? самописная?

(0)[по моему опыту варьируется от 0 до 30. ]
150 рыл в упп-хе

(6) да

(4) если у вас нет понимания направления, то рано думать о том как 1С будет работать с таким количеством - разве что ли из любопытства.

(10) а я и говорю в (4) что из любопытства.

(7) в одной ессно... когда-то это называлось упп, сейчас упп*3

(12) через 3 года приедет цирк ERP ?

(13) не... специфика бизнеса, "пухнем" сами

я могу конечно представить что железом вытягивают это "побыстрее".. но если это единственный вариант, то даже в этом случае все имеет пределы, которые не переступить.
даже в этом случае, допустим в пик работают 100 пользователей генерящих отчеты и проводящих документов, и вся эта орава упрется в sql..
отсюда вывод -- только железом.
так?
Но если некто запустил перепроведение, то ни о каких 500 пользователей не может идти речи даже на хорошем железе!?

Чел не смог осилить больше 30 пользователей, значит те кто пишет о сотнях пользователях либо врут, либо ошиблись нулями.

(15) "прямой" код очень многое решает
p.s. видимо хорошее "железо" ты не представляешь...

(15)[то ни о каких 500 пользователей не может идти речи даже на хорошем железе!?]
да, восьмёрка сырая
сотен пользователей не бывает
и тебя пытаются наипать по черному

с этим и живи, нам больше вкусного рынка достанется

(16)(17) я знаю как написать код чтоб скорость не особо зависела от железа. но это нестандартная конфа и не стандартный подход. меня больше интересует стандартные конфы. и как я понял лучше всех выглядит ERP.

(18) я не хочу с этим жить )

(0)(19) Разговор ни о чём "для диссертации". Конкретная база диктует конкретные усилия, настройки и железо. Ничего невозможного нет.

(20) вах, такой маладой, полный сил и не хочет с этим жить, почему дорогой ?

(21) ты видел базу работающую в пиках овер 200 пользоватлеей?

(23)*стандартную конфу

(21) А вечный двигатель?
По теме - из типовых, кмк, ни одна 2500 пользователей не вытянет. Но вообще - достижимо.
(23) ~400 устроит?

http://v8.1c.ru/expert/cts/cts-218-001.htm

+(25) Так, понял, не устроит, там не типовая.

(23) я вижу УПП под партионкой до 160 пользователей каждый день,
больше 30 секунд документы не проводятся
блокировки раз в неделю


ясен пень, РСВ днём в ней не делается

ну вот об этом я и говорю, вы называете похожие на истину цифры..
50-250
все остальное достигается переписыванием, железом, распределенкой..

а то я думал я что-то упустил серьезное. или не понимаю в одноэсе..

(29)Продолжу...Универсальные таблетки есть только в армии.

(29) упустил и не понимаешь

(31) да понимаю я...
вот щас еще про деловые линии почитаю мож более подробную инфу достану.
откуда там 5000 пользователей.. виртуальных.. надеюсь не один и тот же запрос делали )

(0) - до 30... в (29) на порядок больше...
и не понятно, что подразумевается под "железом". Или автор хочет на i3 с 4 ГБ оперативы и винчестером зеленой серии получить бесконечную масштабируемость?

(33) не а
у него целерон и 5400 от ноута через USB

мне для понимания

только вот не ясно что ты понять хочешь

Я вот тоже не понимаю, что значит достигается железом.
Понятное дело, что при увеличении количества пользователей надо увеличивать память, ядра, возможно частоту процессоров. При увеличении интенсивности чтения/записи надо увеличивать производительность дисков. И т.д. У 1С даже есть официальная метода подбора оборудования.

И не понимаю откуда такое недоверие к типовым. Сейчас таже буха 3.0 разработана во много раз лучше, чем способны разработать 98% активных посетителей Мисты.

(38)  гдето лучше
Гдето хуже

Пытались с восьмерочников на основе логики определить почему в зупе для двух пользователей с одинаковыми настройками у одного считает правильно а у другого не считает

Пытался в основном восьмерочник
Я так больше наблюдал

Сегодня поинтересовался решил ли он проблему
Решил
Путем консультаций на одноэсном форуме
Потому как посмотреть в код видимо очень сложно было
Да и ладно тем более что суть не в этом
А в том что для второго сотра который не считался надо было зайти в документ и перевыбрать заполненный реквизит
Просто перевыбрать
После этого перепроведение документа все сделало как надо
А до этого вот фиг вам
Просто перевыбрать реквизит
Я не знаю как это называется
Передаю со слов но не доверять причин нет озвученному мне

(0)"какие еще методы ускорения 1с? (кроме как поставить железо по-быстрее)"?
Использовать функционал из коробки по минимуму. Писать самому.
У меня одновременно работало до 150 пользователей из заведенных в системе 750. Вроде, без проблем.

(15)"железом вытягивают это "побыстрее""
А хрен вам. Не всегда "быстрее".
В одной конторе закрытие месяца на самописке было около 3-х дней. Решили купить железо помощнее. Я предполагал, что это сильно не ускорит. Купили. Довольно приличная машинка с 90 гиг. оперативки. Как ни странно, стало даже чуток дольше считаться. Причины я, примерно, представляю.

(36) меня убеждают, что УТ заработает на 1000 пользователей

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

(0)
> - какие еще методы ускорения 1с? (кроме как поставить железо по-быстрее)

максимальное ускорение даёт продуманная архитектура решения и отсутствие амнокода.

>- так сколько пользователей может работать в 1с не мешая друг другу? (в одной конфигурации, в одной ИБ)

неплохо-бы объяснить что вы имеете в виду под "работать в 1с не мешая друг другу", если 10 челам одновременно приспичит пересчитывать себестоимость прошлого месяца - понятно они будут мешать друг другу. Есть свои самописки где в периоды пиковой нагрузки одновременно более 200 пользователей работает и не мешают друг другу при этом.

>- вот тут ( http://www.1c.ru/rus/partners/solutions/solution.jsp?SolutionID=362311 ) пишут что одновременно работающих пользователей 2500!? это ошибка? или они работают каждый со своей таблицей и не пересекаются никак?

про количество - не ошибка, про "работают каждый со своей таблицей" - или вы толстый троль или вы плохо знакомы с платформой.

(0) Сделай один документ с одним регистром на управляемых блокировках - у тебя мульен пользователей работать сможет.

(0) Есле не ошибаюсь, это называется теорией массового обслуживания. Вспомни как в магазине один продавец обслуживает туеву кучу покупателей, а также вспомни понятие транзакции. Сопоставь то, что вспомнишь. Вот тебе и ответ. 2500 пользователей - не предел.

gilev.ru уже рекомендовали почитать?

(32) >  про деловые линии почитаю мож более подробную инфу достану. откуда там 5000 пользователей.. виртуальных..

5000 - это нагрузочное тестирование проводилось с учетом предполагаемого роста нагрузки.
В реальной боевой базе у них ~3500 соединений, включая фоновые задания и внешних пользователей (по COM).
Объем боевой базы ~1ТБ

> откуда там 5000 пользователей
помимо своих пользователей есть еще пользователи, получающие информацию через их веб-сайт.

По заявлению представителей фирм 1С и IBM, которые проводили нагрузочные тестирования на их базе на 5000 пользователей, конфа в Деловых Линиях хотя и абсолютно нетиповая (самописка), но при этом достаточно сложная.
Сам я их конфы не видел, но когда-то давно работал в Деловых Линиях и могу предположить (только! предположить), что насчет сложности они слегка преувеличили. Реально - конфигурация всё таки несколько попроще типовых.

(39) в зупе есть такая фича.

(49) это блин не фича... это блин баг.тем более, как я понимаю, никаких нештатных методов не делалось, все оператор ручками.

(0) 60-80 ежедневно.

(50) почему сразу баг? может при выборе этого реквизита устанавливаются другие?
у меня в одной самописке, пользователь в одном из документов (40-50 реквизитов) выбирает только 1, а остальные устанавливаются "автоматом" в зависимости от настроек. так вот, если настройки ему не сделали, то часть реквизитов может не заполнится и многие из них участвуют в алгоритме проведения.

(50) кэш? второй пользователь вообще компьютер перезагружает?

(52) да пофиг.
работа оператором ведется вручную.
при одинаковом наборе видмых на форме реквизитов - результатпроведения должен быть одинаковым.
и не уверяйте меня что это фича.

(53) да фиг его знает.
нормально написанная прога будет работать на компе и который каждый день выключают и который работает сутками... а кеши - мофги на все кеши. должно быть правильно вне зависимости отвсяких непонятных для юзверя условий.

(55)В ЗУП встречается такое иногда, да. Вообще сами по себе периодические расчеты в 8 мне кажутся слишком сложными вообще и ЗуП сама по себе достаточно непростая конфигурация в частности. Приходится писать много кода(а с зуп читать много кода), как следствие встречаются вот такие ляпы иногда. Я наступал на вот такие вот грабли v8: ЗУП надбавка фиксированной суммой, надбавка процентом и неполный месяц. посмотри в посте номер 15какое изящное решение с точки зрения фирмы 1С предлагается использовать. Я как бы это помягче сказать... "был немного удивлен". В 77 расчет был проще в разы и объективных причин городить такой огород я лично не увидел. НО! ТыЖПрограммист? Ну так посмотри код(в смысле тот кому за это деньги платят) ответ ты увидишь в таких случаях достаточно быстро. В след раз скажешь сходу, что надо перезаполнить документ. Я вообще в таких случаю говорю сразу: "а попробуйте создать новый документ?" И это не от зарплаты и не от 8ки привычка просто от общения с 1С в целом.

(54) Если все будет так - 1Сники останутся без денег ;)

P.S. РКО в режиме Прочий расход денежных средств, нажимаешь кнопку "Показать/скрыть счета учета" - и тебе то показывается счет с субконто, то не показывается. Баг?

(0) Конечно, если партии при проведении генерить, то 30 - это максимум

(28) Сколько строк средний и максимальный документы?