|
Какая "серверная" архитектура предпочтительней для Клиент-Серверной 1С 8.х | ☑ | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
0
sanfoto
17.10.14
✎
13:57
|
Итак Вводные данные:
1) 1С база - допустим стандартная УПП от самой 1С. 2) 1 000 (Одна тысяча) пользователей 3) размер базы 1 Терабайт ------------------------ Варианты по железу и ПО: 1) 50 серверов - на каждом по 20 ядер CPU... кроме пожалуй под SQL Выделенного (допустим 40 ядер) - все сервера объедены в "1С кластер" - OS Windows - коммуникация 10 или более Гигабит Ethernet - Везде SSD диски ******---------------------- 2) Один SGI сервер 1 000 ядер - используются те же CPU что и в первом варианте (между блоками быстрый Интер-коннект на NUMA чипах) - т.к. сервер один то ОДИН "сервер 1С" - OS Windows - коммуникация между SQL и "сервер 1С" - без сетевых протоколов - через участок памяти (SharedMemory) - SSD диски ------------------------------------------------- --------------Информация для размышления--------- ------------------------------------------------- можете провести простой тест (на любой СТАНДАРТНОЙ конфигурации) 1) берем "Комп1" и такой же абсолютно "Комп2" - на одном ставим SQL на другом "Сервер 1С" - обработкой.. проводим несколько тысяч документов Засекаем время. 2) берем "Комп1"(абсолютно такойже как в пункт Один) на нем и SQL и "Сервер 1С" соединены через SharedMemory - обработкой.. проводим ТЕЖЕ несколько тысяч документов Засекаем время. 3) Сравниваем результаты. (Лично у меня разница около 50%) |
||||||||||
11
sanfoto
17.10.14
✎
14:06
|
SGI порвет в клочья -> 50 серверов ИБО между ними будут большие задержки на синхронизацию.
Коммуникацию.. -можно проверить утилитой ipperf - между двумя компами например соединеных Ethernet 1 Gigabit/ Выбираем размер пакета 4 Кб (именно с таким работает MS SQL)/ так вот в результате скорость передачи данных будет равна около 250 Мегабит - можно проверить утилитой ipperf на ОДНОМ компе))) все увидите... а SharedMemory еще быстрей ИБО ненужно упаковка распаковка в сетевые пакеты. 1-ин SGI(1000 ядер) порвет-> 50 серверов |
||||||||||
12
Aleksey
17.10.14
✎
14:07
|
(10) Сдохнут <> умрут
Сдохнут - это значит будут не успевать обрабатывать |
||||||||||
13
piter3
17.10.14
✎
14:07
|
(10)если творчески подойти то сдохнут
|
||||||||||
14
Aleksey
17.10.14
✎
14:08
|
(11) шаред мемерои не панацея. скажем так шаред мемори позволит работать не 100 пользователям, а 101, т.е. там в пределах стат погрешности (по крайне мере на моем серваке было так)
|
||||||||||
15
vde69
17.10.14
✎
14:09
|
почему автор не расматривает вариант кластера SQL сервера ???
примерно так 30 серверов - кластер 1с 20 серверов - кластер SQL |
||||||||||
16
sanfoto
17.10.14
✎
14:10
|
(15)
без разницы пропорции ИБО между ними будут большие задержки на синхронизацию. Коммуникацию.. на синхрон транзакций |
||||||||||
17
Aleksey
17.10.14
✎
14:11
|
(8) я тестил полку с сас винтами (10 райд) и ССД Самсунг про 840 на 512 гигов
В линейном чтении ССД немного быстрее, но масштабируемость у САС выше, |
||||||||||
18
ice777
17.10.14
✎
14:12
|
(7) и правда, зачем 1С при таких возможностях-то.
|
||||||||||
19
Йохохо
17.10.14
✎
14:12
|
(16) а почему не 10 серверов 1с и 1 скуля?
|
||||||||||
20
sanfoto
17.10.14
✎
14:13
|
(18) поддержка ПО однако.
|
||||||||||
21
Aleksey
17.10.14
✎
14:13
|
(16) НЕ согласен. При прочих равных при больших объемах сетевая задержка нивелирует скоростью обработки
|
||||||||||
22
vde69
17.10.14
✎
14:14
|
(16) не скажи... если в системе наприер 1000 пользователей - то распаралеливание по серверам будет отлично работать... и чем тяжелее запросы тем будет лучше...
|
||||||||||
23
sanfoto
17.10.14
✎
14:16
|
(22)
рекомендую прочесть https://ru.wikipedia.org/wiki/ORM чтобы понять что БОЛЬШАЯ часть бизнес логики на "Сервере 1С" |
||||||||||
24
sanfoto
17.10.14
✎
14:16
|
(23) а не на SQL
|
||||||||||
25
Aleksey
17.10.14
✎
14:19
|
(23) С каких пор 1С стала следовать каким то стандартам и поддаваться логики???
|
||||||||||
26
sanfoto
17.10.14
✎
14:24
|
|||||||||||
27
XMMS
17.10.14
✎
14:28
|
А мне казалось, что 1 сервер на >100 пользователей - это уже весомый риск. Кластеры придуманы не только для распределения нагрузки, но и на случай отказа одного из серверов на любом из уровней - от приложения до железа.
|
||||||||||
28
Aleksey
17.10.14
✎
14:30
|
(27) Опять таки это если говорить в вне контекста 1С
А вот судя по отзывам кластеры от 1С явно для чего то другого придуманы |
||||||||||
29
oleg_km
17.10.14
✎
14:33
|
(27) В 8.2 кластеры решают ТОЛЬКО проблему распределения нагрузки. Вернее, с их помощью можно удлинить интервал падания серверов из-за утечек памяти
|
||||||||||
30
SSSSS_AAAAA
17.10.14
✎
14:36
|
(0) А под Sql сервером какой сервер подразумевается? MS Sql или какой другой?
|
||||||||||
31
sanfoto
17.10.14
✎
14:42
|
(28) +
(29) + от меня + "Кластеры 1С" дают замедление работы.. проведение доков и т.п. |
||||||||||
32
sanfoto
17.10.14
✎
14:43
|
(30) в общем случае наибольшая скорость работы 1С на MS SQL
поэтому без разницы какая Реляционная СУБД |
||||||||||
33
sanfoto
17.10.14
✎
14:45
|
(30) рекомендую прочесть https://ru.wikipedia.org/wiki/ORM
|
||||||||||
34
SUA
17.10.14
✎
14:49
|
1 сервер лучше сети, главное делать бэкапы =)
(1)(2)(4)да, 1с уже давно не только для ларьков хотя для отказоустойчивости - по 2 компа на кластеры скуля и 1с как-то понадежнее |
||||||||||
35
SSSSS_AAAAA
17.10.14
✎
14:50
|
(32) Ошибаетесь, разница есть. Кластер MS SQL не умеет параллелить нагрузку и потому всякие разговоры о 20 ms sql серверов для одной базы бесмысленны.
|
||||||||||
36
piter3
17.10.14
✎
14:51
|
(34)фраза 1с готова как-то не очень.платформа и/или решения?
|
||||||||||
37
sanfoto
17.10.14
✎
14:51
|
что невижу голования.. кроме НЕОБОСНОВАННОГО))
"pessok 4 - 17.10.14 - 14:03 ни один из вариантов работать не будет, бо 1С 3. Другое (описываем) " |
||||||||||
38
ssh2QQ6
17.10.14
✎
14:52
|
(37) все википедию читают, мат часть подкачала
|
||||||||||
39
sanfoto
17.10.14
✎
14:55
|
(35) Ошибаетесь вы))
даже кластер ORACLE предел масштабируемости ДВА СЕРВЕРА с InfiniBand коэф 0.9.... т.е. уже деградация ...производительности а дальше вниз крутая кривая https://ru.wikipedia.org/wiki/InfiniBand |
||||||||||
40
SUA
17.10.14
✎
14:56
|
(36) УТ11 видел на 1.5К онлайн пользователей, причем по этому показателю база успешно росла
|
||||||||||
41
SSSSS_AAAAA
17.10.14
✎
14:56
|
(39) И в чем я ошибся?
|
||||||||||
42
piter3
17.10.14
✎
14:57
|
(40)понял,но больше интересно объемы в Тб.а звери могут пасьянс раскладывать
|
||||||||||
43
sanfoto
17.10.14
✎
15:00
|
(42)
но больше интересно объемы в Тб.а звери могут пасьянс раскладывать 1)если использовать "Кластеры" - то да 2)а если как и в "SAP NAVISION" использовать ОДИН много много ядерный сервер то нет)) |
||||||||||
44
Maxus43
17.10.14
✎
15:00
|
насчет количество серверов я хз, но в моём пониманиии примерно так:
1. 1с пофиг сколько у тебя ядер, всё равно использует одно на 1 процесс. 2. через шаред мемори конечно быстрее, не юзается сетевой интерфейс, тут проблема будет в паралельности, блокировках и прочем, на типовой УПП не взлетит впринципе такая нагрузка, хоть в 2 раза лучше железо купи, надо логику переписывать там |
||||||||||
45
ice777
17.10.14
✎
15:02
|
(44) насчет ядер на процесс.. дадад.)
|
||||||||||
46
Maxus43
17.10.14
✎
15:02
|
у софтпойнта такой опыт есть, я хз справились они или нет, там с кластерами скуля что-то мутное делали, свои разработки юзали.
На оракле и 1с знаю проект примерно такой по масштабам, но врятли кто-то даст у них спросить как было сделано, мбо такие вещи делаются дорого специализированными конторами |
||||||||||
47
sanfoto
17.10.14
✎
15:02
|
(44) Maxus43
процес то один и у например SQL сервера, а ПОТОКОВ то МНОГО и они вполне могут быть на разных ядрах. https://ru.wikipedia.org/wiki/Процесс_(информатика) |
||||||||||
48
SUA
17.10.14
✎
15:03
|
(46)Просто дорого. Любой очень крупный франч - центр компетенции.
|
||||||||||
49
Maxus43
17.10.14
✎
15:03
|
(47) я про процесс 1с, он не юзает различные ядра на разные потоки процесса.
Стандартная картина на серверах: ровно 50% загружен проц - це 1с, к гадалке не ходи |
||||||||||
50
Maxus43
17.10.14
✎
15:05
|
(48) я бы например БИТ и близко не подпустил к такому проекту... крупнота не показатель
|
||||||||||
51
sanfoto
17.10.14
✎
15:05
|
(49)
я кажется понятно написал ПРОЦЕСС один... но внутри него много потоков как клиентов 1с так и служебных... потоки исполняются ПАРАЛЕЛЬНО |
||||||||||
52
piter3
17.10.14
✎
15:05
|
(48)неа 100 раз нет
|
||||||||||
53
МихаилМ
17.10.14
✎
15:06
|
закройте ветку
автор уже 2 раз на аналгичные темы по 900 постов надрывался v8: Полное масштабирование 1С 8.х (клиент-серверный вариант) - кому удалось, идеи? ) v8: 1с 8.х от чего зависит скорость и Миф о многопроцессорных/многоядерных серверах |
||||||||||
54
piter3
17.10.14
✎
15:06
|
(51)можно нескромный вопрос?это теория или практика.кроме ссылок на вики
|
||||||||||
55
sanfoto
17.10.14
✎
15:07
|
(54) практика
|
||||||||||
56
Maxus43
17.10.14
✎
15:07
|
(51) ты теорию написал, а приложение должно поддерживать работу с несколькими процессорами-ядрами, 1с не поддерживает
|
||||||||||
57
sanfoto
17.10.14
✎
15:08
|
(56) Maxus43
вы про ПОТОКИ кода нибудь читали? |
||||||||||
58
Maxus43
17.10.14
✎
15:09
|
ЕСЛИ в 1с всего 1 процесс, ты не загрузишь им больше ОДНОГО ядра, это практика, а не теоритические статьи из начальной информатики. Операционка не будет сама распределять, если в программном обеспечении не заложено
|
||||||||||
59
Maxus43
17.10.14
✎
15:10
|
(57) читал. Нагрузи мне одним процессом 1с больше одного ядра.
|
||||||||||
60
sanfoto
17.10.14
✎
15:11
|
(59) мы про процесс "сервера 1с" ГОВОРИМ?
|
||||||||||
61
Maxus43
17.10.14
✎
15:14
|
(60) конечно, но тут без разницы.
процесс rphost (в диспетчере) это и есть процесс сервера 1с, и он работает только с одним ядром |
||||||||||
62
sanfoto
17.10.14
✎
15:16
|
(59) Maxus43
"Стандартный нагрузочный тест 1С" ЛИЧНО проводил тест в Односерверной системе принудительно ограничивал SQL по ядрам, на внеш компах. запускались десятки клиентов и ативно проводили доки... на 500 клиентах кончились резервы "клиентских компов" )) на сервере где крутился "Сервер 1С" все ядра были загружены под 90% |
||||||||||
63
sanfoto
17.10.14
✎
15:20
|
(61)
а 50% была загрузка в ДВУХ-СЕРВЕНОЙ конфигурации и загрузка сети была всего 20% а это уже забитый канал ПОЛНОСТЬЮ при общении "Сервера 1С" и "MS SQL" ИБО ЛАТЕНТНОСТЬ Etherneta/// т.е. пропускная способность уменьшяется по мере уменьшения пакета так что 20% ПРЕДЕЛ ПРЕДЕЛОВ |
||||||||||
64
oleg_km
17.10.14
✎
15:21
|
(61) Ничего подобного, процесс rphost многопоточный, иначе многопользовательская работа была бы практически невозможна. Это клиентская 1C.exe многопоточная, но программист 1С работает только в одном потоке.
|
||||||||||
65
sanfoto
17.10.14
✎
15:21
|
(64) +
|
||||||||||
66
Maxus43
17.10.14
✎
15:25
|
мда. поичтал предыдущие ветки автора, и последние тут посты, бесполезный разговор грядёт на 1000 постов...
(64) тут надо сделать оговорку всё таки. 1с псевдомногопоточная. Каждый сеанс(соединение) может работать только в одном процессе и с одним ядром процессора, другие сеансы в других процессах и с другими ядрами |
||||||||||
67
sanfoto
17.10.14
✎
15:26
|
(63)
смотрят СИСАДМИНЫ на загрузку сети 20% и загрузку ядер серверов в 50% и радуются мы все сделали ресурсов железа хватает. а Ваша 1С тормозит ибо тупая 1С.. оптимизируйте код! ТУПО!!!! на самом деле "Сервер 1С" и "SQL" получается друг друга ждут вот и низкая загрузка CPU)) |
||||||||||
68
sanfoto
17.10.14
✎
15:27
|
(66)" Каждый сеанс(соединение) может работать только в одном процессе и с одним ядром процессора" глупость
|
||||||||||
69
Maxus43
17.10.14
✎
15:30
|
дело в таких больших системах не в процессорных мощностях, а в конкуренции юзеров за ресурсы СУБД, блокировках и т.д.
|
||||||||||
70
Maxus43
17.10.14
✎
15:31
|
(68) давай, просвяти глупых, может в рай попадёшь за благие дела
|
||||||||||
71
sanfoto
17.10.14
✎
15:36
|
(69)
а вы читали https://ru.wikipedia.org/wiki/ORM чтобы понять "Сервер 1С" это "Виртуальная ОБЪЕКТНАЯ СУБД" уперлись рогом в реляционный SQL что все дело только в нем)) |
||||||||||
72
sanfoto
17.10.14
✎
15:38
|
кстати ГДЕ голосование ?
я не учитель... учить надоело однако)) Голосуем!!! |
||||||||||
73
sanfoto
17.10.14
✎
15:41
|
(70) Maxus43
внизу и справа веб страничики есть)) Ваш выбор: очистить 1. 50 Серверов(в сумме 1000 ядер) порвут-> SGI 2. 1-ин SGI(1000 ядер) порвет-> 50 серверов 3. Другое (описываем) Обоснуйте свой выбор! |
||||||||||
74
Зеленый пень
17.10.14
✎
15:43
|
Соглашусь с (3).
Если у вас задача проводить последовательно 1000 документов - это одно. Если - параллельная работа юзеров, тест некорректный. ИМХО, чем меньше сетевых соединений и, соответственно, задержек по передаче данных, тем лучше. |
||||||||||
75
Maxus43
17.10.14
✎
15:43
|
(71) чего сказать то хотел? 1с говно?
(72) учи в другом месте, например в Алтайском государственном техническом университете им.И.И.Ползунова |
||||||||||
76
Fragster
гуру
17.10.14
✎
15:43
|
на 1000 юзеров УПП не взлетит без допила, надо ERP брать. ну а так - работать и так и так будет, но на одном 16ядреном серваке в 100 потоков показывает немного лучший результат, чем на двух.
1-ин SGI(1000 ядер) порвет-> 50 серверов |
||||||||||
77
sanfoto
17.10.14
✎
15:45
|
(75)
(70) Maxus43 внизу и справа веб страничики есть)) Ваш выбор: очистить 1. 50 Серверов(в сумме 1000 ядер) порвут-> SGI 2. 1-ин SGI(1000 ядер) порвет-> 50 серверов 3. Другое (описываем) Обоснуйте свой выбор! |
||||||||||
78
sanfoto
17.10.14
✎
16:04
|
(76) Fragster
Цитата: "на одном 16ядреном серваке в 100 потоков показывает немного лучший результат, чем на двух." по процессорным мощностям я расчитываю примерно так 1)современные CPU держат 8 "высоко нагруженных" потоков на ядро 2)16*8 = 128 потоков 3) вроде хватает на на "100" "высоконагруженных", но надо учитывать, что система кушает, юзер 1с поток+ поток на юзера в SQL ----ИТОГО----- 16 ядерника хватит без резкого падения производительности... скажем так на 60 высоко-нагруженных "1c клиентских потоков" |
||||||||||
79
Ник второй
17.10.14
✎
16:10
|
На практике
50 Серверов(в сумме 1000 ядер) порвут-> SGI |
||||||||||
80
sanfoto
17.10.14
✎
16:13
|
(79)
маловато обосновано однако)) ну да ладно |
||||||||||
81
Fragster
гуру
17.10.14
✎
17:04
|
(78) сделай себе красивые графики с помощью http://infostart.ru/public/173394/ (будешь увеличивать количество потоков или как-то по другому менять алгоритмы, пожалуйста не выгружай результаты в сеть)
|
||||||||||
82
shuhard_серый
17.10.14
✎
17:17
|
(0) если выделить каждому юзеру по ядру, то очевидное узким местом будет сиквел
и здесь любая альтернативная учетная система, да речь об Аксапте порвёт УПП как тузик грелку ну нельзя с чудовищной избыточность 1С, пишущей одно и то же в 200 Регистров и на ходу пересчитывающей итоги , всерьёз обсуждать 1000 полноценных ERP пользователей Другое (описываем) |
||||||||||
83
Fragster
гуру
17.10.14
✎
17:21
|
(82) я хз, но на аосы и прочую фигню на сто юзеров дакса ресурсов выделено сильно больше, чем на ту же сотню юзеров 1са... при этом дакс тормозит не меньше, а 1с удобнее сильнее :) как оно отмасштабируется на 1000 юзеров - оно, конечно, хз, но вот 1с-то можно условно-бесконечно "горизонтально" масштабировать с помощью РИБа (конечно, если смириться с некоторой "неопреативностью" из-за разделения по функционалу и/или реквизитам-разделителям регистров (склады или огранизации, например))
|
||||||||||
84
shuhard_серый
17.10.14
✎
17:45
|
(83) ключевой слово РИБ,
ну не умеет 1С работать с несколькими сиквалами и бысто деградирует под нагрузкой причина в проведении документов и структуре Рг остатков пока 1С эту часть архитектуры не изменит ни какие кластеры серверов транзакций не помогут |
||||||||||
85
Fragster
гуру
17.10.14
✎
17:49
|
(84) а что такого плохого в проведении? то, что еще парочка таблиц апдейтятся? ну, если совсем тяжело и вы 80-го года доки перепроводите пачками - ну установите вы период рассчитанных итогов на это время и оставьте текущие итоги - будет ровно то же, что в "ынтырпрайзных" даксах по количеству апдейтов, а вот когда вам остатки нужно будет на предыдущий период получить - вот тогда вы табличке итогов скажете спасибо. а при неопреативном проведении даже за пару лет назад (х24 строки апдейтятся) ничего прямо катастрофического нет.
|
||||||||||
86
Jump
17.10.14
✎
17:51
|
(0)Взлетит.
По принципу - разделяй и властвуй. Короче серверов побольше, и базу аккуратно делишь между серверами. |
||||||||||
87
shuhard_серый
17.10.14
✎
19:35
|
(85) ох мне эти сказочники, ты готов заставить типовой документ(РТиУ под партионкой с оперативным зачетом аванса) в УПП проводиться за 0.1 секунды ?
а записывается он именно за такое время |
||||||||||
88
Escander
17.10.14
✎
19:55
|
SGI = Silicon Graphics?
конечно 1 большой машин для кластера 1С лучше... но пока не возникает потребность в отказоустойчивости... 1К юзеров... тут наверное базоводом оракл брать... но тут моментов хватает. В общем я-бы Вячеслава Гилёва почитал, у него много чего есть про высоконагруженные решения |
||||||||||
89
Fragster
гуру
17.10.14
✎
20:17
|
(88) я видел >500 юзеров на одном сервере 1с + 1 сервере мсскуля (что-то типа 32 ядер там было на каждом). А на оракле может быть опасно из-за ошибок платформы в работе с этим самым ораклом
|
||||||||||
90
Escander
17.10.14
✎
20:37
|
(89) тут Вячеслав вам в помощь. Моментов там есть, но вроде как всё решаемо. Конечно нужен грамотный ораклоадмин.
Тестировали 1С с разными базоводами... если нужна производительность при >100 юзеров - однозначно оракл. |
||||||||||
91
Escander
17.10.14
✎
20:37
|
в смысле не я лично а статью читал
|
||||||||||
92
Fragster
гуру
17.10.14
✎
20:39
|
(90) пару разработок для Вячеслава делал я, только тсссс ;)
|
||||||||||
93
Escander
17.10.14
✎
20:42
|
(92) примерно год назад на сходке ораклистов главный от оракла по сибири рассказывал как он ускорил раз в 6 сальдооборотную ведомость на демобазе УПП... есть моменты...
|
||||||||||
94
Escander
17.10.14
✎
20:44
|
(92) конфы? Так вот значит один из маньяков пишуших конфы где 10% кода попытка - исключение!!!
|
||||||||||
95
Ник второй
17.10.14
✎
20:47
|
(80) Что тут обосновывать? это было бы сумасшедствие несколько тысяч засовывать на один сервак, в общем 50 серваков (баз) лучше одного
|
||||||||||
96
Ник второй
17.10.14
✎
20:47
|
(81) А смысл в этой поделке если есть ТесЦентр?
|
||||||||||
97
Ник второй
17.10.14
✎
20:51
|
(90) Оракл явно проигрывает
|
||||||||||
98
Ник второй
17.10.14
✎
20:52
|
(93) Вот вот и только в этом случае оракле приблизится к мс скл.
|
||||||||||
99
Reaper_1c
17.10.14
✎
22:32
|
(0) Ну и нахрена это все, когда:
http://v8.1c.ru/expert/cts/cts-202-010.htm http://v8.1c.ru/expert/cts/cts-218-001.htm Другое (описываем) |
||||||||||
100
Escander
18.10.14
✎
09:21
|
(97) то-то у последнего сиквела дали возможность ему становиться версионников... то что у оракла всегда было нативно
|
||||||||||
101
Escander
18.10.14
✎
09:25
|
+ (100) хотя конечно если ты не слышал про управляемые блокировки...
|
||||||||||
102
kolanych
18.10.14
✎
10:41
|
кластер sql повышает только отказоустойчивость. но не производительность. это надо знать, прежде чем проектировать систему.
|
||||||||||
103
Маратыч
18.10.14
✎
10:59
|
Во-первых, надо сделать пул терминальных серверов. Как он там называется сейчас - ферма вроде.
Во-вторых, архитектура у тебя непонятная. Я не скажу навскидку, что гамно, но что-то подсказывает... |
||||||||||
104
Обработка
18.10.14
✎
11:53
|
Думаю важно не выбор железа а надо писать свое УПП не подойдет.
Другое (описываем) |
||||||||||
105
Обработка
18.10.14
✎
11:58
|
**Думаю важно не выбор железа а надо писать свое, УПП не подойдет.
|
||||||||||
106
systemstopper
18.10.14
✎
12:36
|
(0) условия гипотетические, тест гуано. "Везде SSD диски" - вообще ни о чем, райды какие?
|
||||||||||
107
sanfoto
20.10.14
✎
05:27
|
радует что большинство таки понимает, что
Кластер <> Скорость работы , а лишь повышает отказоустойчивость. А также есть понимание, что задержки в коммуникации между SQL и "Сервер 1С" - тоже НЕ приводят к "Скорости работы" платформы)) |
||||||||||
108
sanfoto
20.10.14
✎
05:29
|
(106)
про RAID и SSD -- как это не странно в нем(кроме RAID 0 ) кое-какие характеристики по задержкам ухудшаются по сравнению с Одиночным SSD/ |
||||||||||
109
sanfoto
20.10.14
✎
05:52
|
про оптимизацию конфигурации под НАПРИМЕР MS SQL:
(0) да можно перенести ПОБОЛЬШЕ логики на SQL путем использования объекта "1С Запрос" .... да можно написать МНОГО ТЫСЯЧА...десятки ТЫСЯЧ строчные запросы ......... вместо пару десятков строк объектного кода.... КСТАТИ "ЗАПИСЬ и Обработка заполнения Объектов" все-равно будет НЕ в ЗАПРОСЕ!!!!!!!!!!! Суть в том что такое решение становится 1)Очень МЕДЛЕННО в скорости разработки 2)менее гибко 3)зависимо от "первоночального разраба оптимизатора" 4)....... и т.д. |
||||||||||
110
sanfoto
20.10.14
✎
06:02
|
т.е.
1) Экономически более оправдано собрать аппаратно-программный комплекс заточенный на поддержку "Объектного подхода", чем 2)бесконечная "дойная корова" для спецов "Реляционного подхода".... ---------------------------------- Это конечно со стороны "Заказчика"... ))) |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |