Когда кончатся эти мучения с подкачкой данных? - страница 6

 
Ренат, я все никак не пойму, как можно злоупотребить закачкой статического контента? Трафика жалко, что ли? Так он довольно дешевый нынче. Сколько там данных-то в истории... TOHLCV... порядка 30 байт на свечу. Вообще не понятно, о чем разговор. Допустим, будет 10 тыс свечей. Получается 300 килобайт на тикер на период. Плюс еще сжатие... ну допустим, 3:1 (хотя, наверное, можно и больше, чуть ли не больше, чем десять в один, если репу почесать хорошо). Для символа есть 8 периодов. Получается по 800 килобайт на тикер (при сжатии три в один). Сколько требуется тикеров разумному человеку? Ну штук тридцать-пятьдесят. Всего по 50 MB на человека. Сколько пользователей?.. ну.. допустим до десяти тысяч. Это где-то 500GB примерно... 500GB трафика стоят около ста баксов, если я правильно помню. По крайней мере я сам плачу примерно столько (ну там, плюс-минус 10 баксов).
Теперь скорость... допустим, есть хороший 10Mbit burstable порт. 10 тыс пользователей если начнут разом качать, каждому достанется по 1Kbit. Это сто байт в секунду. Таким образом, чтобы все это скачать, надо с такой скоростью 50 мин на тикер на период (это без учета сжатия). Я не думаю, что кто-то станет в таких условиях злоупотреблять сидением перед монитором по 50 мин при каждом запуске MT. А если по делу надо, то один раз можно и посидеть, чтобы в кеш засосалось.
Другой вопрос, что синхронность при таких раскладах может боком выйти.
 
Sfen, картину в цифрах нагрузки нарисовали приблизительно похожую на реальность, а вот с оценкой реальности работы и стоимости полное непонимание.

Кстати, почитайте топик человека, которому надо трафик на уровне десятка байт в секунду.
И даже меньше. И это правильно, по-моему.

Трафика жалко, что ли? Так он довольно дешевый нынче.

Вот именно и проявилось то, о чем мы говорим постоянно.
Всегда найдется кто-то, кто скажет "а у меня выделенка, у меня все стоит гроши, хочу по полной!"
Наш подход совершенно противоположный - софт должен быстро и стабильно работать на самом плохом канале что только возможен. Чтоб люди сидели на GPRS и все у них получалось.

И софт пишем очень экономный - дистрибан МТ4 весит всего 2.2 мега, а в нем: полнофункциональный терминал, отличный редактор с встроенным хелпом, лайвапдейт, компилятор MQL4 и multilanguage pack.

Я отлично понимаю - возможно, Вам размеры не важны, трафик то "довольно дешевый нынче".
Но это абсолютно против нашего подхода.

ps: никто вообще даже словом не обмолвился о том, что у сервера еще может в обработке висеть пару десятков тысяч открытых позиций, которые надо обсчитывать в рилтайме, контролировать все маржевые требования и срабатывание отложенных ордеров... а это ведь одни из самых трудоемких задач сервера.
Грубо: представьте себе на каждый тик for(i=0;i<10000;i++) { расчет профитов, обновление маржевых требований, контроль стопов и срабатывания отложенных ордеров }, а тут к серверу подключены 1500 (полторы тысячи!) трейдеров с дешевым трафиком и требуют неограниченной подкачки истории :-)
 
Трафик клиентов - это проблемы клиентов. Если кому-то надо скачать 50MB, значит, ему это зачем-то надо. Речь шла именно о способности сервера отгрузить десяти тысячам клиентов историю котировок. Задача обсчета ордеров, открытых позиций и маржинколлов, очевидно, распараллеливается близко к идеальному случаю, и, соответственно, сервер размножается простым копированием. То есть увеличение числа серверов в N раз приводит к уменьшению нагрузки на каждый в N раз. Так что по поводу вычислительной нагрузки я бы плакать не стал, ладно, была бы сильносвязанная задача, а тут load balancing идеально работает (хоть round robin вызьмите, клиенты-то независимые). Поэтому никто и не вспоминает про вычислительную нагрузку.
 
Кстати, судя по тому, какие эмоции у вас вызывает вычислительная нагрузка, никакого load balancing, связанного по общей базе клиентов, не предусмотрено даже теоретически.
В большинстве случаев это подразумевает
- отсутствие резервирования active/active (при отказе сервера все курят, пока не отремонтируют железяку),
- отсутствие возможности rolling upgrade (то есть сервер для апгрейда выключается нафиг и все курят),
- и, обычно, но не всегда, отсутствие бэкапа, близкого к реальному времени (то есть если сервер умрет, пропадают не последние 30 сек операций, а последние несколько часов).
интересно, как вообще бэкап организован (если есть проблемы с нагрузкой).

Можно, конечно, жаловаться на слабость железа (скажем, если ДЦ жмотятся на оборудование, а на второй сервак еще 200 баксов в месяц вообще никогда не дадут), но это проблемы ДЦ, а сервер, хотя бы теоретически, должен масштабироваться.
 
никто вообще даже словом не обмолвился о том, что у сервера еще может в обработке висеть пару десятков тысяч открытых позиций, которые надо обсчитывать в рилтайме

А что, у вас все обязательно на одном сервере крутится (на одной железке)?
И торговля, и сервер истории?
А что такое дата центр и что, ДЦ не может его у себя поставить?

Не понимаю, почему вы все время уводите разговор в сторону ...
Ведь торговый сервер и сервер истории- это РАЗНЫЕ сервера, и ДЦ может (и должен) держать их на разных железяках. Причем дата центров (на которые падает нагрузка по подкачке истории) может быть много. Или это все не так?

Почему вы все время говорите про ОДИН сервер?

Что, ваша система не позволяет распаралелиться по задачам? - Тогда это не платформа ..
Или ДЦ такие, что не в состоянии потратить лишнюю штуку баксов на доп. комп.? - Тогда это не ДЦ ..
Или вы просто передергиваете из-за отсутствия других аргументов? - .....

а тут к серверу подключены 1500 (полторы тысячи!) трейдеров с дешевым трафиком и требуют неограниченной подкачки истории

Не требуют, и не неограниченной.
Можете ограничить длину в 2048 - 4096 баров на инструмент.
И загрузка истории может потребоваться только 1 раз - после инсталляции МТ
или соответствующего индикатора.

Если данные уже есть в локальной базе, то пользователь никак не сможет нагрузить сервер, МТ вернет локальные данные.
Это действительно СТАТИЧЕСКИЙ КОНТЕНТ ...

Зачем вы все время передергиваете ... :(((
(надоел уже весь этот бред ..)
(хотелось сделать как лучше, а получается как всегда .. через /dev/ass..)
 
Sfen, я вынужден признать, что Вы в этом вопросе совершенно не в теме.
Чтобы не выдавать голословных заявлений, просто напишите собственный сервер выдачи потокового контента. Отмасштабируйте его до пары тысяч пользователей, параллельно введите сжатие и шифрацию.

сервер, хотя бы теоретически, должен масштабироваться.

Надо бы хотя бы читать описания системы прежде чем ее критиковать:
"Data Center"

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

Во первых, это может оказаться мало.

Во вторых, распределенный сервер я писал, но не могу вам его продемонстрировать еще, кажется, года три-четыре, поскольку давал подписку о неразглашении (в области защиты данных это обычное дело). Единственно что могу сказать, что по смыслу это было похоже на поисковую машину (но не было ей).

В третьих, 70 брокерских компаний - это, естественным образом, не показатель (см. Windows ранних версий).

В четвертых, если у вас есть эти самые data centers, и все это работает так, как рекламируется, то непонятно, откуда вообще проблема с раздачей исторических котировок, и почему вы так жалуетесь на вычислительную мощность (которая в таком случае нагружена на другую машину, ту, на которой работает центральный сервер). Так что или что-то не работает, как рекламируется, или вам просто лень писать эту раздачу котировок (что, вообще говоря, вполне разумная причина - ну так бы и сказали, только не прикрываясь заботой о нагрузке). Есть еще вариант, что в реальных ДЦ все всегда ставится кучей на одну машину - тогда проблема понятна. Правда, непонятно, почему для реальных клиентов так делается (а если для реальных клиентов ставится так, как на той картинке про datacenters, то почему бы им не раздать историю?).

В пятых, совершенно удивительно ваше упорство в вопросе о шифровании котировок, которые представляют с собой открытые данные (если только речь не идет только о цифровых подписях).
 
Sfen, я вынужден признать, что Вы в этом вопросе совершенно не в теме.

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


Эту задачку можно представить и в другом виде:
Есть пользователи, которым необходимо гарантированное получение РАЗУМНОГО кол-ва исторических данных для корректного использования инструментов производителя (ArrrayCopyRates, ArrrayCopySeries) и есть производитель, который считает, что такой гарантированный механизм не нужен, так как при его ПОВСЕМЕСТНОМ использовании МОГУТ возникнуть перегрузки.

Интересно, а у других лидеров рынка (TradeStation, ...) тоже нет гарантированного механизма получения исторических данных?

Последнее слово все равно, конечно, останется за MetaQuotes, но хотелось бы, чтобы потребности пользователей тоже были учтены :)
 
Интересно, а у других лидеров рынка (TradeStation, ...) тоже нет гарантированного механизма получения исторических данных?

В TradeStation сколько попросиш, столько и будет (хоть за 100 лет).
А в последних версиях (TS6-8) нет GlobalServer'a и все что просиш грузится с их сервака.
Причем грузится очень быстро, несмотря на то, что у них наверняка не менее 100 тыс юзеров.
Причем других датафидов к TradeStation по лицензии быть не может, все только с TradeStation Securities.
 
Mak, нам сейчас вспомнят, сколько стоит эта самая Tradestation. Мы, правда, вспомним в ответ про TCO, но тогда совсем уйдем от темы :)
Причина обращения: