Сервер:
Процессор 3.0 Ггц
ОЗУ - 4 Гб
ОСь - Win Ser 2003
Какое примерно количество юзверей могут работать одновременно в  dbf базе без тупняков и какое количество в SQL? Подскажите пожалуйста

примерно

если учитывать что КПД у юзверей высокий

(2) хорошо сказал)

Один точно сможет. Больше - нужно смотреть, что за база, что они там делают

(4) ну а если к примеру 7 человек

(5)
Летят в самолете Петька и Василий Иванович, Василий Иванович спрашивает: — Петька, приборы! Петька отвечает: — 200! Василий Иванович: — А что 200? Петька: А что приборы?

(5) 80

(6) ну это понятно)) я ж говорю, если учитывать что работают с максимальной нагрузкой для базы, все одновременно вводят счета, расходные-приходные...

типовая Тис

(8) 82

(9) 5х потянет dbf, рыл 9 скуль. Дальше только оптимизация

а где терминал?

(11) а как понять оптимизация? (12) терминал не в локальной сети

(13) Прямые запросы, распределенная бд

(13) так он присутствует?! Тогда всех переводи и будет тебе счастье

(14) спасибо, теперь понятно... (15) да, терминал есть... а что разве не одно и тоже что по локальной сети что в терминале?

(16) нееееееееее, терминал круче!!!

(17) чем? не могу понять))

(18) Не открывается куча файлов по сети, нет огромного трафика, пониженные требования к качеству сетки ...
Терминал однозначно. Всех в терминал

(18) ты хочешь быстро работать? Терминал наше все!

(18) представь, ты смотришь картинку на своем мониторе, а обработка данных происходит на сервере.

(19)(20) я вам верю, и так и сделаю все)) но до этого я был уверен что 5 юзверей по локальной и 5 в терминале это одна и та же скорость работы.

(21) но обработка данных не только ж моя, а всех 5 рыл одновременно, как и в локальной

(22) мир не идеален ;)

(23) 82

(24)(25) я понял что в терминале быстрее. Не понял только почему

если в локальной за тем компом, на котором база никто не работает, то какая разница?

(26) я тебе в (21) объяснил.

в терминале картинка)) а в локальной нету картинки, у каждого установлена своя программа

(27) Прикинь, ты смотришь телевизор, наслаждаешься, а на другой стороне экрана люди вкалывают, много людей, а ты балдеешь.

(30) блестящее сравнение!

(29) Ты же обращаешься к базе данных по сетке, сеть имеет свою пропускную способность.

(26) Ну смотри
по сети:
1. Запрос итогов при проведении документа.
2. Пауза на трансфер данных на локальную машину.
3. Обработка итогов.
4. Пауза на обновление БД

в терминале:
1. Запрос итогов при проведении документа.
2. Обработка итогов.
3. Обновление БД.

терминал - по сути локальная работа с базой для всех подключенных ...

(32) да, точно))

(8) Если у тебя винты будут IDE то и 10 человек со скрипом

(33) Спасибо за обьяснение

(18) По сети винда отключает кэширование дисков и начинает дико тормозить. А в терминале всё хорошо. Быстро и шустро

(26) Если без заморочек: 1С научилась только к 8.2 версии (тонкий клиент) таскать из базы строго те данные, которые нужны для конкретного случая, а ранние версии таскаю по сети "всю базу".

(36) вообще, пользователей может быть гораздо больше, чем 5 или 9, но молотить без тормозов они не смогут.
Т.е. блокировки транзакций и тому подобными радости видишь?

Так вот они начинаются гораздо раньше, когда пользователи работают с базой по сети. Если по сети в SQL, то позже хотя все равно блокировки работу тормозят, но стабильность SQL-базы на порядок выше - если смотреть со стороны пользователей, то нет постоянной выдачи запросов на реиндексацию.

Работа с базой в дбф сессиях в терминале снимает прежде всего ограничения сетевого протокола. Ты сам это можешь очень легко оттестировать выполняя одни и те же действия с сеансах на сервере (либо хост-машине, где лежит каталог с базой) и на любой другой машине по сети.

(37)(38)(39) то есть если даже терминал находится в локальной сети, и ни у одного пользователя не будет интернета в скорости все равно можно выиграть?

(40) а интернет зачем?

(41) предположим, я для общего развития

(42) вопрос не понятен.

(43) ну допустим терминальный доступ осуществляется без участия интернета, по обычной локальной сети. Быстрее ли будет скорость работы пользователей, чем просто будет компьютер с расшареной базой

(40) если на пользовательских машинах есть доступ к инету, то соответственно работает и антивирус, так ведь?

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

(44) Работа с клиентской машины с расшаренной папкой по локальной сети происходит по протоколам samba. В протоколе прописывается очень много всякого, но прежде всего под MS Windows жестко прошиты таймауты при обращениях файлам и файловым таблицам. Именно эти ограничения снимаются в первую очередь при запуске терминальной сессии вместо доступа к базе по сети. Это для файловой версии.

(44) Локальная сеть заведомо медленнее работает, чем файловая система сервера.

(45)(46) спасибо огромное, все уяснил для себя!

а в 8.2 тонкий клиент даже по сети стало быть будет работать быстрее, а в терминале тем более

быстрее чем клюшка

(49) Нет

(50) почему?

(51) Иногда надо просто верить

(52) я вам верю... но если бы еще и знать почему! наверняка из-за своей большей функциональности  проигрывает в скорости

(53) Ну вот смотри V7: последний релиз 7.70.027 - надежный, стабильный поэтому 100 лет не выпускаются патчи.
V8: последний релиз 8.2 8.2.17.159 (вроде), релизы клепаются чуть ли не раз в неделю, о какой стабильности и скорости можно говорить ? ;)

(54) так я не знаю что делать вообще... с одной стороны говорят что клюшка уже свое отжила, мол будущее за восьмеркой, но в плане практичности все равно выходит клюшка лучше

(55) А чего добиться хочешь ?

если переписать 7.7 на прямые запросы в SQL, а формы использовать просто как оболочку - то много

(0) пальцем в небо тыкни. не промахнешься

если запилить прямые запросы где только можно, то 50 юзеров можно

(59) пессссссссимист....

(60) да ну, в жопу клюшки с её 1сжурнал.дбф

(55)Некоторые до сих пор работают на 6-ке. Доступно и всерьез. А главное - быстро.

(2) смотря что они будут делать, могут 2 человека мешать друг другу, а могут 200 спокойно сосушествовать

(63) к сожалению, в 7.7 одна таблица, пресловутый общий журнал, в который все упирается.

(64) Гибких блокировок, скажем, в разрезе складов там сделать вообще никак нельзя???

(65) а в той таблице, ЕМНИП вообще никаких реквизитов нету :) только если по виду документа

(0) Есть ограничение на количество открытых фалов.

Т.е. допустим в базе 200 файлов дбф и их открыли 20 юзеров итого 4000 открытых фалов.

Не все такое потянут.

(66) мне до боли интересно, в 7.7 хоть каким-нибудь обходным путем можно левое/полное соединение в запросе сделать Как сделать аналог левого соединения в 7.7? ?

(68) 1с++ и делай какое надо соединение. в стандартных запросах было слово ВСЕ

Давно это было, но типа
Период с ВыбНачПериода по ВыбКонПериода;
|Аналитика1 = Регистр.МойРегистр.Аналитика1, Справочник.Аналитика1.ТекущийДокумент ВСЕ;
|Аналитика2 = Регистр.МойРегистр.Аналитика2;
|Функция КоличествоРасход = Расход(Количество);

(69) Это да, ВСЕ позволяет в 8-ке сделать левое и полное соединение с условием. Но вот ещё вопрос: есть ли способ в 7.7-запросе отличить что присутствует в только в левой, что только в правой, а что в обеих таблицах? Вам же ни NULL, ни ВЫБОР нету, как я помню.

+(71) >вам же
там же

(70) Аааааа... До меня начинает доходить.

(73) все равно эти запросы - муть. такой ужас генерят, если  в профайлер глянуть

(74) Спасибо! С (68) теперь понятно.

(2) КПД у юзверей не может быть высоким по определению.

Безо всякой оптимизации и прочей херни, при правильной организации эксплуатации 1С такая конфига железа в терминальном режиме не аДБФе потянет 30 юзверей как два пальца об асфальт и даже не вспотеет.

Работало человек 50 на СКЛ без всяких оптимизаций, наоборот одни тупняки были
С оптимизацией и приличной нагузкой на СКЛ было около 100 чел. без проблем с блокировками и тормозами
Если использовать гибкие блокировки можно насажать и 500 человек

(78) КЦ, тупняки в основном в каких местах были?

(0) На нетварь положи базу, если локалка так уж критична. Если нет то в терминал загоняй аленей.
(78) Ну про 500 я сильно очень сомневаюсь. Именно на клюшках. Хотя если только будут картинку смотреть и ничего неделать, то может и 500 влезет. Смотря как трамбовать ...

ну.. с учетом того что в шттаной тис юзверь штатно отжирает порядка 70Мб - то может и влезть...

(0) Я знаю точный ответ!
Максимальное количество пользователей будет равняться количеству лицензий. :)
гы-гы-гы....

(79) Блокировка журнала конечно.
Потом начал оптимизировать, т.к. разрастался функционал и пользователи начали удваиваться.
Начались блокировки констант. Это победил своей регистрацией объектов для МОДа.

(80) 750 видел внедрение. Спроси у МуМу.

(77) ДАЖЕ ТАК.....

(85) угу, и даже больше - все зависит от знаний и частных случаев.

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

дбф ? 30 юзеров ? без допиливания ?

(88) возможно, какие-то допиливания и будут, но это будут допиливания, не затрагивающие основные механизмы.
.
Ликвидируй при штатной работе проведение документов задним числом - и снимается львиная доля проблем.

(88) а чем тебя 30 юзеров пугают? как вариант, если они просто откроют программу и будут на ней в отчеты смотреть ты же поверишь, что и больше можно.

(30) вряд ли 30 юзеров генерять вручную такой потко данных что ежеминутно в транзакцию вываливаются доки по 500 строк...