Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Теперь скорость... допустим, есть хороший 10Mbit burstable порт. 10 тыс пользователей если начнут разом качать, каждому достанется по 1Kbit. Это сто байт в секунду. Таким образом, чтобы все это скачать, надо с такой скоростью 50 мин на тикер на период (это без учета сжатия). Я не думаю, что кто-то станет в таких условиях злоупотреблять сидением перед монитором по 50 мин при каждом запуске MT. А если по делу надо, то один раз можно и посидеть, чтобы в кеш засосалось.
Другой вопрос, что синхронность при таких раскладах может боком выйти.
Кстати, почитайте топик человека, которому надо трафик на уровне десятка байт в секунду.
И даже меньше. И это правильно, по-моему.
Вот именно и проявилось то, о чем мы говорим постоянно.
Всегда найдется кто-то, кто скажет "а у меня выделенка, у меня все стоит гроши, хочу по полной!"
Наш подход совершенно противоположный - софт должен быстро и стабильно работать на самом плохом канале что только возможен. Чтоб люди сидели на GPRS и все у них получалось.
И софт пишем очень экономный - дистрибан МТ4 весит всего 2.2 мега, а в нем: полнофункциональный терминал, отличный редактор с встроенным хелпом, лайвапдейт, компилятор MQL4 и multilanguage pack.
Я отлично понимаю - возможно, Вам размеры не важны, трафик то "довольно дешевый нынче".
Но это абсолютно против нашего подхода.
ps: никто вообще даже словом не обмолвился о том, что у сервера еще может в обработке висеть пару десятков тысяч открытых позиций, которые надо обсчитывать в рилтайме, контролировать все маржевые требования и срабатывание отложенных ордеров... а это ведь одни из самых трудоемких задач сервера.
Грубо: представьте себе на каждый тик for(i=0;i<10000;i++) { расчет профитов, обновление маржевых требований, контроль стопов и срабатывания отложенных ордеров }, а тут к серверу подключены 1500 (полторы тысячи!) трейдеров с дешевым трафиком и требуют неограниченной подкачки истории :-)
В большинстве случаев это подразумевает
- отсутствие резервирования active/active (при отказе сервера все курят, пока не отремонтируют железяку),
- отсутствие возможности rolling upgrade (то есть сервер для апгрейда выключается нафиг и все курят),
- и, обычно, но не всегда, отсутствие бэкапа, близкого к реальному времени (то есть если сервер умрет, пропадают не последние 30 сек операций, а последние несколько часов).
интересно, как вообще бэкап организован (если есть проблемы с нагрузкой).
Можно, конечно, жаловаться на слабость железа (скажем, если ДЦ жмотятся на оборудование, а на второй сервак еще 200 баксов в месяц вообще никогда не дадут), но это проблемы ДЦ, а сервер, хотя бы теоретически, должен масштабироваться.
А что, у вас все обязательно на одном сервере крутится (на одной железке)?
И торговля, и сервер истории?
А что такое дата центр и что, ДЦ не может его у себя поставить?
Не понимаю, почему вы все время уводите разговор в сторону ...
Ведь торговый сервер и сервер истории- это РАЗНЫЕ сервера, и ДЦ может (и должен) держать их на разных железяках. Причем дата центров (на которые падает нагрузка по подкачке истории) может быть много. Или это все не так?
Почему вы все время говорите про ОДИН сервер?
Что, ваша система не позволяет распаралелиться по задачам? - Тогда это не платформа ..
Или ДЦ такие, что не в состоянии потратить лишнюю штуку баксов на доп. комп.? - Тогда это не ДЦ ..
Или вы просто передергиваете из-за отсутствия других аргументов? - .....
Не требуют, и не неограниченной.
Можете ограничить длину в 2048 - 4096 баров на инструмент.
И загрузка истории может потребоваться только 1 раз - после инсталляции МТ
или соответствующего индикатора.
Если данные уже есть в локальной базе, то пользователь никак не сможет нагрузить сервер, МТ вернет локальные данные.
Это действительно СТАТИЧЕСКИЙ КОНТЕНТ ...
Зачем вы все время передергиваете ... :(((
(надоел уже весь этот бред ..)
(хотелось сделать как лучше, а получается как всегда .. через /dev/ass..)
Чтобы не выдавать голословных заявлений, просто напишите собственный сервер выдачи потокового контента. Отмасштабируйте его до пары тысяч пользователей, параллельно введите сжатие и шифрацию.
Надо бы хотя бы читать описания системы прежде чем ее критиковать:
"Data Center"
Ну и задачка для проверки логики: есть люди, 5 лет пишущие информационно-торговый комплекс, 5 лет практического опыта реальной эксплуатации, больше 70 брокерских компаний где все это работает в реале и есть теоретик с собственными выкладками. Это не в обиду, а чтобы прояснить ситуацию.
Во первых, это может оказаться мало.
Во вторых, распределенный сервер я писал, но не могу вам его продемонстрировать еще, кажется, года три-четыре, поскольку давал подписку о неразглашении (в области защиты данных это обычное дело). Единственно что могу сказать, что по смыслу это было похоже на поисковую машину (но не было ей).
В третьих, 70 брокерских компаний - это, естественным образом, не показатель (см. Windows ранних версий).
В четвертых, если у вас есть эти самые data centers, и все это работает так, как рекламируется, то непонятно, откуда вообще проблема с раздачей исторических котировок, и почему вы так жалуетесь на вычислительную мощность (которая в таком случае нагружена на другую машину, ту, на которой работает центральный сервер). Так что или что-то не работает, как рекламируется, или вам просто лень писать эту раздачу котировок (что, вообще говоря, вполне разумная причина - ну так бы и сказали, только не прикрываясь заботой о нагрузке). Есть еще вариант, что в реальных ДЦ все всегда ставится кучей на одну машину - тогда проблема понятна. Правда, непонятно, почему для реальных клиентов так делается (а если для реальных клиентов ставится так, как на той картинке про datacenters, то почему бы им не раздать историю?).
В пятых, совершенно удивительно ваше упорство в вопросе о шифровании котировок, которые представляют с собой открытые данные (если только речь не идет только о цифровых подписях).
Ну и задачка для проверки логики: есть люди, 5 лет пишущие информационно-торговый комплекс, 5 лет практического опыта реальной эксплуатации, больше 70 брокерских компаний где все это работает в реале и есть теоретик с собственными выкладками. Это не в обиду, а чтобы прояснить ситуацию.
Эту задачку можно представить и в другом виде:
Есть пользователи, которым необходимо гарантированное получение РАЗУМНОГО кол-ва исторических данных для корректного использования инструментов производителя (ArrrayCopyRates, ArrrayCopySeries) и есть производитель, который считает, что такой гарантированный механизм не нужен, так как при его ПОВСЕМЕСТНОМ использовании МОГУТ возникнуть перегрузки.
Интересно, а у других лидеров рынка (TradeStation, ...) тоже нет гарантированного механизма получения исторических данных?
Последнее слово все равно, конечно, останется за MetaQuotes, но хотелось бы, чтобы потребности пользователей тоже были учтены :)
В TradeStation сколько попросиш, столько и будет (хоть за 100 лет).
А в последних версиях (TS6-8) нет GlobalServer'a и все что просиш грузится с их сервака.
Причем грузится очень быстро, несмотря на то, что у них наверняка не менее 100 тыс юзеров.
Причем других датафидов к TradeStation по лицензии быть не может, все только с TradeStation Securities.