Вход | Регистрация



Тут кто-нибудь сравнивал производительность файловых и серверных версий?

Тут кто-нибудь сравнивал производительность файловых и серверных версий?
Я
   33554432
 
28.12.17 - 07:48
Нужно провернуть довольно большую многочасовую обработку. В файловой версии она 8 часов отрабатывает. Может ли она отработать быстрее в скл версии? Вопрос почему возник, процессор диск и память пишут загрузку 10% в момент отработки. А у меня еще другая база была в скл, там другая обработка жрала все под 90-100%.
 
 
   lodger
 
1 - 28.12.17 - 07:52
"загрузку 10%" << "под 90-100%."
даже если взять 10-15% на погрешность и транзакционные расходы. значит ответ - на сервере происходит большее число работы за единицу времени.
   Azverin
 
2 - 28.12.17 - 07:53
(0) может. а может и нет
   yfylhjkjy
 
3 - 28.12.17 - 08:00
Стаж: 2 года 9 месяцев 23 дня ппц
   Aleksey
 
4 - 28.12.17 - 08:12
у файловой на порядок больше скорость записи
у скульной быстрее выборка данных. причем чем больше в БД данных тем больше файловая приогрывает. плюс масштабируемость у скульной больше

так что если мы говорим о перепроводки (или о массовой записи), то файловая впереди скульной

Если мы говорим о выгрузки данных на сайт, то не факт что файловая зарешает

Так что по какому параметру будем производительность сравнивать?
   33554432
 
5 - 28.12.17 - 08:18
(4)
в моем случае обмен между базазами 1с через com за год по всем документам и справочникам.
   stopa85
 
6 - 28.12.17 - 08:21
(0) есть файловая версия на SSD диске, а объем файлового кеша системы больше размера БД. Почти всегда будет быстрее.
   vis_tmp
 
7 - 28.12.17 - 08:22
(5)Скорее всего без особой разницы будет, т.к. сам com медленее
   Адинэснег
 
8 - 28.12.17 - 08:22
(4) >> у файловой на порядок больше скорость записи
особенно когда в неё пишут 100 ползователей
   Веселый собака
 
9 - 28.12.17 - 08:22
(0) Если в этой обработке кривые запросы в цикле, то серверная не поможет.
   33554432
 
10 - 28.12.17 - 08:26
Еще в свое время сталкивался с базой, которая файловая и сильно тормозила. После перевода в скл она залетала. Просто объем был достаточно большой и подходил к предельному размеру таблиц. Я не знаю, как 1с обрабатывает эту ситуацию, но при больших размерах файловая продолжает работать но сильно тормозит. Я сейчас склоняюсь именно к этой версии, что база начинает тормозить с определенного момента, когда размер подходит к критичному для файловых таблиц.
 
 Рекламное место пустует
   Aleksey
 
11 - 28.12.17 - 08:30
(8) Мы сейчас р сферической базе в ваккуме говорим, или о конкретной ситуации когда ТС один в базе и запустил обработку?
Так то можно учесть вляние пятен на солнце на скорость подключения по com
   Aleksey
 
12 - 28.12.17 - 08:32
(10) отладчик в руки. Может у тебя каждый раз новое соединение инициализируется. Или каждый раз перезаполняются справочники, даже если данные не поменялись
   Azverin
 
13 - 28.12.17 - 08:37
(5) "обмен между базазами 1с через com" - и это в канун 2018 года, атас)
   Azverin
 
14 - 28.12.17 - 08:38
(10) посмотрите размер таблиц - узнаете, есть ли критические таблицы.
   1Сергей
 
15 - 28.12.17 - 08:51
(13) а чем надо в канун 2018?
   33554432
 
16 - 28.12.17 - 09:06
(15)
черех хмл наверно или тхт
   vde69
 
17 - 28.12.17 - 09:07
если выгрузка сейчас идет в монопольном режиме и размер транзакций не большой (до 1000 объектов) то серверную версию можно даже не пробовать, если и будет ускорение - то не значительное.

если это НЕ монопольный режим и одна большая транзакция - то в скуле будет ощутимый прирост скорости
   33554432
 
18 - 28.12.17 - 09:08
(17)
А какой критерий измерения большизны транзакции, как вычислить?
   VladZ
 
19 - 28.12.17 - 09:12
(0) "В файловой версии она 8 часов отрабатывает. Может ли она отработать быстрее в скл версии? " Что мешает развернуть SQL-сервер и проверить?
   Azverin
 
20 - 28.12.17 - 09:13
(15) явно не устаревшим и глючным com-соединением)
   33554432
 
21 - 28.12.17 - 09:14
(19)Время, этож возиться надо, создавать базы, загружать базы. А вдруг зря, обидно будет немного
   vde69
 
22 - 28.12.17 - 09:15
запись 1000 строк в таблицы - это вполне нормальная
запись 10000 строк - уже тяжелая, но приемлемая
запись 100000 строк - явно большая для 1с


1 стока <> 1 объекту/документу
   33554432
 
23 - 28.12.17 - 09:17
(20)
Что в нем устаревшее то? Вполне работает.
   mehfk
 
24 - 28.12.17 - 09:17
(21) Не хочешь делать сам - делегируй это кому-нибудь.
   Azverin
 
25 - 28.12.17 - 09:18
(23) работает - не трогай. согласен)
   1Сергей
 
26 - 28.12.17 - 09:20
(20) сохранять и читать файлик более модно?
   mistеr
 
27 - 28.12.17 - 10:45
(5) Хочешь быстрее - делай обмен через файлы, а не COM. Оптимизируй сам обмен. разбей на этапы (Справочники,
РС, Документы и т.п.), оптимизируй правила по рекомендациям 1С.

После этого и скуль может помочь, т.к. основная нагрузка сместится на выборку и запись данных.
   mistеr
 
28 - 28.12.17 - 10:48
(23) Дело не в том, что устаревшее, а в том, что COM еще тот тормоз. Почему запросы в цикле это плохо, представляешь? Так вот, каждый вызов через COM это "запрос".
   Aleksey
 
29 - 28.12.17 - 10:55
(20)  так вот почему в типовых для обменов приоритет отдан глючному ком, а не как раньше через надежный файл
   33554432
 
30 - 28.12.17 - 10:57
(27)
Переделывать не вариант. Закончить все надо до конца года. Седня последнюю ошибку устранил вроде. Если на файлы переделать, до конца года точно не успею.
   Aleksey
 
31 - 28.12.17 - 10:58
с чего это через ком будет медленее?
Через файл мне нужно выгрузить 100500 реквизитов и не факт что они мне понадобятся.
А через ком я дергаю только то что мне нужно.

Смысл мне дергать номенклатуру, если она уже есть в базе, но при выгрузки в файл я этого не знаю, и мне нужно быть готовым к пессимистическому сценарию. Т.е. предположим что там нет номенклатуры, поэтому мне нужно выгрузить номенклатуру, единицы, гтд, и еще полсотни сопутствующих справочников
   Aleksey
 
32 - 28.12.17 - 11:01
(30) разбивай на группы и на этапы и грузи паралельно
Т.е. 1 поток грузит чисто справочник номенклатуру
2 поток грузит чисто справочник контрагенты

Вероятность пересечения мала, поэтому врядли он нарвется на блокировку

во втором этапе грузим документы тут тоже можно разбить например отдельно банк, отдельно касса, отдельно приходы и т.д.
   Aleksey
 
33 - 28.12.17 - 11:02
скорости это не прибавит, но зато тебе будет чем заняться эти 8 часов
 
 
   mistеr
 
34 - 28.12.17 - 11:15
(31) При выгрузке через COM ты тоже не знаешь, пока не сделаешь запрос через COM. Не вижу принципиальной разницы.
   rs_trade
 
35 - 28.12.17 - 11:29
(28) почему ком тормоз? можно тормозам объяснить?
   33554432
 
36 - 28.12.17 - 11:33
(32)
Кстати это идея, спасибо, попробую
   rs_trade
 
37 - 28.12.17 - 11:41
самописный обмен через ком будет гораздо быстрее выгрузки/загрузки через файло. а еще если в 2-3 потока, тем более
   mistеr
 
38 - 28.12.17 - 12:01
(35) Возможно. Я говорил про обмен через КД.
   Aleksey
 
39 - 28.12.17 - 12:19
(34) я выгружаю через ком документ. дальше мне нужно найти по ссылки контрагента. Если я нашел я тупо использую найденный объект. Если не нашел, тогда да я делаю еще один запрос по ком на получения всех реквизитов элемента справочника.
   rs_trade
 
40 - 28.12.17 - 12:22
(38) в КД не ком обмен, а хрень. там выгружается файл, а загрузка этого файла дергается из базы приемника через ком-соединение.
   rs_trade
 
41 - 28.12.17 - 12:25
(39) это уровень прикладной логики, а не минус технологии.

я могу пулять по ком документ и ниче не искать по реквизитам. а наличие контрагентов из документа, решается тем, что ты их загнал в базу приемник до документа.
   VladZ
 
42 - 28.12.17 - 12:27
(21) Почему сразу зря? Любой результат будет информативен.
   VladZ
 
43 - 28.12.17 - 12:28
+42 К тому же будет платформа для тестов. Не только для этой задачи, но и для любой другой.
   mistеr
 
44 - 28.12.17 - 12:28
(39) Вот это "дальше мне нужно найти по ссылки контрагента" в коде как выглядит?
   Aleksey
 
45 - 28.12.17 - 15:15
(44) дело техники. Начиная от найтиПоКолду/НайтиПоРеквизиту/НайтиПоНаименованию
и заканчивая СсылкаНаОбъект=Справочники.Контрагенты.ПолучитьСсылку(Новый УникальныйИдентификатор(ГУИД));
   rs_trade
 
46 - 28.12.17 - 15:22
(45) искать надо сами объекты, а не реквизиты. в реквизит просто ссылку пишешь и все.
   X Leshiy
 
47 - 28.12.17 - 15:56
(28) Что за чушь?
   dachnik
 
48 - 28.12.17 - 16:01
Может немного не по теме, но сегодня обнаружен ЭФФЕКТ прироста памяти - на рабочем компе стало 6 гигов, если при 4-х документ проводился за пол-часа или даже дольше, то сейчас - менее минуты. В доке порядка 40 тысяч строк. База на Постгри, платформа 8.3.10.2580 доклад закончил! )
   igork1966
 
49 - 28.12.17 - 16:11
(48) Это как раз понятно, своппинг из-за недостачи памяти.
4G для 1С это очень мало
 
 Рекламное место пустует
   mistеr
 
50 - 28.12.17 - 21:49
(48) А в чем прикол делать такие доки по 40К строк? Можно сделать 10 доков по 4000 строк и обойтись четырьмя гигами памяти.

А так, любую систему можно раком поставить.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует