Здравствуйте, Serginio1, Вы писали:
S> S>> А вот терминалы прижились уже по причинам того, что нужно меньше всякого оборудования. Тонкие клиенты на линуксах стоят оочень дешево, дешевле чем со стоимостью лицензий чем настоящий комп. Администрировать меньше. Одни выгоды.
S> R>Терминалы масштабируются только вертикально. Это тупиковое решение.
S> А почему нельзя добавить больше серверов? Какая в этом большая проблема? S> Если добавляются новые пользователи для них добавляются новые сервера. В чем проблема то?
Если решение клиент-серверное изначально, ему нет нужды крутиться на терминальном сервере. Терминальные сервера обычно используются для софта, который нельзя масштабировать горизонтально. Вот почему.
S> То есть комп для юзера купить не проблема, а вот 1 сервер для кучи пользователей с тонкими клиентами значит проблема?
Да. Лишние затраты. Сейчас офисные задачи можно решать на кубике с ребром 6 см, который стоит 10 тыс. руб. (он даже прогрессивный уэб-клиент вывезет)
R>Если решение клиент-серверное изначально, ему нет нужды крутиться на терминальном сервере. Терминальные сервера обычно используются для софта, который нельзя масштабировать горизонтально. Вот почему.
То есть это твои предположения?
Терминальные сервера это замена толстого клиента! Не зависит от софта. Там графика сжимается и передается с минимальной задержкой, а в основном это изменения экрана.
S>> То есть комп для юзера купить не проблема, а вот 1 сервер для кучи пользователей с тонкими клиентами значит проблема?
R>Да. Лишние затраты. Сейчас офисные задачи можно решать на кубике с ребром 6 см, который стоит 10 тыс. руб. (он даже прогрессивный уэб-клиент вывезет)
Зависит от задач. Можно кубик и без диска купить. Еще дешевле.
А про обслуживание, бэкап и прочее забыл?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> R>Если решение клиент-серверное изначально, ему нет нужды крутиться на терминальном сервере. Терминальные сервера обычно используются для софта, который нельзя масштабировать горизонтально. Вот почему.
S> То есть это твои предположения?
Вовсе нет. Просто я вспомнил, как соседи сношались с 1С, коли уж ты ее упомянул.
S> Терминальные сервера это замена толстого клиента! Не зависит от софта. Там графика сжимается и передается с минимальной задержкой, а в основном это изменения экрана.
Толстые клиенты умерли в конце девяностых. Жаль, конечно, что одинэсникам об этом не рассказали (это не в твой огород камень, если что).
S> R>Да. Лишние затраты. Сейчас офисные задачи можно решать на кубике с ребром 6 см, который стоит 10 тыс. руб. (он даже прогрессивный уэб-клиент вывезет)
S> Зависит от задач. Можно кубик и без диска купить. Еще дешевле. S> А про обслуживание, бэкап и прочее забыл?
Обслуживание чего? Бекап? Чего ты собрался бекапить с тонкого клиента?
Здравствуйте, rudzuk, Вы писали:
S>> R>Если решение клиент-серверное изначально, ему нет нужды крутиться на терминальном сервере. Терминальные сервера обычно используются для софта, который нельзя масштабировать горизонтально. Вот почему.
S>> То есть это твои предположения?
R>Вовсе нет. Просто я вспомнил, как соседи сношались с 1С, коли уж ты ее упомянул.
S>> Терминальные сервера это замена толстого клиента! Не зависит от софта. Там графика сжимается и передается с минимальной задержкой, а в основном это изменения экрана.
R>Толстые клиенты умерли в конце девяностых. Жаль, конечно, что одинэсникам об этом не рассказали (это не в твой огород камень, если что).
Толстый клиент я имел ввиду комп! Я тебе привел пример 1С как сначала использовали для 1С, но затем стали использовать повсеместно.
S>> R>Да. Лишние затраты. Сейчас офисные задачи можно решать на кубике с ребром 6 см, который стоит 10 тыс. руб. (он даже прогрессивный уэб-клиент вывезет)
S>> Зависит от задач. Можно кубик и без диска купить. Еще дешевле. S>> А про обслуживание, бэкап и прочее забыл?
R>Обслуживание чего? Бекап? Чего ты собрался бекапить с тонкого клиента?
На тонком клиенте нет, а на сервере есть.
Данные так или иначе клиент будет хранить на нем.
В твоем случае коробочка полноценный комп!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> R>Толстые клиенты умерли в конце девяностых. Жаль, конечно, что одинэсникам об этом не рассказали (это не в твой огород камень, если что).
S> Толстый клиент я имел ввиду комп! Я тебе привел пример 1С как сначала использовали для 1С, но затем стали использовать повсеместно.
Ты сейчас все только запутываешь. Есть устоявшаяся терминология, и толстым клиентом называется клиентское приложение для сервера БД. Тонким клиентом является приложение взаимодействующее с сервером приложений, как отдельной сущностью. Так вот. Последние, обычно, проектируются с учетом возможности горизонтального масштабирования. Первых пытаются масштабировать вертикально, используя, в том числе, сервер терминалов. Но бесконечно вертикально масштабировать нельзя, увы.
S> R>Обслуживание чего? Бекап? Чего ты собрался бекапить с тонкого клиента?
S> На тонком клиенте нет, а на сервере есть.
И что? А на терминальном сервере ничего бекапить не надо что-ли?
S> В твоем случае коробочка полноценный комп!
Здравствуйте, rudzuk, Вы писали:
S>> Толстый клиент я имел ввиду комп! Я тебе привел пример 1С как сначала использовали для 1С, но затем стали использовать повсеместно.
R>Ты сейчас все только запутываешь. Есть устоявшаяся терминология, и толстым клиентом называется клиентское приложение для сервера БД. Тонким клиентом является приложение взаимодействующее с сервером приложений, как отдельной сущностью. Так вот. Последние, обычно, проектируются с учетом возможности горизонтального масштабирования. Первых пытаются масштабировать вертикально, используя, в том числе, сервер терминалов. Но бесконечно вертикально масштабировать нельзя, увы.
Это тоже устоявшаяся терминология. И я говорил он них. Ты как то контекст поменял.
S>> R>Обслуживание чего? Бекап? Чего ты собрался бекапить с тонкого клиента?
S>> На тонком клиенте нет, а на сервере есть.
R>И что? А на терминальном сервере ничего бекапить не надо что-ли?
Так он один! Не надо кучу компов обслуживать!
S>> В твоем случае коробочка полноценный комп!
R>И что? Важно, что она стоит сущие копейки.
Тонкий клиент еще дешевле! Но обслуживать один сервер или кучу компов разница большая!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, rudzuk, Вы писали:
R>Толстые клиенты умерли в конце девяностых.
Ничего подобного. В 2005-м я в Краснодарском крае видел ADSL и толстые клиенты. Выигрыш там существенный, кстати: общие справочники, такие как КЛАДР меняются крайне редко, и снятие нагрузки с центральных серверов при перемещении этих данных на клиента получается существенным. КЛАДР, кстати, весить существенно. Да даже в 2007 видел.
Не понимаю я этой моды на тонких клиентов: всё равно ведь комп нужен.
Всё сказанное выше — личное мнение, если не указано обратное.
Ф>Ничего подобного. В 2005-м я в Краснодарском крае видел ADSL и толстые клиенты. Выигрыш там существенный, кстати: общие справочники, такие как КЛАДР меняются крайне редко, и снятие нагрузки с центральных серверов при перемещении этих данных на клиента получается существенным. КЛАДР, кстати, весить существенно. Да даже в 2007 видел.
Ф>Не понимаю я этой моды на тонких клиентов: всё равно ведь комп нужен.
Ну смысл (трехзвенки) в кэшировании и уменьшения трафика.
Обычно сервер БД и Сервер приложений стараются на одной машине ставить. Пайпы быстрее на одном компе чем tcp/ip между компами.
Проблема в том, что нельзя одним запросом втащить все данные и избавиться от множества мелких запросов.
Логика бывает очень сложной. Поэтому на разных этапах новые запросы.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Обычно сервер БД и Сервер приложений стараются на одной машине ставить.
Стараться можно сколько угодно, но если БД не готова для репликации, то в твоём арсенале будет только вот такие, костыльные решения. Да и репликация — та ещё головная боль. Я семнадцать лет назад взялся для одной БД репликацию настроить, и... обосрался
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Serginio1, Вы писали:
R>>Терминалы масштабируются только вертикально. S> Нет, зависит от экрана и ОС. На новых осях все прекрасно масштабируется. Он ж не про то масштабирование
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Философ, Вы писали:
S>>Обычно сервер БД и Сервер приложений стараются на одной машине ставить.
Ф>Стараться можно сколько угодно, но если БД не готова для репликации, то в твоём арсенале будет только вот такие, костыльные решения. Да и репликация — та ещё головная боль. Я семнадцать лет назад взялся для одной БД репликацию настроить, и... обосрался
Репликация то особо не спасает. Она больше нужна между распределенными базами.
В 1С есть такая штука. Но это не имеет отношения к скорости обмена между сервером приложений и БД.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Serginio1, Вы писали:
R>>>Терминалы масштабируются только вертикально. S>> Нет, зависит от экрана и ОС. На новых осях все прекрасно масштабируется. CC> Он ж не про то масштабирование
Я ему и про другое тоже писал http://rsdn.org/forum/flame.comp/8479611.1
Здравствуйте, Serginio1, Вы писали:
S> Репликация то особо не спасает. Она больше нужна между распределенными базами. S>В 1С есть такая штука. Но это не имеет отношения к скорости обмена между сервером приложений и БД.
Репликация нужна, когда тебе нужно поднять больше одного инстанса БД. Объединение на одной машине клиента и БД — частный случай. Чаще бывает, когда БД ложится под грузом Select'ов и тебе необходимо что-то с этим сделать.
Случай ADSL, кстати — тот самый случай, когда тебе могло бы помочь вытаскивание хотя-бы части данных поближе к клиенту. И репликация тут вполне могла бы подойти.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф> R>Толстые клиенты умерли в конце девяностых.
Ф> Ничего подобного. В 2005-м я в Краснодарском крае видел ADSL и толстые клиенты. Выигрыш там существенный, кстати: общие справочники, такие как КЛАДР меняются крайне редко, и снятие нагрузки с центральных серверов при перемещении этих данных на клиента получается существенным. КЛАДР, кстати, весить существенно. Да даже в 2007 видел.
Ф> Не понимаю я этой моды на тонких клиентов: всё равно ведь комп нужен.
Само по себе использование тонкого клиента совсем не означает отказа от некоторой логики на клиентской стороне. Просто, как пример: у нас некоторые клиенты могли без связи с сервером по месяцу работать.
А теперь, внимание, правильное цитирование википедии:
Тонкий клиент (англ. thin client) в компьютерных технологиях — компьютер или программа-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер. Примером тонкого клиента может служить компьютер с браузером, использующийся для работы с веб-приложениями. Данным термином может также называться P2P-клиент, использующий в качестве сервера другие узлы сети.
В дихотомии толстый/тонкий клиент (rich client vs. thin client), речь идет о программной части (почему, собственно, я и сказал, что масштабирование через сервер терминалов — тупик).
S> R>И что? А на терминальном сервере ничего бекапить не надо что-ли?
S> Так он один! Не надо кучу компов обслуживать!
Ты об этом вспомнишь, когда этот один навернется и предприятие встанет колом потому, что даже банальную путевку водиле распечатать никто не сможет.
S> S>> В твоем случае коробочка полноценный комп!
S> R>И что? Важно, что она стоит сущие копейки.
S> Тонкий клиент еще дешевле! Но обслуживать один сервер или кучу компов разница большая!
Сэкономишь копейку на клиенте, потратишь рубль на сервере терминалов. Заплатишь дважды, а то и трижды.
Здравствуйте, Serginio1, Вы писали:
S> Обычно сервер БД и Сервер приложений стараются на одной машине ставить. Пайпы быстрее на одном компе чем tcp/ip между компами.
Если у тебя сервер приложений не является тупым ретранслятором запросов к БД, то это не очень важно. Достаточно их соединить хорошими гигабитами.
Здравствуйте, rudzuk, Вы писали:
R>Само по себе использование тонкого клиента совсем не означает отказа от некоторой логики на клиентской стороне. Просто, как пример: у нас некоторые клиенты могли без связи с сервером по месяцу работать.
Интересно, что они там у вас там делали? Пасьянс на компе раскладывали? Котиков в интернетах лайкали?
Просто ты сам чуть-чуть ниже выделил:
....Примером тонкого клиента может служить компьютер с браузером, использующийся для работы с веб-приложениями.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
S>> Репликация то особо не спасает. Она больше нужна между распределенными базами. S>>В 1С есть такая штука. Но это не имеет отношения к скорости обмена между сервером приложений и БД.
Ф>Репликация нужна, когда тебе нужно поднять больше одного инстанса БД. Объединение на одной машине клиента и БД — частный случай. Чаще бывает, когда БД ложится под грузом Select'ов и тебе необходимо что-то с этим сделать.
Ф>Случай ADSL, кстати — тот самый случай, когда тебе могло бы помочь вытаскивание хотя-бы части данных поближе к клиенту. И репликация тут вполне могла бы подойти.
Ну вот в 1С есть понятие распределенные БД. То есть есть центральная БД, а перефирийные обмениваются через неё.
Обычно это разного рода справочник. А так каждая БД это отдельный склад итд.
Когда же у тебя есть несколько БД то их как правило разделяют по некому функционалу. И то хрень это все.
Поэтому процветают разного рода Redis
и солнце б утром не вставало, когда бы не было меня
S>> Обычно сервер БД и Сервер приложений стараются на одной машине ставить. Пайпы быстрее на одном компе чем tcp/ip между компами.
R>Если у тебя сервер приложений не является тупым ретранслятором запросов к БД, то это не очень важно. Достаточно их соединить хорошими гигабитами.
Пробовали. В итоге как минимум в 2 раза скорость падала, а то и больше. Сейчас не помню. Давно это было.
Сервер приложений как и занимается расчетом. Но в 1С очень сложные алгоритмы проведения документов. Нельзя одним запросом все вытащить.
СП что то сам кэширует, но все равно нужно делать множество запросов в одной транзакции.
При этом при записи документа блокируются множество записей. Нужно транзакцию как можно быстрее закончить.
Основное время это обмен данными между БД и СП
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Когда же у тебя есть несколько БД то их как правило разделяют по некому функционалу. И то хрень это все. S> Поэтому процветают разного рода Redis
С трудом представляю, как этот редис использовать. Если хранить данные в нём, то получать аггрегированные данные замучаешься: руками апдейтить индексы и джойнить — то ещё удовольствие. А хранить там аггрегированные данные глупо: в итоге может оказаться, что половина заказов у тебя на Машу Девичью, а половина на Машу Иванову — все заказы заказы этой Маши уже не найти. А если её использовать как кэш агрегированных данных, то неожиданно может оказаться, что балансировщик тебя отправил не в то окружение, и в твоём редисе тупо нет нужных данных — клиент усложняется в разы.
Всё сказанное выше — личное мнение, если не указано обратное.
вывезет)
