Тонкие клиенты
17.05.2006
16:03
#1
Работаем с 1С 7.7 бюджетная бухгалтерия. Сетевая Ос - Nowell NetWare 5.
Всего пользователей около 30, из них 16 пользователей вводят информацию, а остальные работают в режиме просмотра. Программа работает очень медленно.Нам предлагают перейти на тонкие клиенты, а может быть лучше перейти на SQL-версию?
Всего пользователей около 30, из них 16 пользователей вводят информацию, а остальные работают в режиме просмотра. Программа работает очень медленно.Нам предлагают перейти на тонкие клиенты, а может быть лучше перейти на SQL-версию?
17.05.2006
16:09
#2
1) SQL, обязательно с подделыванием стандартных отчетов (ну не оптимизированны они под SQL)
2) Сетевухи - гигабитки
3) Полноценный свич
2) Сетевухи - гигабитки
3) Полноценный свич
22.05.2006
15:51
#3
Правильно советуют.
Переход на терминал не требует SQL и от этого (SQL) работать ещё быстрее не станет
Особенно терминал полезен, если те 14 строят отчёты, или 16 сидят в одном журнале.
Переход на терминал не требует SQL и от этого (SQL) работать ещё быстрее не станет
Особенно терминал полезен, если те 14 строят отчёты, или 16 сидят в одном журнале.
23.05.2006
07:27
#5
Тут другая проблема может быть, при переходе на SQL.
У нас тоже примерно 30 пользователей, в терминале на DBF фсе работало очень быстро. Но была проблема, когда кто-нибудь начинал проводить что-нибудь очень объемное по количеству строк, то тормозили все.
Решили перейти на SQL и локально. Но быстродействие упало существенно, что в терминале, что на локальных машинах. Поэтому фик знает что лучше.
У нас тоже примерно 30 пользователей, в терминале на DBF фсе работало очень быстро. Но была проблема, когда кто-нибудь начинал проводить что-нибудь очень объемное по количеству строк, то тормозили все.
Решили перейти на SQL и локально. Но быстродействие упало существенно, что в терминале, что на локальных машинах. Поэтому фик знает что лучше.
23.05.2006
09:13
#6
"Это вы готовить их не умеете." (с)
SQL требует ВДУМЧИВОЙ и к р о п о т л и в о й настройки.
SQL требует ВДУМЧИВОЙ и к р о п о т л и в о й настройки.
29.05.2006
06:32
#7
Так может быть совместными усилиями составим руководство по настройке SQL для нормальной работы с 1С?
Скорее всего не один я столкнулся с такой проблемой, а более-менее удобоваримой инфы по этой теме нет.
Скорее всего не один я столкнулся с такой проблемой, а более-менее удобоваримой инфы по этой теме нет.
30.05.2006
06:22
#8
Во народ...
У меня в фирме около 40 компов работают с торговлей, причем переделанной процентов на 80.
выбор между sql и dbf - на 7.7 90% в пользу dbf.
Но только одно но - терминалка.
Т.к. по сетки даже когда два клиента работать тяжеловато.
Плюс главное подобрать нормальный сервак и базу поставить на scsi-диск убрать шифрование, индексация диска - это гуд.
Процессоры желательно с большей памятью 1 уровня ядра. Количество процессоров никак не влияет на скорость работы. Т.к. 1С занимает только один проц и под многопроцессорность никак не заточена. А в двухядерных процессах и то хуже - только одно ядро.
Фиг знает - ядро 1С не я писал. Единственный плюс количества процессоров - это то, что система будет меньше грузиться сервака и есть возможность запускать несколько различных 1С (баз) без потери производительности.
Добавлю еще, что вся 1С тормозит главным образом из-за корявости разработчиков. Т.к. язык запросов в программировании семерки абсолютно не оптимизирован и его обработка - 99% всего времени. Через выгрузки итогов и обработкой уже в таблицах значений время создавания отчета уменьшается в два-три раза.
И еще 1С с sql можно сказать работает как малолетний мальчик смотрит мультики по компьютеру. Видит видит - а сделать ничего не может. Проще говоря работает только с классическим sql от Майкрософта и то процентов на 5. Многие команды sql не воспринимает как таковых.
В процессе работы с sql-ем гоняет туда-сюда базы, вместо того, чтобы выполнять на самом сервере sql.
У меня в фирме около 40 компов работают с торговлей, причем переделанной процентов на 80.
выбор между sql и dbf - на 7.7 90% в пользу dbf.
Но только одно но - терминалка.
Т.к. по сетки даже когда два клиента работать тяжеловато.
Плюс главное подобрать нормальный сервак и базу поставить на scsi-диск убрать шифрование, индексация диска - это гуд.
Процессоры желательно с большей памятью 1 уровня ядра. Количество процессоров никак не влияет на скорость работы. Т.к. 1С занимает только один проц и под многопроцессорность никак не заточена. А в двухядерных процессах и то хуже - только одно ядро.
Фиг знает - ядро 1С не я писал. Единственный плюс количества процессоров - это то, что система будет меньше грузиться сервака и есть возможность запускать несколько различных 1С (баз) без потери производительности.
Добавлю еще, что вся 1С тормозит главным образом из-за корявости разработчиков. Т.к. язык запросов в программировании семерки абсолютно не оптимизирован и его обработка - 99% всего времени. Через выгрузки итогов и обработкой уже в таблицах значений время создавания отчета уменьшается в два-три раза.
И еще 1С с sql можно сказать работает как малолетний мальчик смотрит мультики по компьютеру. Видит видит - а сделать ничего не может. Проще говоря работает только с классическим sql от Майкрософта и то процентов на 5. Многие команды sql не воспринимает как таковых.
В процессе работы с sql-ем гоняет туда-сюда базы, вместо того, чтобы выполнять на самом сервере sql.
07.06.2006
18:32
#9
7.7 не предназначалась изначально для работы с SQL.
В случае с 7.5 и 7.7 SQL требуется для более стабильной работы базы данных (исключение поломок базы данных)
Повышение быстродействия отчетов - использование библиотеки типа ADSQL (прямой доступ к таблицам SQL)
Повышение быстродействия проведения документов - библиотека и переделка модуля под конкретную организацию (отрасль)
8.0 изначально разрабатывалась для работы под SQL и при работе с SQL генерит стандартные запрос ("SELECT ...")
Можно сказать, взаимодействие 7.7 и SQL - как встреча на Эльбе. Две абсолютно разные системы, но вот сдружились немного. И то хорошо.
Зато 8.0 - с SQL "на ты"
В случае с 7.5 и 7.7 SQL требуется для более стабильной работы базы данных (исключение поломок базы данных)
Повышение быстродействия отчетов - использование библиотеки типа ADSQL (прямой доступ к таблицам SQL)
Повышение быстродействия проведения документов - библиотека и переделка модуля под конкретную организацию (отрасль)
8.0 изначально разрабатывалась для работы под SQL и при работе с SQL генерит стандартные запрос ("SELECT ...")
Можно сказать, взаимодействие 7.7 и SQL - как встреча на Эльбе. Две абсолютно разные системы, но вот сдружились немного. И то хорошо.
Зато 8.0 - с SQL "на ты"
Читают тему
(гостей: 1)