|
Выбор : 2х или 3х звенка?
|
|||
---|---|---|---|
#18+
Добрый вечер, тема избитая но у меня конкретная задача. Сразу хотел бы попросить, не обращать на вероятные ошибки как в тексте так и в диаграммах. Есть некоторая модель данных (см. на слайд№1). В данной задаче принимаются идеальные условия. Собственно задача: Есть некая финансовая система в ней зарегистрированны 300 пользователей. У каждого из пользователей есть личные средства которые учитывает эта система ( анналог с банковскими карточками ) и определен лимит (на текущий год), каждая операция расхода сопровождается определением возможности проведения операции ЛИМИТ>=(расход№1+расход№2...расход№N) и вставкой записи в таблицу "текущие расходы" если таковая возможна. В таблице текущие расходы 2 000 000 записей (данные за 3 года). СУБД Oracle 10g Release 1. Сервер приложений JBOSS. Для 2-х решений (клиент-сервер и 3х звенная архитектура) пользователь выполняет одни и те же операции. Завершением считается завершение операции или получение отказа (для каждого пользователя). Очень ВАЖНО! Данную операцию 300 пользователь выполняют одновременно ( к примеру в 23:59:59 ). Необходимо определить при какой архитектуре (СЛАЙД№2 или СЛАЙД№3) данная задача выполниться быстрее? Извиняюсь что много букв. Заранее благодарю за ваши коменты. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2011, 21:57 |
|
Выбор : 2х или 3х звенка?
|
|||
---|---|---|---|
#18+
Задача действительно интересная, но пока мы не узнаем, чем же там занимается JBoss, она по сути сводится к следующей: "Программа может общаться с БД напрямую, а может через промежуточную программу. Как быстрее?". Ну и ответ: "Напрямую быстрее, если только промежуточная программа не подготавливает данные предварительно (кеширует, например)". Тем более, что Вы говорите о таблицах и полях, а не об объектах и javabeans. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2011, 22:34 |
|
Выбор : 2х или 3х звенка?
|
|||
---|---|---|---|
#18+
rilioЗадача действительно интересная, но пока мы не узнаем, чем же там занимается JBoss, она по сути сводится к следующей: "Программа может общаться с БД напрямую, а может через промежуточную программу. Как быстрее?". Ну и ответ: "Напрямую быстрее, если только промежуточная программа не подготавливает данные предварительно (кеширует, например)". Тем более, что Вы говорите о таблицах и полях, а не об объектах и javabeans. Вы безусловно правы. Я попытался подойти к определению архитекруры абстрактно - видимо это в корне неверно! Не могу провести анализ при какой архитектуре будет более производительно!? для данной задачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2011, 22:40 |
|
Выбор : 2х или 3х звенка?
|
|||
---|---|---|---|
#18+
student42Я попытался подойти к определению архитекруры абстрактно - видимо это в корне неверно! Не могу провести анализ при какой архитектуре будет более производительно!? для данной задачи.Первое - кешировать тут нечего, у каждого пользователя свои данные. Второе - нужно определиться, что называется "быстрее" (т.е. когда операция считается законченной - когда данные положат в СУБД или когда пользователь получит ответ). Третье - когда пользователь получает ответ - когда данные положат в СУБД или когда данные положат в сервер приложений? Вот исходя из ответов на эти вопросы всё будет понятно. Как правило, для таких приложаний пользователь получает ответ, когда данные сохранены в СУБД; поэтому с учётом того, что общих кешируемых данных нет, для данной конкретной задачи 2-х звенка быстрее, т.к. мы просто исключим лишнее звено. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2011, 23:18 |
|
Выбор : 2х или 3х звенка?
|
|||
---|---|---|---|
#18+
А что значит "одновременно"? Транзакции на заблокированных данных все равно пойдут последовательно (да и физически там будет последовательное выполнение). Насколько существенна эта "одновременность"? Или просто имеется в виду, что пиковая нагрузка - около 300 сложных транзакций в секунду? Но на таких объемах данных - все равно от архитектуры мало что зависит. По идее, трехзвенка в среднем лучше масштабируется, но нагрузка нужна на несколько порядков выше, нежели та, что есть. Все равно все будет упираться в количество оперативки и дисковую корзину у СУБД. А, ну еще если JPA в JBoss как-нибудь особо плохо настроить, то проблемы будут. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2011, 13:12 |
|
Выбор : 2х или 3х звенка?
|
|||
---|---|---|---|
#18+
student42, 2-х заенка или 3-х звенка? Конечно 2-х звенка будет работать быстрее, как написали выше, банально, исключается одно звено. Но смотрите, где будет храниться бизнес логика? В БД, при помощи хранимок? Не будет ли это слишком перегружать БД? Или BLL будет вынесен в виде "толстого клиента"? Мое скромное мнение, если необходима максимальная скорость выполнения + BLL приложения не будет меняться (или очень редко) тогда толстый клиент, а БД нужна только для выбора данных. А если же BLL очень большой + постоянно меняться бизнес правила, тогда без сервера приложений никуда. В крайнем случае, если сервак долго думает можно создать кластер. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2011, 14:18 |
|
Выбор : 2х или 3х звенка?
|
|||
---|---|---|---|
#18+
student42Необходимо определить при какой архитектуре (СЛАЙД№2 или СЛАЙД№3) данная задача выполниться быстрее? Тут вопрос не столько в архитектуре, сколько в оптимизации. Я бы сказал так: при использовании эквивалентных методов оптимизации время отклика в обоих случаях будет достаточно малым, чтобы было глупо думать быстрее/медленнее. На пальцах: если речь идёт о том, чтобы выполнить запрос вида "лимит за текущий год минус траты за текущий год", то на выполнение трёхсот таких запросов уйдёт в общем одинаковое время вне зависимости от того, приходят они с трёхсот клиентов или через пару "прокси". Application Server может закэшировать "текущий остаток клиента" и быстро отвечать на такого рода запросы, обычно адепты трёхзвенок очень этим гордятся. СУБД в общем ровно так же может его закэшировать, будет в целом так же быстро. Для толкового разработчика трёхзвенка в принципе даёт некоторые возможности оптимизации, в двухзвенке отсутствующие либо затруднительные. Но они достаточно тонкие, и в данной задаче никак не проявляются. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 10:42 |
|
|
start [/forum/topic.php?fid=33&fpage=28&tid=1548113]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
others: | 316ms |
total: | 450ms |
0 / 0 |