Для терминального режима

**olhovik** Ср Фев 17, 2010 12:02

Hi All
Сейчас у нас уже 5 локальных ключей на смета.ру. Расширяемся.
Базы и софт расположены локально на рабочих станциях.
Надо перенести всё на терминальный сервер как и с 1С. Нужен именно ТЕРМИНАЛЬНЫЙ СЕРВЕР, каналы связи аховые.
Про практические аспекты этого дела инфы мало, кроме того что при сетевом ключе это возможно. Посему вопросы:
1. Как смета будет работать на Win 2008 x64 ?
2. То же для firebird, есть версия для x64? Насколько она стабильна?
3. Сколько памяти надо для комфортной работы?
4. Были какие то тестирование на двухпроцессорных системах, имеет смысл второй xeon? Firebird умеет параллелить между ядрами/процессорами?

Ваша реклама

**Kir** Ср Фев 17, 2010 17:33

olhovik писал(а):1. Как смета будет работать на Win 2008 x64 ?
2. То же для firebird, есть версия для x64? Насколько она стабильна?
3. Сколько памяти надо для комфортной работы?
4. Были какие то тестирование на двухпроцессорных системах, имеет смысл второй xeon? Firebird умеет параллелить между ядрами/процессорами?

1. Так же как и на x86.
2. Работа комплекса гарантирована только для версии Firebird 1.5.0.4306.
3. Памяти много не бывает. (от 2Гб)
4. Существует вариант установки Firebird в Classic Server. Нюансы все здесь.

**olhovik** Чт Фев 18, 2010 9:28

Kir писал(а):1. Так же как и на x86.
2. Работа комплекса гарантирована только для версии Firebird 1.5.0.4306.
3. Памяти много не бывает. (от 2Гб)
4. Существует вариант установки Firebird в Classic Server. Нюансы все здесь.

1. Т.Е. как приложение x86, говорят потеря производительности, или врут?
2. Firebird 1.5.0.4306 для x86 имеется?
4. Про классик разбираюсь.

Пока по чтении документации и думании вопросы след:
1. Если будет выбор между 2003 и 2008 что для сметы лучше? Севрер с 2003 есть, хочется новый с 2008, а беглый обзвон продавцов говорит что в феврале приличной техники нету. Хочу понять чего я потеряю при использовании 2003 ts вместо ts 2008.
1а. Публикуется смета на ts без особенностей?
2. Если из 5 клиентов 4 будут в терминале а один присоединиться как клиент/серверное приложение со своей ws - будут конфликты?

**olhovik** Чт Фев 18, 2010 20:28

Hi
Нус понятно, дело тёмное, надо тестовый стэнд ставить с 2008. Благо недолго

А существует возможность взять (пусть и за плату) на тестирование сетевой ключ ?

**aivt** Пт Фев 19, 2010 13:50

Во всей вашей истории есть одно узкое место - жесткий диск.
Вы можете установить сколько угодно процессоров, но все равно не получите повышения производительности всей системы, так как при нормальной работе процессоры будут в основном простаивать ожидая пока информация протиснется через "узкий" канал на жесткий диск.

Если у вас несколько более или менее хороших рабочих мест у пользователей (Core 2 Duo 2Гб ОЗУ), и сервер не очень крутой (хватает одного Core Quad процессора и 3 Гб ОЗУ), то работать будет не плохо, так что не стоит огород городить.

За теже дегьги, которых будет стоить сервер на 2-х ксеонах с Win 2008 ts, вы можете купить десяток неплохих клиентских компьютеров и собрать простенький системник под сервер на Core Quad процессоре с Win XP Prof.

Если не заморачиваться с терминалом, то смысла ставить серверную операционку нет ни какого, так как для Smeta.ru она не требуется - это вам не 1С8, которая открывает по 600 файлов на каждого подключенного к серверу пользователя - у Smeta.ru вся база лежит в 1 файле, Fireberd выполняет все клиент-серверные операции с базой не требуя при этом от операционки ни каких серверных возможностей. Единственное что может потребоваться так это не менее 2Гб ОЗУ под сам Fireberd, так как во время работы с большой базой (объем файла базы 8 Гб) процесс fbserver реально отбирает до 2 Гб ОЗУ.

Что касается конфигурации Firebird в Classic Server, то применять ее не рекомендую, так как в случае некорректного завершения работы любого пользователя на сервере останется висеть процесс fbserver и сам он не закроется.
Таким образом на сервере будут скапливаться множество процессов fbserver, часть из которых рабочие, часть оставшиеся после некорректного выхода пользователей. А вам оно надо? Хочется закрвыать процессы вручную? Мне кажется лучше не использовать Classic Server, тогда вмешиваться в работу сервера не потребуется - поставил и забыл. В обычной конфигурации, на сервере запущен один процесс fbserver, и он будет задействовать только одно ядро процессора. Процессор на сервере все равно даже на одном ядре справляется и по большей мере простаивает, то есть не требуется реальной многопроцессорности, так как запись все равно идет в один файл базы данных, и если и приходится ждать, то только потому что жесткий диск тормозит всех пока идет обращение к файлу базы данных.

А теперь вы представьте, что будет если вы повесите на одном сервере еще и пользователей в терминале - жесткий диск должен будет на всех успеть, быстрее вся система от этого работать явно не станет!
По моему лучше будет если у каждого клиента свой системник со своим жестким диском, а на сервере диск используется только для сервера. Тогда производительность всей системы будет выше.

**olhovik** Пт Фев 19, 2010 16:23

aivt писал(а):Во всей вашей истории есть одно узкое место - жесткий диск.
А теперь вы представьте, что будет если вы повесите на одном сервере еще и пользователей в терминале - жесткий диск должен будет на всех успеть, быстрее вся система от этого работать явно не станет!
По моему лучше будет если у каждого клиента свой системник со своим жестким диском, а на сервере диск используется только для сервера. Тогда производительность всей системы будет выше.

Ок, буду думать. Хотелось бы вот что: мы новых сметчиков разместим в другом офисе. Надо что бы они помогали друг другу работать со сметами, т.е. работали в одной базе. Я представлял это так: офисы подключены по vpn, бухи и сметчики работают в терминале. Т.е. сервер неплохой под 1С по любому будет. Хотел ту да же и сметчиков. Но теперь буду думать и пробовать, тут действительно много соображений появляется, спасибо за информацию для размышления. У меня для удалённых пользователей узким местом будет канал до сервера. Да и некоторые хотят из дома работать.

**Шуруп** Пт Фев 19, 2010 18:21

Дополню свои соображения. Самая большая засада, при терминальном режиме - вывод документа в Эксель. Как ты не организуй "сетевую" работу на терминале, а вывод в Excel все равно токмо через единый файлик main.xls в клиентской дирректории. А excel второго пущает только на просмотр.

Выход. на терминале ставить 5 программ в разные каталоги, которые будут обращаться к обной базе. Не забудте и о том, что пользователи у этих программ должны быть разные -база-то одна!

**aivt** Пт Фев 19, 2010 18:47

Ок, буду думать. Хотелось бы вот что: мы новых сметчиков разместим в другом офисе. Надо что бы они помогали друг другу работать со сметами, т.е. работали в одной базе. Я представлял это так: офисы подключены по vpn, бухи и сметчики работают в терминале. Т.е. сервер неплохой под 1С по любому будет. Хотел ту да же и сметчиков. Но теперь буду думать и пробовать, тут действительно много соображений появляется, спасибо за информацию для размышления. У меня для удалённых пользователей узким местом будет канал до сервера. Да и некоторые хотят из дома работать.

На тот же сервер где будет сидеть 1С ставить Smeta.ru точно не следует - лучше поставить под Smeta.ru отдельный не очень навороченный системный блок.