Доброго времени суток !

А. К спору о СЕРВЕРАХ

Многие спорят какой процент серверов работает на винде какой на юнихах. Одни кричат, что рулит винда, другие, что юнихи. Спорить не буду, но приведу небольшое сравнение: на винде работают только Х86-тые (алфа не всчет так как очень маленький % выпуска и к томуже не все на винде), на юнихах SUN;DEC;IBM;SGI;HP и небольшой процент Х86-тых (на вскидку больше сразу не припомнил ). Могут сказать, что перечисленные компании выпускают мало машин, но каждая из них — это мультимиллиардная корпорация. Если машин мало, тогда позвольте спросить начемже они заработали деньги ?
Теперь мое мнение о серверах на винде. Начнем сначала, сервер — это компъютер который отдает свой ресурс (файловую систему, вычислительный, сетевой и т.д.) клиентам. Винда сама посебе ОЧЕНЬ ресурсоемкая система, тоесть большой (относительно)% ресурса (за который кстати плочены деньги) потребляет ситема на собственные нужды. Но какже так я покупал сервер для того чтобы он обрабатывал мою базу данных, монитор с него вообще убрал, а он держит в памяти всю графическую систему винды (на кой она мне сдалась не понятно), запущеннй RPC (а он зачем непонять) и кучу других сервисов необходимых для работы ситемы, которые мне и нать-ненать. С другой стороны я ставлю FreeBSD (ядро и минимальный набор утелит и сервисов), устанавливаб сервер баз данных после чего на загрузку оставляю только ядро, TCP/IP и сервер баз данных(даже виртуальные консоли не гружу). И очудо оказывается пенек даже первый с 64-мя мегами на борту нетакая уж плохая машина и все наней просто летает. Чтобы получить такоеже быстродействие на винде НТ4 сервер потребуется минимум пенек второй и 128 метров мозгов. Конечно скажут, что и пенек 1 и пенек 2 — это уже история, но и винда НТ4 — тоже история(желающие могут для себя построить к современным машинам аналогию).
Теперь о работе на одном сервере нескольких клиентов. Пустой цикл создает на винде загрузку процессора 100% (кто сомневается может написать на Си программу int i=1; while(i1==i1){i1++;i1--;} и глянуть на загрузку проца). Тоесть написание циклов требует внимания програмистов. Пример у нас в конторе стояла 1С Предприятие в винтерминале, несколько клиентов, проблема была втом, что когда один изних формировал какойто отчет у всех остальных чтоб они не делали (кто в ворде сидел кто в экселе) машина тормозила безбожно. Правда проблема решилась просто: поставили двухпроцессорную мать и два проца, в этом случае выше указаный глюк винды лечится(почему незнаю толи изза другого ядра толи еще изза чего).

ЗЫ: Впринципе найдутся люди которые скажут: ну и что, а мне всеравно нравится !


Б. О инструментах программистов.

Читая форум, нарвался на топик http://www.rsdn.ru/Forum/Message.aspx?mid=953877&only=1. Человек утверждает, что инструмент навязывают(типа все платят за C# или Java). Ну вопервых построение любой программы начинается с определения задачи, планирования задачи(если необходимо превлекаются специ по данной задаче: математики, бухгалтера, экономисты, физики и т.д.), разбиение крупных задач на более мелкие, если необходимо те еще мельче и т.д. Далее идет распределение задач между програмистами, с описанием входных и выходных параметров. Каждый програмист пишет свою маленькую и простую задачку, четко перед ним определенную(в принципе процес перевода задачи в код).После чего все это дело как из кубиков собирается в общий проэкт и получается большая, сложная и страшная програмище . Это я конечно описал в общих чертах насамом деле там еще работают художники, дезайнеры, разработчики интефейса, и т.д. вобщем народу много. Так вот для чего я все это писал, если так подходить к написанию програм то писать можно хоть в асме. Причем написание на асме будет не сложнее чем на C# и не намного трудоемнее. Это был один из примеров построения програм. Теперь о програмистах. К утверждению что програмистам пишущим на асме тяжелей найти работу чем пишущим на C#. Давайте посмотрим вокруг себя и что мы видим ? А видим мы кучу бытовых электронных умных цацок (кстате на них народ выбрасывает КУЧУ денег)телефоны, телевизоры, автомобили, микроволновки и т.д. И в каждой этой игрушке есть контроллер который програмировался можете мне поверить не на C# и не на Java, а именно на том самом асме или если контролер мощный то в лучшем случае на С. Так вот програмисты которые пишут подобные програмы зарабатывают намного больше чем те которые пишут на C# или Java. И на крупных конторах которые занимаются разработкой всевозможны автоматических узлов, если такой спец появляется то его могут нанять даже если нет вакансии, так сказать прозапас. Потому что пацанов которые виртуозно двигают мышку по экрану, море, а вот таких програмистов — автоматчиков как надо будет не найдеш.


ЗЫ: Конечно не все аспекты осветил того что хотел сказать, но хоть немного душу излил.

С уважением Валерий.

Здравствуйте, sva1509, Вы писали:

S>Доброго времени суток !

S> Б. О инструментах программистов.

S> Читая форум, нарвался на топик http://www.rsdn.ru/Forum/Message.aspx?mid=953877&only=1. Давайте посмотрим вокруг себя и что мы видим ? А видим мы кучу бытовых электронных умных цацок (кстате на них народ выбрасывает КУЧУ денег)телефоны, телевизоры, автомобили, микроволновки и т.д. И в каждой этой игрушке есть контроллер который програмировался можете мне поверить не на C# и не на Java, а именно на том самом асме или если контролер мощный то в лучшем случае на С.

Все эти электронные хахаряшки производятся за пределами России, поэтому и программировать их приходится там же. Вопрос в том, что далеко не все могут(хотят?) уезжать — H1B за один день кончаются и т.п.
Кроме того, потребность в таком программировании на несколько порядков меньше если сравнивать с прикладным программированием на C# и Java

Здравствуйте, henson, Вы писали:


H>Все эти электронные хахаряшки производятся за пределами России, поэтому и программировать их приходится там же. Вопрос в том, что далеко не все могут(хотят?) уезжать — H1B за один день кончаются и т.п.
H>Кроме того, потребность в таком программировании на несколько порядков меньше если сравнивать с прикладным программированием на C# и Java

1) Я не согласен что это все за пределами России. Если вы человек в погонах, то я вас уверяю что системы наведения; системы управления огнем и прочих интересных цацок которых в России выпускается достаточно, не в США программирут. Далее если туда устроится нет возможности, то с России выпускают станки с ЧПУ и прочие производственные радости жизни и кстати ДАЛЕКО не худшего качества. Програмирование контролеров автомобилей тоже не худший вариант — напишиш пару прошивочек тюнинговых ~$3000 в месяц худо-бедно нашкребеш. + В России начинает появлятся и своя бытовая продукция, особенно в таких городах как Питер, Москва. К примеру LCard, как-то у них на форуме было объявление "требуется" с неплохими параметрами. Так что опытному программисту-автоматчику работа всегда найдется.
2) А чаще бывает работа есть, а пойди сейчас найди программиста-автоматчика. ВУЗы наких нынче не делают(по крайней мере если и делают то очень не много и таких вузов может на всю Россию 1-2), материальная база не позволяет, пример : подготовить программистов на C# — купил компъютерный клас за 20т баксов и готовь себе насыпом, через 4 года компы устарели купи новый класс и опять готовь. А станок с ЧПУ один от 500т и в гору, особо классами готовить не разгонишся, а менять их нужно где-то также. В советские времена хорошо было большой завод и при нем ВУЗ завод себе технику набирает и ВУЗу одбрасывает, чтоб спецов готовил. В Николаеве несколько лет назад снова запустился турбинный завод "Зоря". Так спецов нанимали аж из прекрасного далека потому как свои по рынкам разбежались или за бугор уехали вобщем из бывших системщиков никого найти не удалось.

С уважением Валерий.

>Давайте посмотрим вокруг себя и что мы видим ? А видим мы кучу бытовых электронных умных цацок (кстате на них народ выбрасывает КУЧУ денег)телефоны, телевизоры, автомобили, микроволновки и т.д. И в каждой этой игрушке есть контроллер который програмировался можете мне поверить не на C# и не на Java, а именно на том самом асме или если контролер мощный то в лучшем случае на С.

Вот этого не надо, на асме или С пишется только ОС, а софт, как правило, на Java. Те же сотовые или палмы посмотрите.

Про ресурсоёмкость винды. Знаете, есть абсолтные и относительные издержки. Расходы винды на GUI — это абсолютные, их влияние уменьшается по мере роста производительности систем.
Далее. FreeBSD — отличное решение, когда нужно сделать небольшой сервер: web или файлопомойку, шлюй и файрвол. Но при создании ERP-систем и бизнес-решений на первый план выходят другие проблемы: интеграция систем и приложений, обмен данными, стандартизация интерфейсов и пр. А вот тут у юниксов туго. Средств интеграции приложений — практически никаких (ну, пайпы не в счёт). Зато в винде MSSQL, Access, Visio, MS Office, Exchange, Active Directory, ASP (.NET) взаимопроникают, интегрируются и взаимодействуют. А вот юникс — это система одного приложения. Т.е. сделать терминал в регистратуре — отлично. Сделать WEB-сервер и вылизать его в плане производительности — самое оно. А вот сделать интегрированное решение — увы.

Здравствуйте, sva1509, Вы писали:

S> Теперь о работе на одном сервере нескольких клиентов. Пустой цикл создает на винде загрузку процессора 100% (кто сомневается может написать на Си программу int i=1; while(i1==i1){i1++;i1--;} и глянуть на загрузку проца). Тоесть написание циклов требует внимания програмистов.
Я правильно понял, что юникс вполнит этот цикл за 1 секунду? Или ты к чему это написал?

Здравствуйте, sva1509, Вы писали:

S> Теперь о работе на одном сервере нескольких клиентов. Пустой цикл создает на винде загрузку процессора 100% (кто сомневается может написать на Си программу int i=1; while(i1==i1){i1++;i1--;} и глянуть на загрузку проца).

Ну а что неправильно ? Если запустить 2 такие программы, каждая будет загружать процессор на 50%. Три — каждая на 30%. Вроде всё правильно.
А как на Unix'ах? Там что процессор вместо того, чтобы работать на 100% над задачей даёт задаче только n% ? А остальные n% ничего не делает ?

Здравствуйте, Евгений Коробко, Вы писали:


ЕК>Про ресурсоёмкость винды. Знаете, есть абсолтные и относительные издержки. Расходы винды на GUI — это абсолютные, их влияние уменьшается по мере роста производительности систем.

По мере роста производительности систем, идет увеличение ресурсоемкости.
Пример:Longhorn, я эту штуковину инстальнул на пенек 4 3Мгц 512М мозгов. Впечатление создалось, что эта штука никогда не загрузится. После загрузки каждое движение окон отзывалось тарахтением винта и жуткими тормозами.
Короче впечетление такое как будто на 386 с 8М мозгов винду 95 поставили.
А под UNIX (FreeBSD,Solaris,SCO) на такой тачке у меня ТАКОЙ бы сервер баз данных получился !


ЕК>Далее. FreeBSD — отличное решение, когда нужно сделать небольшой сервер: web или файлопомойку, шлюй и файрвол. Но при создании ERP-систем и бизнес-решений на первый план выходят другие проблемы: интеграция систем и приложений, обмен данными, стандартизация интерфейсов и пр. А вот тут у юниксов туго. Средств интеграции приложений — практически никаких (ну, пайпы не в счёт). Зато в винде MSSQL, Access, Visio, MS Office, Exchange, Active Directory, ASP (.NET) взаимопроникают, интегрируются и взаимодействуют. А вот юникс — это система одного приложения. Т.е. сделать терминал в регистратуре — отлично. Сделать WEB-сервер и вылизать его в плане производительности — самое оно. А вот сделать интегрированное решение — увы.

Интеграция о которой вы пишите — это технология DCOM. DCOM-в свою очередь это ООП оболочка служды RPC, а RPC — всвою очереди вещь спертая мелкомягкими у юниха. Так что интеграция на юнехе штука давно работающая, правда без ООП оболочки.

ЗЫ: Кстати вы о таком проекте бизнес интеграции Tarantella вы не слышали ? Под юних пашет.

С уважением Валерий.

Здравствуйте, Евгений Коробко, Вы писали:

>>Давайте посмотрим вокруг себя и что мы видим ? А видим мы кучу бытовых электронных умных цацок (кстате на них народ выбрасывает КУЧУ денег)телефоны, телевизоры, автомобили, микроволновки и т.д. И в каждой этой игрушке есть контроллер который програмировался можете мне поверить не на C# и не на Java, а именно на том самом асме или если контролер мощный то в лучшем случае на С.

ЕК>Вот этого не надо, на асме или С пишется только ОС, а софт, как правило, на Java. Те же сотовые или палмы посмотрите.

ОС — это уже более высокий уровень. Микропрограммное обеспечение для всяких контроллеров и т.п. девайсов пишется (точнее генериться из спецификаций на SDL/UML/ASN.1/TTCN/etc) либо на С либо на проприетарных языках изобретенных фирмами-производителями. Я это знаю, т.к. мы CASE средства соответствующие делаем.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, sva1509, Вы писали:

