|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
just_nick GeenS2just_nick Признателен за трезвый расчет. ... 3) Расчеты приблизительно совпадают с оценками некой иностранной фирмы, которая предложила ОЧЕНЬ ДОРОГОЙ проект для такого же решения. Наши обещают дешевле - думаю, что брешут, собаки... ... Блин - кто бы тогда взял меня в консалтеры, раз я так хорошо считаю? Хочется поработать с действительно крупными системами... Согласен в Краснодарэнерго, раз уж его Карклинь упоминал его несколько раз. Или раз Вы сказали про "в сторону юга" - то Ростов бы вообще идеально подошел - и переезжать бы не пришлось! РОСТОВЧАНИН? а-ха... уже теплее во всех смыслах... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 09:39 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
GeenSРОСТОВЧАНИН? а-ха... уже теплее во всех смыслах...он самый... "жить ведь где-то надо"(с) Вам тут сотрудники не нужны? ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 09:56 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
GeenS Для систем такого масштаба существует стандартное решение: 1. 1 сервер БД без(почти) бизнес логики 2. N серверов приложений с бизнес логики 3. терминалы или веб доступ к 2 масштабируемость за счет числа N и числа процессоров на 1. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 10:18 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
модДля систем такого масштаба существует стандартное решение: 1. 1 сервер БД без(почти) бизнес логики 2. N серверов приложений с бизнес логики 3. терминалы или веб доступ к 2 масштабируемость за счет числа N и числа процессоров на 1. Исчо один... Только вчера на аналогичное "решение" отвечал... Если ОДИН сервер СУБД не справляется с нагрузкой от большого числа пользователей, то мы между ним и пользователями поставим ЕЩЕ ОДИН СЕРВЕР (несколько), который решит эти проблемы? Бред... И, простите, в приведенном варианте решения серверу СУБД только процессоры нужны? А дисковое пространство? А память? Таким образом, дабы действительно что-то масiтабировать при прtдложенном "стандартном решении" надо: 1. Умощьнять сервер СУБД 2. Добавлять сервера приложений. Теперь забываем про сервер приложений, и, оказывается, для масштабирования достаточно умощьнать только сервер СУБД (на выбор - scale up или scale out). ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 10:32 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
just_nick GeenSРОСТОВЧАНИН? а-ха... уже теплее во всех смыслах...он самый... "жить ведь где-то надо"(с) Вам тут сотрудники не нужны? ;) Может и нужны ;) ...будут ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 10:44 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
GeenS Прохожий..... GeenSЕще раз повторяю (немного устало): мне предлагают разработать корпоративную систему учета, которую потом можно вырастить до сетевого сервиса и сдавать его другим компаниям для учета разных похожих услуг (кои являются потоковыми: тепло, вода, газ, еще хрен знает что придумают...) отсюда требование: заранее заложиться (прошу прощения за карточный жаргон) на мультиуслуги и разные компании из самых разных регионов России. А такие компании будут расти ка грибы по всем прогнозам! по моему проще и яснее не объяснишь... Вам доверяют создать биллинговую систему на 10 000 клиентов? Даже если приблизительно прикинуть то получается ваша фирма хочет захватить рынок ну как минимум 20% всего Российского биллинга. Идея мягко говоря амбициозная. В энергетике вам столько не дадут явно, там уже SPL начинает внедряться, года через 2-3 SPL заберет минимум половину этого рынка в энергетике. Но, что самое странное, данная амбициозная задача доверена человеку, который судя по всем предыдущим высказываниям лишь поверхностно владеет темой. Как повашему, чем закончится данный проект? ох-хо-хо... Да ничего мне не доверяют...Идут разговоры...Это стадия такая...Я вообще на самом деле даже не решил еще: участвовать или нет... Я же говорил - мне твердят в уши спецы...Я еще хочу понять суть этих спецов. Надеюсь на Вашу помощь. Абсолютно верно! Темой больших систем владею не очень...Темой энергосбыта - очень владею! А насчет амбиций - упаси Бог идти на такие масштабы! Пахнет катастрофой...Но запас надо ведь иметь? или нет? Не надо болезненно реагировать. Просто, что вы писали до этого, попахивает несерьезностью. Даже примитивно посчитав 10000 (одновременно работающих операторов) * 1000 (минимальное количество обслуживаемых абонентов 1 оператором) = 10млн абонентов (и это по минимуму, в реалиях будет значительно больше). Чисто технически хранение этой информации за 3-5 лет потребует каких мощностей, а ее обработка? Вы хотите создать национальный датацентр с суперЭВМ? А за работу с абонентами юрлицами вот так: авторИнтерфейс клиента: web пользователи вас сожгут на костре! Мой совет: Забейте на все и проектируйте систему на 300-500 пользователей, используя общедоступные средства, слишком жирный сервер приложений иметь чревато, так что лучше сбалансировать нагрузку между клиентом и сервером, все делайте на NET с доступом через WebService и люди к вам потянутся. P.S. если вам и вправду надо станет 10000 пользователей, ничто не мешает создать 20 баз на 20 серверах, а пытаться иметь одну БД на несколько десятков миллионов абонентов это маразм. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 10:53 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
pkarklinЕсли ОДИН сервер СУБД не справляется с нагрузкой от большого числа пользователей, то мы между ним и пользователями поставим ЕЩЕ ОДИН СЕРВЕР (несколько), который решит эти проблемы? Ключевое слово: бизнес-логика (перечитайте еще раз). И еще раз повторяю - это стандартное решение, которое применяется в системах такого масштаба, например, в банках (не наших). ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:12 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
Прохожий..... А за работу с абонентами юрлицами вот так: авторИнтерфейс клиента: web пользователи вас сожгут на костре! А что делать если сеть филиалов весьма распылена географически, а каналы скверные? если делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:18 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
модКлючевое слово: бизнес-логика (перечитайте еще раз). Хотите об этом поговорить? Давайте. Она эта бизнес-логика, реализуемая в вашем варианте не на сервере СУБД, будет обходиться без данных, получаемых с сервера? Т.е. В Вашем варианте мы сначала потянем необходимые данные на апп. сервер, там их "посчитаем" и положим обратно? И на кой этот геморой нужен? Зачем таскать данные еще куда-то, если их можно посчитать там, где они лежат? Не ставя дополнительных серверов и не городя между ними 10гигабиные каналы связи, превращая сервер СУБД в простое хранилище? модИ еще раз повторяю - это стандартное решение, которое применяется в системах такого масштаба, например, в банках (не наших). "Мода" на это "стандартное" решение давно прошла! Несколько лет назад все носились с идеей N-звенок, как с писаной торбой, но когда поняли, во что выливаются такие проекты, когда N-звенку совали кудя не попадя, Вы, надеюсь, слышали. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:22 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
GeenSА что делать если сеть филиалов весьма распылена географически, а каналы скверные? если делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... Еще один миф, в котором утверждается, что WEB интерфейс (оставим в стороне обсуждение его убогости) менее требователен к ширине каналов!!! Вы, как мне показалось, здравомыслящий человек. Ну сами посчитайте, что при использовании WEB клиента траффик будет не меньше, а БОЛЬШЕ, ибо кроме самих данных (предположим TDS пакетов), клиент и WEB сервер будут обмениваться еще кучей дополнительной информации. ВЫ скажите - "а обновления клиентских частей"? Для этого существуют различные способы. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:26 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
авторесли делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... Сильно ошибаетесь. авторкогда N-звенку совали кудя не попадя А теперь вспомним самое главное - КТО совал и куда.. Я -же говорю: тупые американцы! Используют дурацкие, ущербные трехзвенки и сервера приложений ведущих производителей. Ту-у-упы-ы-Е! ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:31 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
anonimouseЯ -же говорю: тупые американцы! Используют дурацкие, ущербные трехзвенки и сервера приложений ведущих производителей. Ту-у-упы-ы-Е! Вы ошибетесь! Они не тупые. Они очень хорошие маркетологи, умеющие навешать клиенту лапши на уши теми же аргументами, которыми и автора топика "спецы" подчивали. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:35 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
pkarklin GeenSА что делать если сеть филиалов весьма распылена географически, а каналы скверные? если делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... Еще один миф, в котором утверждается, что WEB интерфейс (оставим в стороне обсуждение его убогости) менее требователен к ширине каналов!!! Вы, как мне показалось, здравомыслящий человек. Ну сами посчитайте, что при использовании WEB клиента траффик будет не меньше, а БОЛЬШЕ, ибо кроме самих данных (предположим TDS пакетов), клиент и WEB сервер будут обмениваться еще кучей дополнительной информации. ВЫ скажите - "а обновления клиентских частей"? Для этого существуют различные способы. Ну вот как раз насчет обновления клиентских частей я меньше всего беспокоюсь...Я понимаю, что использование десктопного интерфейса дает преимущества как то: защищенность клиента от несанкционированного доступа, несравнимое с веб удобство и функциональность. Но: я никода не видел практического решения работы десктопного приложения через веб сервисы дотнет, а видел десктоп работающий с БД напрямую (Delphi + MS SQL 2000) - это выглядело, мягко говоря, не очень хорошо, хотя впрочем там система была очень криво спроектирована и возможно бесполезного трафика было сверх меры... А канал-то был 265Кбит на ОДНОГО КЛИЕНТА ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:36 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
GeenS Прохожий..... А за работу с абонентами юрлицами вот так: авторИнтерфейс клиента: web пользователи вас сожгут на костре! А что делать если сеть филиалов весьма распылена географически, а каналы скверные? если делать десктопного клиента, то конечно нужны каналы не менее 256Кбит, а у нас далеко не везде связисты дают такую возможность... Вы думаете web вас спасет от узких каналов? На канале в 64кбит даже странички размером в 100кб тормозят, и представте, все это будет использовать биллинговый центр, где уж никак не 1 оператор. Применяйте сжатие передаваемой информации (в NET реализуется проще простого), можно использовать кеширование некоторой инфы на клиенте. На мой взгляд так даже экономичней использовать трафик. Передается посути только xml с данными и все, ничего лишнего, а если xml еще и сжать, то вообще альтернативы нет! ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:36 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
GeenSА канал-то был 265Кбит на ОДНОГО КЛИЕНТА конечно же 256Кбит...сорри...хотя вот сейчас вспоминаю..наверное не было 256...было меньше...они только пробывали получить такой канал, а в тот момент не было. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:39 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
GeenSа видел десктоп работающий с БД напрямую (Delphi + MS SQL 2000) - это выглядело, мягко говоря, не очень хорошо, хотя впрочем там система была очень криво спроектирована и возможно бесполезного трафика было сверх меры... А канал-то был 265Кбит на ОДНОГО КЛИЕНТА Из собственного опыта. Удаленный филиал. 15 клиентов на канале 64 кбит. Разницы (в режиме нормальной операционной работы) что в локальной сети, что у них - никакой. Если же ВЫ потащите на клиента сотни тысяч записей за один присест - тады "ой". ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:39 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
pkarklin GeenSа видел десктоп работающий с БД напрямую (Delphi + MS SQL 2000) - это выглядело, мягко говоря, не очень хорошо, хотя впрочем там система была очень криво спроектирована и возможно бесполезного трафика было сверх меры... А канал-то был 265Кбит на ОДНОГО КЛИЕНТА Из собственного опыта. Удаленный филиал. 15 клиентов на канале 64 кбит. Разницы (в режиме нормальной операционной работы) что в локальной сети, что у них - никакой. Если же ВЫ потащите на клиента сотни тысяч записей за один присест - тады "ой". Да согласен, чрезвычайно зависит от проетирования, я бы даже сказал - стиля разработки клиента. Я например как могу избегаю редактируемые курсоры и вообче всякие привязки к данным через датасеты - все должно решаться только в ХП получающей параметрами значения ОТВЯЗАННЫХ контролов, т.е. все проверки на корректность, наличие / отсутствие и т.п. ИМХО. Но я так делаю - пока все хорошо. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:43 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
авторЯ например как могу избегаю редактируемые курсоры и вообче всякие привязки к данным через датасеты - все должно решаться только в ХП получающей параметрами значения ОТВЯЗАННЫХ контролов, т.е. все проверки на корректность, наличие / отсутствие и т.п. Я, наоборот, использую датасеты (в режиме кэшированных изменений) + db-aware контролы (за редким исключением) и хп на стороне сервера. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:48 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
pkarklinНесколько лет назад все носились с идеей N-звенок, как с писаной торбой, но когда поняли, во что выливаются такие проекты, когда N-звенку совали кудя не попадя, Вы, надеюсь, слышали. а во что они выливаются собственно? Как работали, так и продолжают работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:52 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
GeenSКраткое описание задачи: Назначение: Учет сбыта электроэнергии (физ.лица и юр.лица),биллинг, отслеживание состояний оборудования, договоры и т.п. Я не имею опыта в этих сферах.Я работал только с MS продуктами. Есть команда разработчиков и у них почти сложилось понимание, НО! я хочу иметь собственной мнение. Кто имел опыт подобных разработок - поделитесь советом...Заранее благодарен iseries + telnet 5250 (green sreen) хватит и 9600 коннекта при нынешних ценах на x86 софт не дороже будет -) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 11:53 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
Уважаемые! Каждый волен отстаивать свою точку зрения и ту тенологию которой владеет. Я имел возможность поюзать и даже поучаствовать в проектах с многозвенной архитектурой и классической клиент серверной.И там и там есть свои плюсы и минусы.Одно могу сказать точно: какая разница насколько красиво ваше решение если оно не работает.Качество проектирования складывается из многих составляющих.Даже на очень хорошее железо можно такой глючный софт поставить.Классический клиент сервер хорош до определенных масштабов.Явно не для ваших амбиций:).WEB клиент по-моему убогий изначально ,плюс убогая ,как правило, реализация .К тому же достаточно дорогие спецы.Теперь ,что подразумевать под многозвенкой?.Если сервер приложений это просто набор интерфейсов доступа к базе- выигрыш в производительности сомнительный.Под Ado.net все и так работает не быстро .Хотя если данные достаточно статичны при правильном подходе число запросов к серверу можно значительно уменьшить ,но при этом надо иметь хорошие каналы .ХМL знаете ли ... Или вы на самом деле будете писать свой сервер приложений.В смысле бизнеслогику туда вынесите или хотя бы часть... но спрашивается зачем?Если отказаться от WEB клиента то есть на клиенте классический EXE.И пусть все умное делается на клиенте.Не думаю ,что нормальное железо дороже чем софт. В любом случае: оччень мощный сервер с базой отдельно , сервер(ы) приложений(доступа) отдельно, "толстый" клиент c возможностью удаленного обновления. З.Ы. и упаси вас господь от репликаций и проч. "стандартных" решений от MS. а мода здесь совершенно не при чем ,хотя имеет место быть.. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 12:18 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
pkarklinЗачем таскать данные еще куда-то, если их можно посчитать там, где они лежат? Не ставя дополнительных серверов и не городя между ними 10гигабиные каналы связи, превращая сервер СУБД в простое хранилище? Дело все в том, что СП и каналы связи могут масштабироваться (и недорого), а вот сервер БД - один (и дорогой и масштабировать его дорого). ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 12:19 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
leonidyУважаемые! Каждый волен отстаивать свою точку зрения и ту тенологию которой владеет. Я имел возможность поюзать и даже поучаствовать в проектах с многозвенной архитектурой и классической клиент серверной.И там и там есть свои плюсы и минусы.Одно могу сказать точно: какая разница насколько красиво ваше решение если оно не работает.Качество проектирования складывается из многих составляющих.Даже на очень хорошее железо можно такой глючный софт поставить.Классический клиент сервер хорош до определенных масштабов.Явно не для ваших амбиций:).WEB клиент по-моему убогий изначально ,плюс убогая ,как правило, реализация .К тому же достаточно дорогие спецы.Теперь ,что подразумевать под многозвенкой?.Если сервер приложений это просто набор интерфейсов доступа к базе- выигрыш в производительности сомнительный.Под Ado.net все и так работает не быстро .Хотя если данные достаточно статичны при правильном подходе число запросов к серверу можно значительно уменьшить ,но при этом надо иметь хорошие каналы .ХМL знаете ли ... Или вы на самом деле будете писать свой сервер приложений.В смысле бизнеслогику туда вынесите или хотя бы часть... но спрашивается зачем?Если отказаться от WEB клиента то есть на клиенте классический EXE.И пусть все умное делается на клиенте.Не думаю ,что нормальное железо дороже чем софт. В любом случае: оччень мощный сервер с базой отдельно , сервер(ы) приложений(доступа) отдельно, "толстый" клиент c возможностью удаленного обновления. З.Ы. и упаси вас господь от репликаций и проч. "стандартных" решений от MS. а мода здесь совершенно не при чем ,хотя имеет место быть.. только не толстый клиент! так мы и до DBF докатимся... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 12:40 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
модДело все в том, что СП и каналы связи могут масштабироваться (и недорого), а вот сервер БД - один (и дорогой и масштабировать его дорого). Еще раз. Умощнением (увеличением кол-ва) только апп. серрверов проблемы масштабирования не решить. От того, что Вы в одном месте информационного потока сделали "шире" общая пропускная способность не увеличится, так как будет определяться самым "узким" местом на пути этого потока, которым в Вашем примере станет сервер СУБД. Таким образом, при наличии апп. сервера надо умощнать и апп. сервер и сервер СУБД, и только сервер СУБД в случаи отсутствия первого. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 12:44 |
|
Выбор сервера приложений
|
|||
---|---|---|---|
#18+
На самом деле вот что: или БЛогика на сервере БД и доступ через веб сервисы или БД+аппсервер+тонкий (веб?) клиент Мне один чел вообще говорит: все делать на сервере приложений, берем шустрый MySQL и используем его только как хранилище данных объектов, т.е. храним собственно объекты. Аппсервер дергает объекты из базы (конструктором класса) чето-там ими манипулирует...и назад если надо. Я ему сразу: мил человек, ява твоя в таком разе столько отожрет что мама не горюй! Он начал возмущаться. Я ему говорю, ладно: как ты себе представляешь объект выбирающий списки для отчетов, вообще объект отчет. Примолк. Наверное думает. Откуда такое небрежение к реляционным БД? Прям будто они только то и могут что поля хранить в таблицах! А че это мы как не свои прямо? Ведь праздник же коллеги! Поздравляю! Забыл совсем... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2007, 12:49 |
|
|
start [/forum/topic.php?fid=33&msg=34797109&tid=1548999]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
126ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
others: | 266ms |
total: | 502ms |
0 / 0 |