1C+MSSQL медленнее обрабатывает запросы чем файловая?
Сабж.
Бьюсь второй день.
Сервер: 2 ксеона 2.40 Ггц, 36 ГБ оперативки, диски SAS в 1 рэйде.
База - 5 гигов.
Ось - Windows Server 2008R2
MSSQL 2008R2 10.50.1600.1
TEMP_DB вынесена на другой раздел.
В файловом варианте старт системы происходит за 3 секунды.
Поставил MSSQL - старт - 18 секунд.
Перестраивал индексы, дефрагментировал, перестаивал статистику, очищал процедурный кеш, дал Скулю 20 гигов опреативки, игрался с настройками базы - прироста производительности нет...
По замеру производительности (1С) много времени занимают такие запросы:
Результат = Запрос.Выполнить();
По идее, это операции считывания/записи жеж.
Почему так сильно упала скорость работы?
Бьюсь второй день.
Сервер: 2 ксеона 2.40 Ггц, 36 ГБ оперативки, диски SAS в 1 рэйде.
База - 5 гигов.
Ось - Windows Server 2008R2
MSSQL 2008R2 10.50.1600.1
TEMP_DB вынесена на другой раздел.
В файловом варианте старт системы происходит за 3 секунды.
Поставил MSSQL - старт - 18 секунд.
Перестраивал индексы, дефрагментировал, перестаивал статистику, очищал процедурный кеш, дал Скулю 20 гигов опреативки, игрался с настройками базы - прироста производительности нет...
По замеру производительности (1С) много времени занимают такие запросы:
Результат = Запрос.Выполнить();
По идее, это операции считывания/записи жеж.
Почему так сильно упала скорость работы?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Snifer, мы всем предлагаем воспользоваться бесплатным сервисом , который поможет оценить проблему и ответить на ваш вопрос:
Собранный план запроса скорее всего раскроет все тайны :)
Вы также можете воспользоваться бесплатно нашей помощью на нашем форуме , который мы открыли на этой неделе.
По замеру производительности (1С) много времени занимают такие запросы:
Результат = Запрос.Выполнить();
По идее, это операции считывания/записи жеж.
Почему так сильно упала скорость работы?
Результат = Запрос.Выполнить();
По идее, это операции считывания/записи жеж.
Почему так сильно упала скорость работы?
Собранный план запроса скорее всего раскроет все тайны :)
Вы также можете воспользоваться бесплатно нашей помощью на нашем форуме , который мы открыли на этой неделе.
(1)
Алексей (Snifer).
Посмотрите эту публикацию:
P.S.
Характеристика системы словами "2 ксеона 2.40 Ггц"(с) ничего не говорит.
"Xeon (произносится: Зион, а в русской транслитерации как Ксеон) — линейка серверных микропроцессоров производства Intel. Название остаётся неизменным для нескольких поколений процессоров."(с)
Очень разная у них производительность на НАШИХ задачах.
Алексей (Snifer).
Посмотрите эту публикацию:
P.S.
Характеристика системы словами "2 ксеона 2.40 Ггц"(с) ничего не говорит.
"Xeon (произносится: Зион, а в русской транслитерации как Ксеон) — линейка серверных микропроцессоров производства Intel. Название остаётся неизменным для нескольких поколений процессоров."(с)
Очень разная у них производительность на НАШИХ задачах.
старт системы не показатель работы в скорости, чтоб грузилась быстро нужно на SSD системный диск переводить. SQL-ная в обработке запросов быстрее и формировании ответа клиенту. Дело может в RAID контроллере быть попробуйте без него с одним винтом!
Режим работы: 8х5
Проверяем на том же железе.
Платформа: 1С:Предприятие 8.2 (8.2.16.368)
Конфа: Бухгалтерия предприятия, редакция 2.0 (2.0.42.6)
Ставили 173 платформу - то же самое.
Своп и TEMP_DB вынесены на отдельное зеркало.
Проверяем на том же железе.
Платформа: 1С:Предприятие 8.2 (8.2.16.368)
Конфа: Бухгалтерия предприятия, редакция 2.0 (2.0.42.6)
Ставили 173 платформу - то же самое.
Своп и TEMP_DB вынесены на отдельное зеркало.
еще советуют обновление статистики в базе SQL отключать, можно базу SQL в режим Simple перевести, чтоб логи не писало...
да что вы все к бедным логам SQL привязались?!
Эти режимы влияют на способ восстановления базы.
И Simple и Full делают транкэйт журнала транзакций, только в разное время и отражают состояние операций: при Simple режиме невозможно восстановить впоследствии текущие операции, если случится авария, т.к. он не резервирует журнал транзакций.
Поэтому если не критично - используют режим Simple.
Не у тех учителей учитесь.
(11) amadeus2011,
Это показал нам ЦУП
молодцы, купили дорогую и бесполезную игрушку.
(8) dedtver,
тест Гилева запусти
вам как - результат нужен или попугаев мерять по неизвестным даже автору методикам?
(17) Snifer,
у вас очень много на одном сервере всего.
Скорей всего, тормозит не SQL, а 1С.
Хотя, если SQL не хватит памяти - будет тоже тормозить (т.к. у идеальный случай, когда "размер базы >= размер ОЗУ", т.к. возможно - теоретически, - что вся база загрузится в память).
Rphost ест очень много (особенно сейчас - на 8.2).
У вас наверняка 1С 32-хбитная - следовательно, её процессам-rphost'ам не хватает памяти.
Разделите на несколько процессов.
Если драться за ресурсы (память, диск, процессорное время) не будут между собой (да плюс еще терминалы будут память отъедать) - то оставляйте на одном, если будут - разделяйте на два/добавляйте памяти/переходите на 1С 64 разряда.
20 под SQL, 4 под систему, 10 под терминальные процессы и rphost.
у вас очень много на одном сервере всего.
Скорей всего, тормозит не SQL, а 1С.
Хотя, если SQL не хватит памяти - будет тоже тормозить (т.к. у идеальный случай, когда "размер базы >= размер ОЗУ", т.к. возможно - теоретически, - что вся база загрузится в память).
Rphost ест очень много (особенно сейчас - на 8.2).
У вас наверняка 1С 32-хбитная - следовательно, её процессам-rphost'ам не хватает памяти.
Разделите на несколько процессов.
Если драться за ресурсы (память, диск, процессорное время) не будут между собой (да плюс еще терминалы будут память отъедать) - то оставляйте на одном, если будут - разделяйте на два/добавляйте памяти/переходите на 1С 64 разряда.
(19) AlexO,
Да, процессы промониторить могу.
Дело в том, что оперативка загружена на 30% а процессор на 15-20%.
И это при работающих 20 пользователях.
Какое направление вы указали? Добавить оперативки/процессор/SSD-Raid0?
Или перейти на х64?
На втором сервере с MSSQL крутится только WSUS.
Замеры производительности (штатные 1С) показывают различие по времени:
Файловая база - выполнение запроса: 0,4 секунды
MSSQL локальная - 2,3 секунды.
MSSQL удаленная - 2,3 секунды.
Запрос - одинаковый.
Да, процессы промониторить могу.
Дело в том, что оперативка загружена на 30% а процессор на 15-20%.
И это при работающих 20 пользователях.
Какое направление вы указали? Добавить оперативки/процессор/SSD-Raid0?
Или перейти на х64?
На втором сервере с MSSQL крутится только WSUS.
Замеры производительности (штатные 1С) показывают различие по времени:
Файловая база - выполнение запроса: 0,4 секунды
MSSQL локальная - 2,3 секунды.
MSSQL удаленная - 2,3 секунды.
Запрос - одинаковый.
(22) Snifer,
в принципе - обо всех :)
Может, у вас кроме 1С еще чего там не дает работать :)
А более узко - о процессах 1С-сервера и SQL-сервера. Кто из них создает у вас "тормоза" при выполнении запроса по сравнению с файловым вариантом?
О процессах программ или об операциях, выполняемых в процессе запуска и работы 1С?
в принципе - обо всех :)
Может, у вас кроме 1С еще чего там не дает работать :)
А более узко - о процессах 1С-сервера и SQL-сервера. Кто из них создает у вас "тормоза" при выполнении запроса по сравнению с файловым вариантом?
(25) Snifer,
я не вижу ваших скринов - данный файлообменник "закрыт".
это вы сравниваете файловую и серверную базы. А не я. Мне-то давно известны проблемы и нищета обоих вариантов.
И вы не знаете, как сравнить два процесса по времени их активности в диспетчере задач? Или в более удобном мониторе, с логгированием.
Так активность какого из процессов данных двух серверов занимает большую часть из времени ваших так называемых "тормозов при исполнении запроса"? Уже и не знаю, как вам еще по-другому вопрос сформулировать :)
я не вижу ваших скринов - данный файлообменник "закрыт".
Как вы себе представляете сравнение серверных процессов rphost и sqlsrv с файловой БД?
это вы сравниваете файловую и серверную базы. А не я. Мне-то давно известны проблемы и нищета обоих вариантов.
И вы не знаете, как сравнить два процесса по времени их активности в диспетчере задач? Или в более удобном мониторе, с логгированием.
Из вышеприведенного скрина видно, что не тормозит ничего.
Так активность какого из процессов данных двух серверов занимает большую часть из времени ваших так называемых "тормозов при исполнении запроса"? Уже и не знаю, как вам еще по-другому вопрос сформулировать :)
(22) Snifer,
берете и смотрите (лучше на более длительном запросе), где-у какого рабочего процесса (1С или SQL) более длительное время использования процессорного (или ОЗУ) времени.
Делаете выводы - кто из двух серверов "тормозит".
О процессах программ или об операциях
берете и смотрите (лучше на более длительном запросе), где-у какого рабочего процесса (1С или SQL) более длительное время использования процессорного (или ОЗУ) времени.
Делаете выводы - кто из двух серверов "тормозит".
это вы сравниваете файловую и серверную базы. А не я.
Кто из них создает у вас "тормоза" при выполнении запроса по сравнению с файловым вариантом?
бОльшую нагрузку создает процесс rphost. Но не на столько бОльшую, чтобы было троекратное падение в производительности относительно файловой базы.
Кстати, в потугах наткнулся на статейку на Тэчнете:
(27) Snifer,
это известные проблемы сетевого взаимодействия 1С в новых Windows с новыми SQL.
Причем вот так, нарастание падения слева-направо:
SQL2005 -> SQL2008 -> SQL2012
Windows2003 -> Windows2008 -> Windows2012
Т.е. самые "левые" SQL и Windows - берутся за точку отсчета (за "максимальную" производительность). Остальные "варианты" Windows-SQL - чем правее вариант, тем увеличение падения вплоть до 5-20%.
Видимо, сетевая модель 1С так и осталась на уровнеподелки версии 8.0 (несмотря на якобы "мы всю платформу переписали в 8.2"), а Microsoft поменяла свои "приоритеты" в работе серверов.
Ну вот и результат.
А вот ответ специалиста Гилева:
"а не хотите просто юзать Win2003 + SQL 2005?"
Собственно, мы примерно такой же вариант ("ставьте более мощный сервер") и получили в ответ, когда стал дико тормозить 1С сервер на пустом месте.
Ну, т.е., я тоже хочу давать подобные "советы", причем за более умеренную плату :)
Кстати, в потугах наткнулся на статейку на Тэчнете:
это известные проблемы сетевого взаимодействия 1С в новых Windows с новыми SQL.
Причем вот так, нарастание падения слева-направо:
SQL2005 -> SQL2008 -> SQL2012
Windows2003 -> Windows2008 -> Windows2012
Т.е. самые "левые" SQL и Windows - берутся за точку отсчета (за "максимальную" производительность). Остальные "варианты" Windows-SQL - чем правее вариант, тем увеличение падения вплоть до 5-20%.
Видимо, сетевая модель 1С так и осталась на уровне
Ну вот и результат.
А вот ответ специалиста Гилева:
"а не хотите просто юзать Win2003 + SQL 2005?"
Собственно, мы примерно такой же вариант ("ставьте более мощный сервер") и получили в ответ, когда стал дико тормозить 1С сервер на пустом месте.
Ну, т.е., я тоже хочу давать подобные "советы", причем за более умеренную плату :)
(28)А вот ответ специалиста Гилева:
"а не хотите просто юзать Win2003 + SQL 2005?"
Собственно, мы примерно такой же вариант ("ставьте более мощный сервер") и получили в ответ, когда стал дико тормозить 1С сервер на пустом месте.
+ До сих пор, методом проб и грабель, использую связку Win2003 + SQL2008. И кстати, согласен с отсылом к 1С. Скуль жаден до оперативки, а вот rphost-ы, потребляя всего по 500 метров памяти на брата, грузят как раз процессор. особенно, если на сервере 1С работает более 5 баз.
"а не хотите просто юзать Win2003 + SQL 2005?"
Собственно, мы примерно такой же вариант ("ставьте более мощный сервер") и получили в ответ, когда стал дико тормозить 1С сервер на пустом месте.
+ До сих пор, методом проб и грабель, использую связку Win2003 + SQL2008. И кстати, согласен с отсылом к 1С. Скуль жаден до оперативки, а вот rphost-ы, потребляя всего по 500 метров памяти на брата, грузят как раз процессор. особенно, если на сервере 1С работает более 5 баз.
(32) Motor24,
это вы мне как контраргумент или что? :)
В первом случае - да, я знаю, что такая связка работоспособна, никто не говорит, что "не заработает".
Речь идет о потерях производительности по отношению к связкам "первых" версий.
До сих пор, методом проб и грабель, использую связку Win2003 + SQL2008
это вы мне как контраргумент или что? :)
В первом случае - да, я знаю, что такая связка работоспособна, никто не говорит, что "не заработает".
Речь идет о потерях производительности по отношению к связкам "первых" версий.
(32) Motor24,
Вы описываете известное заблуждение новый более дорогой сервер = более мощный сервер. Мы несем ответственность за "мощный" сервер, если он покупается у нас, настраивается нами и мы курируем работу хотя бы в начале эксплуатации. Мы готовы демонстрировать заказчику нагрузочным тестированием, что сервер который он собирается купить реально повышает производительность 1С. Тест может быть и синтетический, и модулировать деятельность его компании - в последнем случаи речь идет о нагрузочном тестировании с целью дополнительных гарантий. Мы также предлагаем нашим заказчикам нашу ответственность деньгами, если сервер не улучшит производительность как дополнительную гарантию. В привате мы можем назвать клиентов, которым мы подобрали оборудование и они нас могут рекомендовать.
28)А вот ответ специалиста Гилева:
"а не хотите просто юзать Win2003 + SQL 2005?"
Собственно, мы примерно такой же вариант ("ставьте более мощный сервер") и получили в ответ, когда стал дико тормозить 1С сервер на пустом месте.
+ До сих пор, методом проб и грабель, использую связку Win2003 + SQL2008. И кстати, согласен с отсылом к 1С. Скуль жаден до оперативки, а вот rphost-ы, потребляя всего по 500 метров памяти на брата, грузят как раз процессор. особенно, если на сервере 1С работает более 5 баз.
"а не хотите просто юзать Win2003 + SQL 2005?"
Собственно, мы примерно такой же вариант ("ставьте более мощный сервер") и получили в ответ, когда стал дико тормозить 1С сервер на пустом месте.
+ До сих пор, методом проб и грабель, использую связку Win2003 + SQL2008. И кстати, согласен с отсылом к 1С. Скуль жаден до оперативки, а вот rphost-ы, потребляя всего по 500 метров памяти на брата, грузят как раз процессор. особенно, если на сервере 1С работает более 5 баз.
Вы описываете известное заблуждение новый более дорогой сервер = более мощный сервер. Мы несем ответственность за "мощный" сервер, если он покупается у нас, настраивается нами и мы курируем работу хотя бы в начале эксплуатации. Мы готовы демонстрировать заказчику нагрузочным тестированием, что сервер который он собирается купить реально повышает производительность 1С. Тест может быть и синтетический, и модулировать деятельность его компании - в последнем случаи речь идет о нагрузочном тестировании с целью дополнительных гарантий. Мы также предлагаем нашим заказчикам нашу ответственность деньгами, если сервер не улучшит производительность как дополнительную гарантию. В привате мы можем назвать клиентов, которым мы подобрали оборудование и они нас могут рекомендовать.
(28) Уважаемый AlexO,
Мы того не могли говорить. Наша позиция по этому вопрос официально изложена на сайте .
Если хотите улучшить производительность, то обратитесь к нам, мы решим все проблемы с производительностью.
А вот ответ специалиста Гилева:
"а не хотите просто юзать Win2003 + SQL 2005?"
Собственно, мы примерно такой же вариант ("ставьте более мощный сервер") и получили в ответ, когда стал дико тормозить 1С сервер на пустом месте.
Ну, т.е., я тоже хочу давать подобные "советы", причем за более умеренную плату :)
"а не хотите просто юзать Win2003 + SQL 2005?"
Собственно, мы примерно такой же вариант ("ставьте более мощный сервер") и получили в ответ, когда стал дико тормозить 1С сервер на пустом месте.
Ну, т.е., я тоже хочу давать подобные "советы", причем за более умеренную плату :)
Мы того не могли говорить. Наша позиция по этому вопрос официально изложена на сайте .
Если хотите улучшить производительность, то обратитесь к нам, мы решим все проблемы с производительностью.
(27) Snifer,
но опять же, к вам это отношения не имеет - вы ж не разные версии SQL сравниваете.
1С и SQL - эта связка не для производительности, как таковой, "придумана".
А для повышения отказоустойчивости, улучшения администрирования базы, уменьшения количества налагаемых блокировок, увеличение размера собственно таблиц базы и т.д. - т.е. то, в чем 1С сразу поняла тред: это ей не потянуть...
Хотя многие тру-1сники и до сих пор не знают о проблемах и причинах симбиоза 1С и SQL.
Кстати, в потугах наткнулся на статейку на Тэчнете:
но опять же, к вам это отношения не имеет - вы ж не разные версии SQL сравниваете.
1С и SQL - эта связка не для производительности, как таковой, "придумана".
А для повышения отказоустойчивости, улучшения администрирования базы, уменьшения количества налагаемых блокировок, увеличение размера собственно таблиц базы и т.д. - т.е. то, в чем 1С сразу поняла тред: это ей не потянуть...
Хотя многие тру-1сники и до сих пор не знают о проблемах и причинах симбиоза 1С и SQL.
(33) Snifer,
ну да, например, в случаях:
- когда 1С сервер не "убирается" в рамках одного сервера;
- когда много deadlock'ов в базе, которые продыху не дают пользователям (точнее, вынуждают их гонять чаи вместо работы в ожиданиях завершения операции);
- когда пользователей over 10, и все активничают в базе;
- когда данные намного более ценны, чем стоимость сервера SQL и т.д.
Т.е. это очередное стандартное лукавство (или незнание - тут уже трудно сказать) 1сников.
Дык в том то и дело, что манагеры нам впаривали это по причинам "повышения производительности".
ну да, например, в случаях:
- когда 1С сервер не "убирается" в рамках одного сервера;
- когда много deadlock'ов в базе, которые продыху не дают пользователям (точнее, вынуждают их гонять чаи вместо работы в ожиданиях завершения операции);
- когда пользователей over 10, и все активничают в базе;
- когда данные намного более ценны, чем стоимость сервера SQL и т.д.
Т.е. это очередное стандартное лукавство (или незнание - тут уже трудно сказать) 1сников.
во первых, SQL используют не для ускорения а для приведения структуры к варианту клиент-сервер и увеличения количества подключаемых клиентов и одновременно обрабатываемых запросов.
во вторых, для обеспечения быстродействия нужна хорошая дисковая подстсема и достаточный объем оперативной памяти на SQL сервере, а вместе с тем нужна корректная оптимизация базы и тяжелейшая работы с блокировками.
франчайзинг просто впарил вам дорогое решение. на файловой базе можно сидеть до 20 клиентов, работать она бедет не медленнее чем SQL если не нагружать аналитическими отчетами, да и база базе рознь.
во вторых, для обеспечения быстродействия нужна хорошая дисковая подстсема и достаточный объем оперативной памяти на SQL сервере, а вместе с тем нужна корректная оптимизация базы и тяжелейшая работы с блокировками.
франчайзинг просто впарил вам дорогое решение. на файловой базе можно сидеть до 20 клиентов, работать она бедет не медленнее чем SQL если не нагружать аналитическими отчетами, да и база базе рознь.
Да, это уже понятно. Но мы в "отместку" дошли до руководства "впаривателей" и завтра они к нам отправляют специалиста.
До этого по удаленке они посмотрели, сказали что все нормально настроено. Не понимают они кароч, почему такое падение производительности. Поэтому пришлют завтра спеца...
До этого по удаленке они посмотрели, сказали что все нормально настроено. Не понимают они кароч, почему такое падение производительности. Поэтому пришлют завтра спеца...
Специалист просидел 5 часов, покопался в стандартной конфигурации, сделал несколько звонков более продвинутым гуру, сказал что со стороны 1С все в порядке, выписал счет на оплату и уехал.
Сказал что все должно работать нормально, но почему-то не работает...
Предложил обратиться к ним в отдел "производительности", за круглую сумму денег они сделают нам тест.
До этого из их же компании подключались по удаленке, тестировали железо и настройки MSSQL, сказали что тоже все в порядке...
Сегодня с утра дали конфу для теста товарищу, он произвел замеры, у него в 2.5 раза быстрее работает SQL чем у нас.
Различия по железу только в процахи хардах, у нас 2хЕ5-2609, у него 1хE3-1270 и SATA диски в зеркале (У нас SAS).
Непонятная ситуация...
Сказал что все должно работать нормально, но почему-то не работает...
Предложил обратиться к ним в отдел "производительности", за круглую сумму денег они сделают нам тест.
До этого из их же компании подключались по удаленке, тестировали железо и настройки MSSQL, сказали что тоже все в порядке...
Сегодня с утра дали конфу для теста товарищу, он произвел замеры, у него в 2.5 раза быстрее работает SQL чем у нас.
Различия по железу только в процахи хардах, у нас 2хЕ5-2609, у него 1хE3-1270 и SATA диски в зеркале (У нас SAS).
Непонятная ситуация...
(45) Snifer,
Вы серьезно?
Ваш процессор выдает 2.4 GHz, у вашего соседа 3.8 Ghz больше чем на гигагерц. А частота процессора оказывает ключевое влияние на общую производительность.
Различия по железу только в процахи хардах, у нас 2хЕ5-2609, у него 1хE3-1270 и SATA диски в зеркале (У нас SAS).
Непонятная ситуация...
Непонятная ситуация...
Вы серьезно?
Ваш процессор выдает 2.4 GHz, у вашего соседа 3.8 Ghz больше чем на гигагерц. А частота процессора оказывает ключевое влияние на общую производительность.
Вам необходимо обратиться к специалисту по настройке SQL сервера.
У нас была похожая ситуация правда с PostgreeSQl - База работала в разы медленнее файлового варианта.
После настройки работа сервера кардинально поменялась.
Отчет вместо 6 минут стал формироваться в течении 2-3 секунд. Также посоветую посмотреть в SQL Profiler на простейшем отчете посмотреть как 1С преобразует Запрос в SQL запрос.
Также запуск Сервера 1С в режиме отладки может тормозить работу.
У нас была похожая ситуация правда с PostgreeSQl - База работала в разы медленнее файлового варианта.
После настройки работа сервера кардинально поменялась.
Отчет вместо 6 минут стал формироваться в течении 2-3 секунд. Также посоветую посмотреть в SQL Profiler на простейшем отчете посмотреть как 1С преобразует Запрос в SQL запрос.
Также запуск Сервера 1С в режиме отладки может тормозить работу.
Посмотрите в таком случае запросы SQL , и план их выполнения. Возможно это поможет решить проблему. У меня сервер похож на ваш процы только 2.8 база упп 17 гигов. памяти 32. активных пользователей до 30.
тормозов особых не наблюдается.
тормозов особых не наблюдается.
(48) slimmaster,
Зачем? Вы хотите сказать, что сервер выбирает неоптимальный план выполнения?
Конфа стандартная, не переписаная. Соответственно, она должна работать в фаловом и SQL варианте с примерно одинаковой производительностью. (мы согласны уже и на падение производительности в 2 раза, но не в 4!), к тому же, как тогда объяснить что у товарища эта же конфигурация работает в 2.5 раза быстрее чем у нас на более "слабом" железе?
У нас с ним даже билды софта одинаковые.
Зачем? Вы хотите сказать, что сервер выбирает неоптимальный план выполнения?
Конфа стандартная, не переписаная. Соответственно, она должна работать в фаловом и SQL варианте с примерно одинаковой производительностью. (мы согласны уже и на падение производительности в 2 раза, но не в 4!), к тому же, как тогда объяснить что у товарища эта же конфигурация работает в 2.5 раза быстрее чем у нас на более "слабом" железе?
У нас с ним даже билды софта одинаковые.
(51) Snifer, да я допускаю такой вариант (неоптимальный план выполнения). Попробуйте создать самый простой запрос (Не отчет!!!) Посмотрите время и план его выполнения у себя и у вашего друга (там где ваша база работает в 2 раза быстрее). Если на вашем сервере работает медленнее, то скорее всего виноваты настройка именно SQL либо есть проблемы с дисковыми массивами.
у вас и 1с и SQL х64?
у вас и 1с и SQL х64?
Сам недавно задавался этим вопросом вот что нарыл в инете:
Первое, что необходимо понять и запомнить: SQL-системы не предназначены для ускорения выполнения выборок и печати отчетов. Если Вы ожидаете, что установив "1C-Торговлю для SQL" Вы ускорите работу своей системы, то Вы глубоко заблуждаетесь. Не будет она работать быстрее. Поэтому всякие разговоры о том, что "…SQL-Торговля - это тормоз…" абсолютно не имеют смысла. Несколько лет назад журнал PC Magazine проводил сравнительный анализ (в том числе и по быстродействию) систем управления базами данных, построенных на основе обычных файл серверов и с использованием клиент-серверных (SQL) систем. Естественно, условия испытаний по возможности были нивелированы, т.е. применялись одинаковые объемы баз данных, одинаковые их структуры, один и тот же компьютер в качестве сервера, одинаковое количество рабочих станций и т.д. Если мне не изменяет память, из клиент-серверных систем были испытаны Oracle, Interbase, Informix, Gupta и самый дешевый в то время Watcom SQL Server. Во всех случаях, средняя скорость выполнения запросов в SQL-системах была ниже, чем у файл-серверной системы (сейчас об этом эффекте можно прочесть в любой серьезной книге по SQL ). Испытатели не были удивлены полученным эффектом, поскольку были людьми грамотными и понимали причину такого поведения SQL-систем при заданных условиях эксперимента. Ведь задачей эксперимента было сравнение быстродействия двух видов систем и поэтому были выбраны условия, позволяющие произвести это сравнение. В частности для тестов использовались базы данных объемом 1.5-2Гб. Ведь если бы исследователи взялись проводить испытания, используя базы данных на порядок большего размера, то им просто не с чем было бы сравнивать SQL-варианты, поскольку обычная файл-серверная система на таких объемах информации просто заткнулась бы.
Первое, что необходимо понять и запомнить: SQL-системы не предназначены для ускорения выполнения выборок и печати отчетов. Если Вы ожидаете, что установив "1C-Торговлю для SQL" Вы ускорите работу своей системы, то Вы глубоко заблуждаетесь. Не будет она работать быстрее. Поэтому всякие разговоры о том, что "…SQL-Торговля - это тормоз…" абсолютно не имеют смысла. Несколько лет назад журнал PC Magazine проводил сравнительный анализ (в том числе и по быстродействию) систем управления базами данных, построенных на основе обычных файл серверов и с использованием клиент-серверных (SQL) систем. Естественно, условия испытаний по возможности были нивелированы, т.е. применялись одинаковые объемы баз данных, одинаковые их структуры, один и тот же компьютер в качестве сервера, одинаковое количество рабочих станций и т.д. Если мне не изменяет память, из клиент-серверных систем были испытаны Oracle, Interbase, Informix, Gupta и самый дешевый в то время Watcom SQL Server. Во всех случаях, средняя скорость выполнения запросов в SQL-системах была ниже, чем у файл-серверной системы (сейчас об этом эффекте можно прочесть в любой серьезной книге по SQL ). Испытатели не были удивлены полученным эффектом, поскольку были людьми грамотными и понимали причину такого поведения SQL-систем при заданных условиях эксперимента. Ведь задачей эксперимента было сравнение быстродействия двух видов систем и поэтому были выбраны условия, позволяющие произвести это сравнение. В частности для тестов использовались базы данных объемом 1.5-2Гб. Ведь если бы исследователи взялись проводить испытания, используя базы данных на порядок большего размера, то им просто не с чем было бы сравнивать SQL-варианты, поскольку обычная файл-серверная система на таких объемах информации просто заткнулась бы.
Вот в этом то и состоит основное отличие и достоинство клиент-серверных систем: они будут работать со вполне приемлемой скоростью с базами данных такого объема, с которыми файл-серверная система работать просто не сможет ("не сможет" в том смысле, что ее функциональность, в том числе и быстродействие, станут неприемлемы для коммерческих приложений).
У меня SQL версия работает в раза 3 быстрее, чем файловая. Загружается от 5 до 10 секунд. Не замерял специально. Короче с переходом на SQL выигрышь в производительности был колосальный.
Короче:
Пользователей 30.
Размер базы 1.2 Гигабайта.
ОC на сервере 1С (32бит) - Windows 2008 4 процессора, 24 ядра. 32 гига памяти.
Непосредственно на самом сервере работа разделена на 3 процесса.
SQL база лежит на Hyper-V с 6 гигами памяти и 4 ядрами.
Версия SQL - 10.
Пробовал работать и с Oracle. Но честно какой-либо разницы не заметил. Но с ним глюков не счесть.
Короче:
Пользователей 30.
Размер базы 1.2 Гигабайта.
ОC на сервере 1С (32бит) - Windows 2008 4 процессора, 24 ядра. 32 гига памяти.
Непосредственно на самом сервере работа разделена на 3 процесса.
SQL база лежит на Hyper-V с 6 гигами памяти и 4 ядрами.
Версия SQL - 10.
Пробовал работать и с Oracle. Но честно какой-либо разницы не заметил. Но с ним глюков не счесть.
Сейчас сообщить не могу. Но честно я даже не представляю, как у вас с такой базой файловая получается быстрее SQL на лицо тормоза либо сервера 1С либо SQL. Ибо файловая гоняет бешенный трафик по сети. Перегружая, жесткий диск и сеть. У нас страшные тормоза начались сразу, как людей в 1С8.2 стало работать больше 10 (хотя сеть у нас гигабитная и на сервере стоит сасовский рейд).
В понедельник поспрашиваю у админа точные версии и билды софта, отпишу.
В понедельник поспрашиваю у админа точные версии и билды софта, отпишу.
Знаете в чем разница между тем что я пишу и большинством на этом форуме в вопросах производительности? Мне не интересно флудить и расчитываю с минимальными усилиями (а по принципу Парето 20 на 80) максимально эффективно решить вопрос. Я уже в этой теме и так слишком много букв написал :).
Есть такая теория горлышковых мест. Для 1С она начинается с частоты процессора. Ферштейн? :)
А частота процессора оказывает ключевое влияние на общую производительность.
Есть такая теория горлышковых мест. Для 1С она начинается с частоты процессора. Ферштейн? :)
Нет, я нисколько не сомневаюсь в ваших знаниях.
Просто вы действительно считаете, что различие в 4 раза между файловой и SQL базой на этом процессоре - нормально?
Вопрос топика не в том, что база медленно работает, вопрос, почему такой провал в производительности SQL в сравнении с файловым вариантом? И почему у второго тестера эта разница всего лишь в 1.5 раза?
Просто вы действительно считаете, что различие в 4 раза между файловой и SQL базой на этом процессоре - нормально?
Вопрос топика не в том, что база медленно работает, вопрос, почему такой провал в производительности SQL в сравнении с файловым вариантом? И почему у второго тестера эта разница всего лишь в 1.5 раза?
Что я считаю не важно. Важно от слов переходить к делу. От того что мы обсудим здесь ничего не произойдет. Вопрос топика содержит скрытый вопрос - как решать проблему запросов в клиент-серверном варианте. Ведь вы же не будете использовать файловый вариант, так какой смысл это обсуждать.
Либо ставьте проц E5-2687W (у него 150 ват, не все сервера тянут) или бюджетный E5-2643.
Либо показывайте медленный код, будем не железо а код оптимизировать под имеющееся железо. Но в любом случаи нужен бюджет. Без бюджета это все болтовня имхо.
Либо ставьте проц E5-2687W (у него 150 ват, не все сервера тянут) или бюджетный E5-2643.
Либо показывайте медленный код, будем не железо а код оптимизировать под имеющееся железо. Но в любом случаи нужен бюджет. Без бюджета это все болтовня имхо.
(70) gilv, У товарища не 3.8 Ghz, а 3.4
я не понимаю почему вы решили, что у меня узкое место - процессор.
Загрузки на процессорах нет. Замеры производились на продакшн сервере, на котором в данный момент работали около 30 пользователей с файловым вариантом. Эти же замеры производились ночью, после ребута сервера, когда пользователей не было вообще - результаты те же.
Медленный запрос... хм... На самом деле, такое ощущение, что вы не читали топик.
Я уже писал о том, что замеры делались при старте 1С.
Запросы стандартные, конфигурация стандартная - Бухгалтерия 2.
Такое падение на всех запросах.
Если мы сейчас перепишем все стандартные! запросы под нас - мы будем при каждом обновлении ночевать на работе?
Переписывание запросов - это самый последний шаг.
я не понимаю почему вы решили, что у меня узкое место - процессор.
Загрузки на процессорах нет. Замеры производились на продакшн сервере, на котором в данный момент работали около 30 пользователей с файловым вариантом. Эти же замеры производились ночью, после ребута сервера, когда пользователей не было вообще - результаты те же.
Медленный запрос... хм... На самом деле, такое ощущение, что вы не читали топик.
Я уже писал о том, что замеры делались при старте 1С.
Запросы стандартные, конфигурация стандартная - Бухгалтерия 2.
Такое падение на всех запросах.
Если мы сейчас перепишем все стандартные! запросы под нас - мы будем при каждом обновлении ночевать на работе?
Переписывание запросов - это самый последний шаг.
(74) gilv, У него не включен Turbo Boost, процессор работает на частоте 3.4Ггц.
(76) gilv, Процессор, который вы предложили - 2.7Ghz... Будет ли прирост производительности?
(77) gilv, замеры приводил где-то выше. На вскидку - перепроведение месяца на файловой базе - 16 минут, на SQL - 47 минут.
Затык именно в запросах.
(76) gilv, Процессор, который вы предложили - 2.7Ghz... Будет ли прирост производительности?
(77) gilv, замеры приводил где-то выше. На вскидку - перепроведение месяца на файловой базе - 16 минут, на SQL - 47 минут.
Затык именно в запросах.
(78)
Алексей (Snifer).
Дал Вам ссылку в (72) сообщении.
Даю еще одну:
Прочтите, пожалуйста. Там есть ответы на ВСЕ ваши вопросы/сомнения.
P.S.
"на файловой базе - 16 минут, на SQL - 47 минут. "(с)
Это НОРМАЛЬНО.
Хотя, настройками ОС-а и железа возможно поднять скорость в SQL-ной версии.
Но, эти настройки поднимут и скорость файловой версии. ;-)
Алексей (Snifer).
Дал Вам ссылку в (72) сообщении.
Даю еще одну:
Прочтите, пожалуйста. Там есть ответы на ВСЕ ваши вопросы/сомнения.
P.S.
"на файловой базе - 16 минут, на SQL - 47 минут. "(с)
Это НОРМАЛЬНО.
Хотя, настройками ОС-а и железа возможно поднять скорость в SQL-ной версии.
Но, эти настройки поднимут и скорость файловой версии. ;-)
(78) Snifer,
чета не верится, покажите скриншот
(76)
E5-2643 в турбобусте 3.5 GHz
Еще раз говорю, разница между моими рекомендациями и других оппонентов колосальная. Они на 95% говорят фантазаии и домыслы. Ну вот hogik можно в эту статистику не брать :)
Если Вы прочитали статью , то там вроде на Ваши вопросы все данны. Вывод - Вы не читали или не хотите читать.
(74) gilv, У него не включен Turbo Boost, процессор работает на частоте 3.4Ггц.
чета не верится, покажите скриншот
(76)
gilv, Процессор, который вы предложили - 2.7Ghz... Будет ли прирост производительности?
Вы как читаете? Читаете ли?!!
E5-2643 в турбобусте 3.5 GHz
Еще раз говорю, разница между моими рекомендациями и других оппонентов колосальная. Они на 95% говорят фантазаии и домыслы. Ну вот hogik можно в эту статистику не брать :)
(77) gilv, замеры приводил где-то выше. На вскидку - перепроведение месяца на файловой базе - 16 минут, на SQL - 47 минут.
Затык именно в запросах.
Затык именно в запросах.
Если Вы прочитали статью , то там вроде на Ваши вопросы все данны. Вывод - Вы не читали или не хотите читать.
(80) gilv,
+ к тому же... Вы с увереностью говорите про повышение частоты процессора. Но не знаете какая у меня материнская плата... Там нет этой функции... ИМХО, разгонять сервер - не лучшая идея. Если вы часто прибегаете к этому методу, это не очень хорошо...
Соответственно, прироста производительности у меня не будет, т.к. мои 2.4Ghz против 2.7Ghz предложеного вами процессора существенного прироста не дадут.
Так же в вашу логику не укладывается то, почему для файлового варианта базы моего процессора достаточно, а для SQL - нет.
+ к тому же... Вы с увереностью говорите про повышение частоты процессора. Но не знаете какая у меня материнская плата... Там нет этой функции... ИМХО, разгонять сервер - не лучшая идея. Если вы часто прибегаете к этому методу, это не очень хорошо...
Соответственно, прироста производительности у меня не будет, т.к. мои 2.4Ghz против 2.7Ghz предложеного вами процессора существенного прироста не дадут.
Так же в вашу логику не укладывается то, почему для файлового варианта базы моего процессора достаточно, а для SQL - нет.
(81) закрываю тему со своей стороны и резюмирую:
1. Сомнительна тема изначально
Сколько бизнес готов заплатить, за то чтобы ускорить 47 минут до 5 минут к примеру? Если у него есть 90 000 руб., то мы готовы это сделать в клиент-серверном варианте.
2. если хочется найти причину не решать проблему, то всегда найдете
3. кто хочет решить проблему, информации в этой ветке для этого достаточно
4. рекомендация по процессорам в этой ветке однозначная - использовать процессор с максимальной частотой, если максимально топовый огранчен возможностями железа, то либо взять из доступных серверу с максимальной частотой, либо поменять материнку и другие ограничивающие компоненты
5. если нужна помощь в подборе процессора под конкретную материнку, 15 000 руб. нашими силами это будет стоить
6. на приложенном скриншоте нет реквизита турбобуст, с чего взяли что проц работает на 3.4 гц - хз.
7. подозреваю, что на проце 1270 можно еще немного выжать попугаев в тесте, если улучшить схему энергопитания
дальнейшие консультации оказываются на профессиональном форуме где оказывается квалифицированная помощь с ответственностью за рекомендации (фразы "сомневаюсь" отсутствуют, только цифры, факты, обоснования)
1. Сомнительна тема изначально
перепроведение месяца SQL - 47 минут.
- как правило это делается раз в месяц и это вовсе не ситуация когда "не проходит за ночь". Вот проведение за 24 часа - это проблема.
Сколько бизнес готов заплатить, за то чтобы ускорить 47 минут до 5 минут к примеру? Если у него есть 90 000 руб., то мы готовы это сделать в клиент-серверном варианте.
2. если хочется найти причину не решать проблему, то всегда найдете
3. кто хочет решить проблему, информации в этой ветке для этого достаточно
4. рекомендация по процессорам в этой ветке однозначная - использовать процессор с максимальной частотой, если максимально топовый огранчен возможностями железа, то либо взять из доступных серверу с максимальной частотой, либо поменять материнку и другие ограничивающие компоненты
5. если нужна помощь в подборе процессора под конкретную материнку, 15 000 руб. нашими силами это будет стоить
6. на приложенном скриншоте нет реквизита турбобуст, с чего взяли что проц работает на 3.4 гц - хз.
7. подозреваю, что на проце 1270 можно еще немного выжать попугаев в тесте, если улучшить схему энергопитания
дальнейшие консультации оказываются на профессиональном форуме где оказывается квалифицированная помощь с ответственностью за рекомендации (фразы "сомневаюсь" отсутствуют, только цифры, факты, обоснования)
(71) Snifer,
Вы хотите сказать что у вас вообще все запросы плохо работают? Это сколько в секундах?
А то я тут от одного товарища слышал, что проведение документы 2 секунды это жуткие тормоза, может вы тоже об этом?
Медленный запрос... хм... На самом деле, такое ощущение, что вы не читали топик.
Я уже писал о том, что замеры делались при старте 1С.
Запросы стандартные, конфигурация стандартная - Бухгалтерия 2.
Такое падение на всех запросах.
Если мы сейчас перепишем все стандартные! запросы под нас - мы будем при каждом обновлении ночевать на работе?
Переписывание запросов - это самый последний шаг.
Я уже писал о том, что замеры делались при старте 1С.
Запросы стандартные, конфигурация стандартная - Бухгалтерия 2.
Такое падение на всех запросах.
Если мы сейчас перепишем все стандартные! запросы под нас - мы будем при каждом обновлении ночевать на работе?
Переписывание запросов - это самый последний шаг.
Вы хотите сказать что у вас вообще все запросы плохо работают? Это сколько в секундах?
А то я тут от одного товарища слышал, что проведение документы 2 секунды это жуткие тормоза, может вы тоже об этом?
По поводу Hz трудно согласиться с Гилевым
Выдержка из таблицы результатов теста Гилева
1. Intel® Core™ i5-2410M CPU @ 2.30GHz - SQL - TCP_1C_GILV - Значение [54]
2. Intel® Xeon® CPU E5-2643 0 @ 3.30GHz - SQL - TCP_1C_GILV - Значение [53]
3.1. Intel® Xeon® CPU E5620 @ 2.40GHz - SQL - TCP_1C_GILV - Значение [7]
3.2. Intel® Xeon® CPU E5620 @ 2.40GHz - SQL - TCP_1C_GILV - Значение [24] ?
или в таблицах результатов содержатся неверные данные, или не совсем понятна разница 3.1 <-> 3.2 хотя там еще масса подробностей может присутствовать.
По последним сообщениям понятно что дело в "железе", но где более точное определение, что для серверов 1С + SQL требуется определенный вид процессоров или определенный тип памяти ? (см. hogik ? :) )
У снифера явное занижение скорости по выданным тестам, при этом на машине его товарища с более слабой серверной конфигурацией - показатели намного Выше.
Пойти, и просто купить самый мощный процессор (предложение Гилева), - один из самых дорогих в указанной линейке - особого ума не надо - думаю - что ему проще поменять свой более навороченный сервер на старенький сервер своего друга (если договорятся). Решит ли это проблему в общем ?
Тест Гилева можно запустить и на простеньком ноутбуке на i5 - и он покажет хорошие результаты (судя по таблице результатов)
Конечно максимально приближенный ответ = Проц-Память.
Но почему такая большая разница ? (при чем не в ГГц - а в характеристиках процессора, как и в характеристиках оперативки).
Выдержка из таблицы результатов теста Гилева
1. Intel® Core™ i5-2410M CPU @ 2.30GHz - SQL - TCP_1C_GILV - Значение [54]
2. Intel® Xeon® CPU E5-2643 0 @ 3.30GHz - SQL - TCP_1C_GILV - Значение [53]
3.1. Intel® Xeon® CPU E5620 @ 2.40GHz - SQL - TCP_1C_GILV - Значение [7]
3.2. Intel® Xeon® CPU E5620 @ 2.40GHz - SQL - TCP_1C_GILV - Значение [24] ?
или в таблицах результатов содержатся неверные данные, или не совсем понятна разница 3.1 <-> 3.2 хотя там еще масса подробностей может присутствовать.
По последним сообщениям понятно что дело в "железе", но где более точное определение, что для серверов 1С + SQL требуется определенный вид процессоров или определенный тип памяти ? (см. hogik ? :) )
У снифера явное занижение скорости по выданным тестам, при этом на машине его товарища с более слабой серверной конфигурацией - показатели намного Выше.
Пойти, и просто купить самый мощный процессор (предложение Гилева), - один из самых дорогих в указанной линейке - особого ума не надо - думаю - что ему проще поменять свой более навороченный сервер на старенький сервер своего друга (если договорятся). Решит ли это проблему в общем ?
Тест Гилева можно запустить и на простеньком ноутбуке на i5 - и он покажет хорошие результаты (судя по таблице результатов)
Конечно максимально приближенный ответ = Проц-Память.
Но почему такая большая разница ? (при чем не в ГГц - а в характеристиках процессора, как и в характеристиках оперативки).
(73) mikki_1C,
Рекомендую начать с , а именно
с
Т.е. тест характеризует не только процессор, а конечный результат, который достигается в совокупности всех факторов. Более того, тест не умеет к сожалению собирать параметры сервера 1С или субд. Если вы запустите клиента на дохлом компе, а сервере 1с и скуль на другом мощном железе, то по отчету может создаться впечатление, что слабый ноутбук "рвет" мощные сервера. Возможна и обратная ситуация. Т.е. предполагается, что клиент 1С-Сервер1С-СУБД стоят на одной железке и тогда можно делать какие то выводы. Но и то, в этом случаи есть разница например от использования протокола TCP и Shared Memroy между сервером 1С и субд.
По поводу Hz трудно согласиться с Гилевым
конечно трудно, сколько проектов за год успешно вы делаете по ускорению 1С? А как вы можете судить без нужного опыта и статистики, ясен перец, что ни как.
Рекомендую начать с , а именно
с
Вы получили в качестве результата некий индекс производительности (считай скорости). Не важно, хороший или плохой результат — это результат работы ПЛАТФОРМЫ на вашем «железе». В случаи клиент — серверного варианта это результат сложной цепочки прохождения запросов по различным участкам. Вы получаете общий фактический результат, который определяется САМЫМ УЗКИМ МЕСТОМ в системе. УЗКОЕ МЕСТО ЕСТЬ ВСЕГДА!
Другими словами, и настройки СУБД, и настройки ОС, и оборудование оказывают влияние на общий командный результат
Другими словами, и настройки СУБД, и настройки ОС, и оборудование оказывают влияние на общий командный результат
Т.е. тест характеризует не только процессор, а конечный результат, который достигается в совокупности всех факторов. Более того, тест не умеет к сожалению собирать параметры сервера 1С или субд. Если вы запустите клиента на дохлом компе, а сервере 1с и скуль на другом мощном железе, то по отчету может создаться впечатление, что слабый ноутбук "рвет" мощные сервера. Возможна и обратная ситуация. Т.е. предполагается, что клиент 1С-Сервер1С-СУБД стоят на одной железке и тогда можно делать какие то выводы. Но и то, в этом случаи есть разница например от использования протокола TCP и Shared Memroy между сервером 1С и субд.
Пойти, и просто купить самый мощный процессор (предложение Гилева), - один из самых дорогих в указанной линейке - особого ума не надо - думаю - что ему проще поменять свой более навороченный сервер на старенький сервер своего друга (если договорятся). Решит ли это проблему в общем ?
Я предложил два варианта, в том числе E5-2643 который далеко не топовый. (Топовый кстати E5-4650L стоит больше 3х штук) Более того, я акцентировал внимание что нужен процессор с высокими частотами, а не с высокой ценой. Не надо включать дурака. И этот апгрейд на порядок конструктивней чем ваши советы.
Поставили SQL сервер на обычный писюк.
Проц - Core2Duo E7500 - 2,93Ghz
Диски - Sata2
Память - 1333
Сделали замеры iometer и 1С:
Кароче так:
сервер с сас дисками - 850 попугаев (iometer)
десктоп с sata - 150 попугаев(iometer)
дело не в дисках.
А скорость по сравнению с нашим сервером - в 2 раза выше!
Неужели количество ядер не влияет???
Нахер тогда серваки вообще под SQL, если зависит от частоты проца?
Можно же взять AMD какой нить с 4.1Ггц и в ус не дуть?
Проц - Core2Duo E7500 - 2,93Ghz
Диски - Sata2
Память - 1333
Сделали замеры iometer и 1С:
Кароче так:
сервер с сас дисками - 850 попугаев (iometer)
десктоп с sata - 150 попугаев(iometer)
дело не в дисках.
А скорость по сравнению с нашим сервером - в 2 раза выше!
Неужели количество ядер не влияет???
Нахер тогда серваки вообще под SQL, если зависит от частоты проца?
Можно же взять AMD какой нить с 4.1Ггц и в ус не дуть?
За всю ветку обсуждения так и не нашел упоминания - какая конфигурация стоит на железке... Если самописная, без использования конструкций кода #сервер #клиент, то боюсь ситуация предельно ясна: Сервер не работает как сервер, а тупо транслирует файловые операции в Скуль....
Если это типовая конфигурация, то там выполнение кода разделено на клиентское и серверное, вплоть до проведения документов и выполнения запросов для отчетов... и увеличение скорость многократное...
PS в жизнь не поверю что 15 человек у вас работают на файловой типовой.... там 5 уже вешаются
Если это типовая конфигурация, то там выполнение кода разделено на клиентское и серверное, вплоть до проведения документов и выполнения запросов для отчетов... и увеличение скорость многократное...
PS в жизнь не поверю что 15 человек у вас работают на файловой типовой.... там 5 уже вешаются
Если файловая база стоит в терминале - она и будет быстрее чем SQL. Для 77 это нормальная ситуация. Стандартные запросы не оптимизированы под SQL , поэтому семерочные базы приходится использовать с прямыми запросами в наиболее сложных и критичных местах. SQL позволяет работать с базой бОльшему количеству пользователей одновременно. Но он не быстрее.
При маленьком количестве пользователей, файловая работает быстрее у меня также. Если один работаешь (допустим закрываешь месяц, перепроводишь документы за период) то я выгружаю базу со скуля в файловую и получается быстрее раза в 4 точно, это на одном и том железе. Но естественно если работает в базе больше 5 пользователей и если активно работают, то на файловой версии все вешается.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот