Злой Бобр а потом когда объем резко подрос пришлось все это дело перепиливать. так что мой вам совет - очень хорошо подумайте прежде чем связываться с 1С. Стелят они мягко, но падать больно.

Послушав слова вышесказанные. Объем базы не должен влиять на производительность. Если это так, то скорее всего не хватает оптимальных индексов. Т.е. объем вашей базы на 1С не должен влиять на производительность системы.

Злой БобрtimkaaОбъем базы не должен влиять на производительность...
Видимо вы незнаете что такое 1С. Типовая конфигурация будет работать очень слабо и такой объем вообще непотянет.
Знаю. Говорил про 8ку. Типовые тиражируемые решения на 1С никогда не будут работать с высокой производительностью при крупных внедрениях. Их всегда дорабатывают, до нужной производительности. Это не особенность 1С, это особенность всех крупных внедрений для любых систем.

AHDPtimkaaпропущено...

Знаю. Говорил про 8ку. Типовые тиражируемые решения на 1С никогда не будут работать с высокой производительностью при крупных внедрениях. Их всегда дорабатывают, до нужной производительности. Это не особенность 1С, это особенность всех крупных внедрений для любых систем.

Видимо вы знаете только что такое 1С ;) При крупных внедрениях дорабатывают функционал системы. Перерабатываются конкретные блоки под конкретные нужды, но дорабатывать ВСЮ систему только ради повышения быстродействия системы УТОПИЯ!

Не вижу противоречия с собой:). Я же не говорил что ВСЮ систему дорабатывают по производительности. Выбирают ключевые показатели и уже контролируют их производительность, например по методике APDEX.
Да и вообще если есть сомнения в производительности, всегда надо провести нагрузочное тестирование.

AHDPЗа чей счёт и где проводить нагрузочное тестирование?

Нагрузочное естественно за счет заказчика. В крупных системах без него нельзя.
Его никак нельзя избежать, оно все равно будет. Тут его или будут делать бессловесные роботы (Использовать конфигурацию "Тест-центр") или живые пользователи при начале работы. И если его не сделать, то очень велика вероятность, что при начале работы пользователи будут визжать и жаловаться, что программа не работает, все медленно и т.п.

Тут просто надо просто заказчику объяснить зачем оно нужно. Чтобы он не думал, что это какое-то высасвание денег из него. Если заказчик вменяемый, то это вполне возможно обосновать.

AHDPТогда это я идеалист :( , а вы обычный "Франь" ;) Забавно, но созвучно с фраер. Прошу без обид. :)

Тоесть я, как заказчик, на этапе выбора ПО должен ещё и нагрузочном тестировании подумать? Ничего, что серьёзное оборудование в Россию под заказ поставляется!? Может мне ещё за свою зарплату за вас сценарий тестирования нарисовать и отвечать за правильно выбранный коэффициент при масштабировании системы?

В чём же тогда Ваша экспертиза заключается?

Тестирование не избежать при любом раскладе его или будут производить роботы, или живые пользователи. Многих проблем, с которыми пользователи столкнуться в первые дни работы системы, с помощь тестирования можно избежать, сделав шаг на опережение.

Тестирование можно осуществить в центре IBM. Там это очень давно практикуется. И оказывают хорошую поддержку и помощь в выборе оборудования. С другими производителями, например, HP дела сложнее.

Не всегда обязательно писать сценарий тестирования. Можно воспользоватся СНТ (стандартным нагрузочным тестом).

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

Тестирование заключается в правильном выборе оборудования. Выявлением проблем с производительностью с которыми могут столкнутся пользователи при работе.

Все, что я сказал относится к большим системам с большим количеством пользователей (>50 в одной ИБ) и/или работающих под высокой нагрузкой.

Проблемы: дэдлоки, ожидания на блокировках снизить, время проведения критичных документов очень длительное.
Я не говорил, что все оперативно можно решить. Но выявить и принять меры можно.

Лично я не часто. Если все вопросы достичь не удалось, то надо в др. месте спросить. Можно попробовать напрямую у 1С.

Я говорю про 50 пользователей и выше. Бывают такие системы, где пользователей еще меньше, а проблемы больше. Это просто такое приблизительное пограничное значение.

Если сомневаетесь в производительности будущей системы на 1С. То сейчас развивается такое направление как ЦКТП(центры корпоративной технологической поддержки). Где заключается 3-х сторонее соглашение заказчиком, фирмой исполнителем и 1С.
Т.е тем самым получаем доступ к разработчикам с гарантированным временем реакции. 1С оказывает методическую помощь.

И если такой 3-х сторонний договор заключили: то обязательным условием перед началом эксплуатации системы - это проведение нагрузочного тестирования. Это обязательный пункт.

AHDPЯ не понял, какие конкретно действия по результатам нагрузочного тестирования Вы предлагаете предпринять клиенту?

ЗЫ Вы нагрузочное тестирование проводите для выбора оборудования? Научите меня пожалуйста оборудованием лечить дедлоки. Вам за это очень большая часть посетителей этого форума спасибо скажет.

Причем здесь оборудованием лечить дедлоки. Я имею ввиду, нагрузочным тестированием можно выявить эти проблемы. А потом уже их устранять. Лечатся они не оборудованием, а исправлением кода в основном (определяем причину и лечим).

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

AHDPЯ правильно Вас понимаю, что на этапе нагрузочного тестирования, ПРОВЕДЁННОГО ЗА СЧЁТ Клиента, Вы будете выявлять архитектурные косяки в своём приложении (по русски говоря его переписывать, то же надо полагать за счёт клиента)? Вот это мне, как клиенту, и не нравится. Я ХОЧУ преобрести товар с ЗАВЕДОМО ИЗВЕСТНЫМ качеством реализации.

У каждого Вашего клиента свои особенные проблемы!? Или Вы не можете спрогназировать работоспособность своего творения?

Какие именно критерии вы используете при выдаче рекоемендаций по оборудованию?

Опять все утрируете. Нельзя написать УПП которое подойдет всем. Каждая корпоративная система уникальна. В каждой будут применяться свои изменения и доработки, которые нигде больше возможно и не встретятся.

Производительность это не разовое дело, за ней надо следить постоянно(мониторить).
Т.е. если куплена конфигурация на 1С и со временем(с ростом данных или количество пользователей увеличилось) она начала все медленнее работать (какие то отчеты стали медленнее выполнятся или проводится документы), то тот кто написал это должен был все это предусмотреть и теперь когда это выяснилось прийти и все бесплатно исправить.

timkaaAHDPЯ правильно Вас понимаю, что на этапе нагрузочного тестирования, ПРОВЕДЁННОГО ЗА СЧЁТ Клиента, Вы будете выявлять архитектурные косяки в своём приложении (по русски говоря его переписывать, то же надо полагать за счёт клиента)? Вот это мне, как клиенту, и не нравится. Я ХОЧУ преобрести товар с ЗАВЕДОМО ИЗВЕСТНЫМ качеством реализации.

У каждого Вашего клиента свои особенные проблемы!? Или Вы не можете спрогназировать работоспособность своего творения?

Какие именно критерии вы используете при выдаче рекоемендаций по оборудованию?

Опять все утрируете. Нельзя написать УПП которое подойдет всем. Каждая корпоративная система уникальна. В каждой будут применяться свои изменения и доработки, которые нигде больше возможно и не встретятся.

Производительность это не разовое дело, за ней надо следить постоянно(мониторить).
Т.е. если куплена конфигурация на 1С и со временем(с ростом данных или количество пользователей увеличилось) она начала все медленнее работать (какие то отчеты стали медленнее выполнятся или проводится документы), то тот кто написал это должен был все это предусмотреть и теперь когда это выяснилось прийти и все бесплатно исправить.

Знак вопроса забыл поставить:)

AHDPМы ушли от темы нагрузочного тестирования, за чем оно нужно и кто его будет оплачивать.
Вы выдвинули утверждение, что оно необходимо клиенту и он его должен оплачивать. Но кроме довода подстраховать себя от ошибок вендора, я от Вас аргументов не услышал.

Если это не укладывается в рамки описанной при внедрении масштабируемости системы - то это косяк вендоров, который придётся расхлёбывать предприятию самостоятельно. Хотя с моей подачи, и пересматривались алгоритмы формирования отчётов в некоторых "Совместимых" решениях.

ЗЫ Вы же не каждый раз всё пишите с нуля, при этом забыв всё с чем сталкивались до этого...

Считаю, что заказчик должен оплачивать, потому что система эта делается специально под него.

Если мы будем ждать, когда 1С напишет такое УПП которое всем подходит и все идеально, то можно смело менять работу. Оно его никогда не напишет. Его нельзя написать, чтобы всем предприятиям подходило и одинаково быстро работало при всех случаях.
У разных пользователей разные потребности, одним важно как можно больше и быстрее документов записать в базу, другим важна аналитика и т.д. Нужно найти какие-то способы помочь каждому(компромис).

Даже типовые конфигурации не идеальны. Но нельзя же ждать, когда 1С все исправит.