S>> Теперь о работе на одном сервере нескольких клиентов. Пустой цикл создает на винде загрузку процессора 100% (кто сомневается может написать на Си программу int i=1; while(i1==i1){i1++;i1--;} и глянуть на загрузку проца). Тоесть написание циклов требует внимания програмистов.
S>Я правильно понял, что юникс вполнит этот цикл за 1 секунду? Или ты к чему это написал?

Причем здесь 1с ? У системы должно быть четкое разделение времени. Я приводил пример того как операционная система не справляется с контролем исполняемых задач.
В юнихе при запуске этой программы вы никаких загрузок не увидете. И вообще ее работа на системе никак не отразится.

С уважением Валерий.

Здравствуйте, Sergey J. A., Вы писали:

SJA>Ну а что неправильно ? Если запустить 2 такие программы, каждая будет загружать процессор на 50%. Три — каждая на 30%. Вроде всё правильно.
SJA>А как на Unix'ах? Там что процессор вместо того, чтобы работать на 100% над задачей даёт задаче только n% ? А остальные n% ничего не делает ?

В нормальной ОС, темболее претендующей на серверную, один процесс никак не должен влиять на другой. Тем более на работу системы.

С уважением Валерий.

Здравствуйте, sva1509, Вы писали:

S>В нормальной ОС, темболее претендующей на серверную, один процесс никак не должен влиять на другой. Тем более на работу системы.

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

Здравствуйте, sva1509, Вы писали:

хъ

S>Причем здесь 1с ? У системы должно быть четкое разделение времени.

Т.е. Вы утверждаете, что такового разделения нет?

S>Я приводил пример того как операционная система не справляется с контролем исполняемых задач.


А Вы утверждаете, что Юнихе система хрен отдаст процессор такой программе, даже если ей больше (99% idle) делать нечего? Круто, блин.

S>В юнихе при запуске этой программы вы никаких загрузок не увидете. И вообще ее работа на системе никак не отразится.

Странно, у меня вот тоже никак не отражается. Пишу вот это сообщение, рядом крутится пяток таких "программ", полет нормальный...

Здравствуйте, sva1509, Вы писали:

хъ

S>В нормальной ОС, темболее претендующей на серверную, один процесс никак не должен влиять на другой. Тем более на работу системы.

Что значит в Вашем понимании "влиять на работу ситемы"?

Здравствуйте, Patalog, Вы писали:

P>Странно, у меня вот тоже никак не отражается. Пишу вот это сообщение, рядом крутится пяток таких "программ", полет нормальный...

Запустил 1. Съело 50%. 2 — съели 99-100%. 3 — тоже 99-100

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

Проц 2х гигагерцовый.

Здравствуйте, Crab, Вы писали:


C>Запустил 1. Съело 50%. 2 — съели 99-100%. 3 — тоже 99-100

C>При попытке запустить пейтбраш, компьютер долго думал. Пейтбраш запустил, но секунд десять не отрисовывал клиентскую часть. Между апликухами переключаться хреново. Долго думаем....

C>Проц 2х гигагерцовый.

Все правильно. Только я хотел обратить внимание не на ту часть где загрузка 50%-100%, а на ту где "Пейтбраш запустил, но секунд десять не отрисовывал клиентскую часть", на то что "Между апликухами переключаться хреново. Долго думаем...."

На юнихе работа подобных программок на работе системы и других приложений никак не отражается.

С уважением Валерий.

Здравствуйте, Patalog, Вы писали:


S>>В нормальной ОС, темболее претендующей на серверную, один процесс никак не должен влиять на другой. Тем более на работу системы.

P>Что значит в Вашем понимании "влиять на работу ситемы"?

См. выше ответ Crab. Просто чтоб не переписовать.

Здравствуйте, Sergey J. A., Вы писали:

SJA>Смешно. Всем выдавать фиксированный процент процессора, чтоб не было влияний ? Зачем тогда спрашивается выдумывают всякие сложные схемы диспетчеризации потоков ?

Сергей не в обиду вам будет сказано, но вам немешалобы подучить теорию операционных систем. Что такое операционная система, для чего она нужна, какие фудкции должна выполнять.
Так вот процентов процессора не существует. А вот квантование процессов есть. Если распредиление квантов времени между процессами равное без перепадов в большую или меньшую сторону система считается со стабильным распредилением ресурса. А не это ли один из основных критериев сервера ?

ЗЫ: И нестоит забывать что ядро которое занимается распределением — тоже процесс.

С уважением Валерий.

Здравствуйте, sva1509, Вы писали:

S>Сергей не в обиду вам будет сказано, но вам немешалобы подучить теорию операционных систем. Что такое операционная система, для чего она нужна, какие фудкции должна выполнять.
Что советуете прочесть по ОСям ?
кроме прочитанных:
М. Руссинович, Д. Соломон "Inside windows 2000"
Столлингс "Операционные системы"
Дж. Рихтер. "Программирование серверных приложений для Microsoft Windows 2000"
Так же пытаюсь начать книгу Вахалия "UNIX изнутри"

S>Так вот процентов процессора не существует.
Если посчитать сколько кому выдано в итоге, то вполне можно посчитать. Ясное дело шедулер не на проценты ориентируется.
Будете упорствовать — зделаю скриншот Task Manager`а

S>А вот квантование процессов есть. Если распредиление квантов времени между процессами равное без перепадов в большую или меньшую сторону система считается со стабильным распредилением ресурса. А не это ли один из основных критериев сервера ?
А что такое распределение квантов между потоками (кстати в Windows не между процессами !) как не влияние одного процесса на другие ?
Если один процесс имеет больший приоритет и хотит больше процессора — ему дадут его за счёт других, менее приорететных. Или вам это кажется странным ?

S>ЗЫ: И нестоит забывать что ядро которое занимается распределением — тоже процесс.
И что ?

Здравствуйте, Sergey J. A., Вы писали:

SJA> Что советуете прочесть по ОСям ?
SJA>кроме прочитанных:
SJA>М. Руссинович, Д. Соломон "Inside windows 2000"
SJA>Столлингс "Операционные системы"
SJA>Дж. Рихтер. "Программирование серверных приложений для Microsoft Windows 2000"
SJA>Так же пытаюсь начать книгу Вахалия "UNIX изнутри"

Приятно ощатся с начитанным человеком .

S>>Так вот процентов процессора не существует.
SJA>Если посчитать сколько кому выдано в итоге, то вполне можно посчитать. Ясное дело шедулер не на проценты ориентируется.
SJA>Будете упорствовать — зделаю скриншот Task Manager`а

S>>А вот квантование процессов есть. Если распредиление квантов времени между процессами равное без перепадов в большую или меньшую сторону система считается со стабильным распредилением ресурса. А не это ли один из основных критериев сервера ?
SJA>А что такое распределение квантов между потоками (кстати в Windows не между процессами !) как не влияние одного процесса на другие ?
Не важно как это назвали в винде, потому что мы говорим о процессоре. Так вот в книге "Микропроцессор 80386 и его программирование П.Брам Д.Брам" при описании TSS таблици использовался термин процесс, а не поток.
Пример влияния уже приводил отвечая Crab. Посмотрите пожалуйста, надоело набирать.

SJA>Если один процесс имеет больший приоритет и хотит больше процессора — ему дадут его за счёт других, менее приорететных. Или вам это кажется странным ?

Там-же. Процессу паразиту никто никаких приоритетов не давал. С каких делов винда решила, что ему нужен выше приоритет ?

Поразмышляйте над этим и сделайте вывод, просто для самого себя.
Если есть желание по спорить, буду рад выслушать аргументы.

С уважением Валерий.

Здравствуйте, sva1509, Вы писали:

S>Не важно как это назвали в винде, потому что мы говорим о процессоре. Так вот в книге "Микропроцессор 80386 и его программирование П.Брам Д.Брам" при описании TSS таблици использовался термин процесс, а не поток.
Брамов не читал, но во всех прочитанных книгах упоминается процес и поток. Впрочем это не столь суть важно.

SJA>>Если один процесс имеет больший приоритет и хотит больше процессора — ему дадут его за счёт других, менее приорететных. Или вам это кажется странным ?

S>Там-же. Процессу паразиту никто никаких приоритетов не давал. С каких делов винда решила, что ему нужен выше приоритет ?
Я имел в виду, что фраза

В нормальной ОС, темболее претендующей на серверную, один процесс никак не должен влиять на другой.

не совсем верная как я её понимаю. Все потоки влияют друг на друга. Если запущен поток с более высоким приоритетом, то он явно повлияет на процессорное время выделяемое другим потокам. И это правильно.
Насчёт проблем с paint'ом не буду спорить. Возможно виндовый шедулер хуже Unix'овых, а может нет. Вот прочту Вахалия тогда может смогу что-то сравнивать...