<по просьбе Tygra пост отредактирован модератором и представлен в новой редакции>

bantikЭто означает - что в среднем, на числе одновременно работающих
пользователей около ~200-300 наступает кирдык классической архитектуре
клиент-сервер.
Ну, как так? Обсуждали тут в некоторых "интересных" топиках про такое -
3-tier своими
руками и
БОЛЬШОЙ
ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL) никак так не получается. У многих
все хорошо работает, кирдыков не замечается :)

авторЕсли все написано на хранимых процедурах - то ресурсы
процессора начинают расходоваться на интерпретацию каждого скрипта,
вместо того чтобы заниматься непосредственно добавлением и извлечением
данных .
Ну как так, ну... СУБД это только хранилище данных - для 1С понятно , но
вообще то восем не так.
автор В принципе за счет оптимизации процедур
Дык оптимизация процедур это обязательное действие на любых системах,
более-менее испытывающих нагрузку.

автор, выноса логики на клиента (да Visual Basic),
Ну об этом в тех же топиках и где-то еще (не нашкл что-то:)) был горячий
разговор. Большинство считает, что нельзя так делать. Да и не поможет

автор кеширования можно поднять этот потолок до ~ 700 пользователей.
Но скорость упадет.
А вы хотели, чтобы скорость не падала? Чем больше юзеров, тем меньше
скорость (на одинаковом железе).

авторДальше ждет засада с увеличением времени отклика, SQL
"версионники" начинают нелинейно захватывать ресурсы (Oracle) ,
"неверсионники" - путатся во взаимных блокировках.
Так уже же вроде соптимизировали ХП - тогда ничего не должно путаться.

автор Не говоря уже о том, что обычно ~1000 пользователей как
правило подразумевает и другую интенсивность ввода информации и объем базы
данных. Это оперативная база уже может зашкалить за 1 ТБ - а с большими
таблицами тоже уметь работать нужно.
Боязнь больших объемов?
Ну бывают большие объемы - правда зависит от архитектуры. Можно лишние
объемы отдельно складывать, можно ... еще много чего, разные методы есть.
Это не проблема в принципе

авторЛечится дорого - апргрейдом техники.
А вы небось на PIII хотели чтобы все работало? С 128 метров памяти..
Дешевого то апгрейда не бывает, а система должна работать при необходимой
нагрузке. Для чего тогда HP сервера выпускает? :)
Вот мы тоже недавно проапгрейдились - эх, хорошо стало! Станет плохо - еще
проапгрейдимся. Не надо этого бояться - надо тольео поставщиков правильно
выбирать, а то блин....

авторВон Сбербанк для расчетной системы поставил машину из TOP500
tpc - а производительность около 500 тыс документов в час всего.
А как мерили? А вдруг больше бывает - если работников больше и клиентов. А
много это или мало? Хватает сберу столько или нет? А может можно выжать
больше. Соптимизировать чего - а то бывало, в разы разница получается.

авторДругие производители софта тоже вынуждают под свои задачи
закупать сервера с шести-семизначными ценами. Для МТС по-моему даже стену
разбирали - чтобы SUN для билинговой системы проапргрейдить.
Ну а как же иначе?

авторПоэтому не нужно обманыватья - такие "болезни роста" есть и у
нас, и (особенно) у зарубежных систем.
???

авторНовые решения на серверах транзакций или 3-уровневой
архитектуре - которые с легкостью вытянут и до сотни тысяч пользователей в
on-line только только появляются и пока "пилотируются".
Сотни тысяч пользователей!!!! Это как так!!!
Или для много-звенки конечно технику мощную не нужно - пару 486 сойдет, да
еще к тому же она СУБД не использует... В общем, сотни тысяч потянет вообще
без коомпьютеров, оптимизации, настройки и т.д. Понятно понятно... :)
Те же топики, что выше упомянуты, очень сильно задевали вопрос про
многозвенки. Итог тут не скажу - только там, здесь разговор о другом.

авторОтечественные разработчики, в силу относительной дешевизны
рабочей силы и типичной русской "безбашенности" - уже начинают выходить на
этот этап.
Конечно, если зарубежное - значит круто, если наше - ..... Про Галактику,
Босс - согласен. но есть много собственных разработок, которые и западным в
ровень будут. Да и опыт то не сравнить..

авторНу а зарубежные вполне понятно, что заинтересованы отбивать
инвестиции на старые разработки...
Ну конечно - рынок как никак :) И наши так же делают.

За что же так к-с системы то не любят???

Может кто и не видел. но бывают к-с системы правильные, которые сделаны
правильно, которые спроектированы правильно, которые работают вследствие
всего этого правильно, быстро, для многих клиентов и т.д. и т.п.
И бывают другие системы, которые проектировали тоже правильно.
Но бывают и те, и другие, которые проектировали .... очень плохо :) и ... в
общем в которых все очень плохо (например 1С, например версия 7 под SQL) :))

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

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

--
Tygra's
--

2 bantik
Извиняюсь за свой пред-предыдущий пост - не хотел обидеть, честно. Да и к вам лично нет никаких претензий - отвечаю то на утверждения, а получается... Мда.

Остаточные явления от обсуждений тех двух топиков :). И характер, чтоб его...

-- Tygra's --

2 bantik

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

Наезды согласен обмыть в соответствующем заведении :)

авторЯ сам до этого вынужденно дошел. Поскольку на сервере миллион процессоров не поставишь. Например на Intel архитектуре человеческая цена кончается на 8-ми процессорном Xeon. А еще есть ограничения по шине и 32-разрядности (до 10G/s) . На такой машине в клиент сервере у нас получалось до 1 млн конвейерных документов в час (в таблицу документов запихивали поштучно)
Мда, сами недавно покупали 8хXeon - точно, цены дальше.... Епрст.
Ну да, если 1 млн в час это мало, то.... Дааааа!

авторА вот серверов приложений можно в slim исполнении закупить десяток,
Это точно
авторсвязать их с СУБД скоростным каналом - и с легкостью довести производительность до требуемой. В конфигурации 8*1 серверов приложений + 2*Xeon MS SQL у нас получалось до 6 млн. документов в секунду (тоже конвейер) Но в отличие от первого количество пользователей доводилось до тысячи и время отклика не увеличивалось
Получается, что MS SQL использовался только для записи/хранения данных? И только такие операции он выполнял? И так сильно выросла производительность? Да, неплохо!
А Оракл с его кластерами не пробовали использовать? Может тоже помогло бы? Я вот хотел бы попробовать, да не работаем с Ораклом мы :)

авторОптимизируем - но каждый select шлифовать очень напряжно, особенно в условиях неопределенной статистики. Это очень дорого - заново просматривать все хранимые процедуры при изменении версии продукта или структуры данных.
Ну а мы шлифуем :) Там где появляются тормоза - остальное не трогаем

авторНе боязнь, а опасение :-) Поскольку за большими объемами пойдут и обеспечение безопасности, и время поднятия/опускания дампа, и место под архивы. Есть такая СУБД - Terradata - так там столько фенек для террабайтных баз понакрутили - и Oracle, и DB2, и Sybase и MS SQL могут отдыхать. Но увы - эта база и непопулярна и недешева.
Ну да, но я и говорил, что можно большие объемы разделить например

авторЧитаем - обманывают, гады :-) как говорят кто не умеет работать и учить - пишет книги.
Про книги это точно, я маху дал - книги лучше не читать такие, да их правда других хороших то и нет :)

авторМне лично нужно не менее 20 млн документов в час на железке не дороже $100 тыс и на 5 тыс пользователей. Вот хочу и все...
Да, хороши запросы

Да, похоже что в данной ситуации, если действительно перенос логики на средний слой и разгрузка БД до только операций записи/селекта дает такие результаты и подъем производительности, никуда от апп-сервера не уйдешь.
Вот он, пример случая, когда апп-сервер необходим. Мне так кажется :)
Не, конечно можно купить железо под СУБД и мощнее, и еще мощнее.... Но что-то дорого

Хотя может у кого такая производительность и без среднего слоя достигается?

-- Tygra's --

2 guest4321

А вы не использовали Оракловый кластер? Если да, как оно?
Интересно, только вот не на чем пробовать

-- Tygra's --