170 ответов в теме

[Gmoorick]

Имею Опыт перевода баз данных с MS SQL на Постридж, затем обратно и потом на IBM DB, это все SQL и сдесЯ в обще проблем нету для тех кто в теме.

Проблем нету, до тех пор пока ты используешь только чистый sql. Боюсь что таким разработчики евы не ограничились.

И опять же 120, не 40 тысяч

[yatsik]

в обще я так понимаю речь идет не о 40 тыщах ) ведь при флит зарубах лагает не весь сервер, а там где заруба, собственно и накинуть на опасные места по больше железа.

З.Ы. а что можно использовать в субд на SQL языке кроме данных в sql ? и тем более в MS SQL?

[AloneIbreak]

2 цели для каждого пилота? сэр, вы сидели в дреде? 2 цели = постоянно стрелять практически нереально. и это при стрельбе по кэпиталам с ~2кк эфф хп - то что вы предлагаете означает что 40-50% времени боя человек будет не стрелять а тупо пытаться хоть что-нибудь залочить и выстрелить хоть разок.

мне кажется автор имел в виду не макс. количество залоченых целей. а количество целей которые можно лочить (сам процесс лока, когда полоска уменьшается и отсчёт времени идёт) ОДНОВРЕМЕННО
так у тебя 6 целей макс. и ты запускаешь лок на 6 шипов и ждёшь пока они залочатся. а так будешь по 2 лочить

[Gmoorick]

З.Ы. а что можно использовать в субд на SQL языке кроме данных в sql ? и тем более в MS SQL?

http://www.microsoft...5/tsprfprb.mspx
http://www.microsoft...its_queues.mspx
вот пара статеек на тему оптимизаций скуль сервака. Думаю найдешь много нового и интересного.

в обще я так понимаю речь идет не о 40 тыщах ) ведь при флит зарубах лагает не весь сервер, а там где заруба, собственно и накинуть на опасные места по больше железа.

проблема №1.
Сложность обработки действий одновременно взаимодействующих объектов (считай шипов игроков) растет как минимум экспоненциально. Скорее всего это н-п полная задача. Т.е. чтобы получить сервак на 600 человек надо, чтобы он был в разы производительнее сервака на 500 игроков.
проблема №2.
Девы оптимизируют/делают новый сервак, так чтобы он держал 700 человек. Игроки этому радуются и пробуют воткнуть туда тысячу. В итоге получаем теже лаги.

Как уже говорили самые толковые люди - решать надо причины по которым эти блобы собираются.

Сообщение отредактировал Gmoorick: 07 August 2008 - 11:36

[piroksilin]

А почему бы ССР не ввести стек пенальти просто на количество кораблей во флоте ? >20 - на 25% ниже дамаг скорость лока и скорость.

[Starslayer]

Как уже говорили самые толковые люди - решать надо причины по которым эти блобы собираются.

+1


не стоит ждать того, что лаги волшебным образом исчезнут

[deadok]

Что за глупости? Я выше топик привел возможные доходы, даже пусть подписчиков как я указал не 50 тыщ а 41 тыща, и все из нас видели такое кол-во в прайм тайм, а это 574 тыщи баксов, в месяц, сколько там сотрудников я дуцмаю максимум с уборщицами 30 зарплата я думаю 4 штуки в среднем это 120 штук, ну за интернет свет и охрану еще 20 штук уберем минимум маржа штук 300 в месяц капает боссам, один два месяца и можно скопить на ахеренные системы 4+ процовые по 32 гига озу этак штук 5 серваков и объеденить в один, это даст афигенный прирост производительности.

на данный момент (по последнему блогу) используются блейдцентр из 56 http://www-03.ibm.co...ls21/index.html.

т.е сейчас ноду могут обслуживать максимум 4 ядра, из представленного в линейке блейдцентров лучше сомтрятся только hs21 и ls41, (2x4 или 4x2), такчто грубо говоря производительность отдельной ноды теоретически можно поднять в 2 раза.

далее имхо
однако сдается мне, что основную нагрузку составляют не вычисления, а обмен данными. такчто увеличение числа ядер позволит создать больше нод, а не поднять производительность одной ноды.
или, более простыми словами, с переходом на 8-ядерную схему жита по прежнему не сможет держать 2000 игроков, зато на одном блейде можно будет уместить 2 хека,например.
такчто основные проблемы: эффективное динамическое перераспределение ресурсов и пиковую нагрузку на ноду, покупка новых серверов не решит.

А почему бы ССР не ввести стек пенальти просто на количество кораблей во флоте ? >20 - на 25% ниже дамаг скорость лока и скорость.

заблобливание эффективно понижает и скорость лока и скорость и дпс, и воопще считай все.
это не тот случай, когда можно бороться огнем против огня.
вот скажем выдавать приоритет меньшим флотам - неплохая идея в задумке, но порочная в реализации альянс А приводит 50 человек, а дружественные альянсы Б и В по 40, и хрен знает кому приоритет отдавать.

[yatsik]

просто Оракл это решение для огромных задач, а MS SQL для среднего бизнеса, даже у нас в России такие гиганты как МТС и Биллайн свои БД держут только на ОРАКЛ, я думаю это показатель

Сообщение отредактировал yatsik: 07 August 2008 - 12:47

[MOH]

т.е сейчас ноду могут обслуживать максимум 4 ядра, из представленного в линейке блейдцентров лучше сомтрятся только hs21 и ls41, (2x4 или 4x2), такчто грубо говоря производительность отдельной ноды теоретически можно поднять в 2 раза.

Более того я не нашел что они решили проблему с GIL. и похоже ноду обслуживает одно ядро.
http://myeve.eve-onl...amp;page=10#285

http://myeve.eve-onl...threadID=682229

Как уже говорили самые толковые люди - решать надо причины по которым эти блобы собираются.

Блобы собираются, по причине того что люди хотят победить. Или есть другие причины?

Сообщение отредактировал MOH: 07 August 2008 - 12:50

[Tamer]

Решить проблему блобов можно только одним способом - переписать сервер с питона и избавиться от десинков.

piroksilin - глупость, будут просто летать 10-ю флотами в одной системе.

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

[MOH]

Решить проблему блобов можно только одним способом - переписать сервер с питона и избавиться от десинков.

piroksilin - глупость, будут просто летать 10-ю флотами в одной системе.

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

Пинцет. совсем пинцет.

Какой нафиг SQL, мультикоры и т.п. ИМХО, им нужно всем учится. Или я чегото не понимаю в жизни.
http://myeve.eve-onl...amp;page=10#291

Делать все в одном треде? И размышлятъ о том что семафоры это тяжело?

Do you really want a multi-threaded combat engine?

Пинцет, весь мир лет 30 пишет "combat engine" на парралельных вычислениях.

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

Сообщение отредактировал MOH: 07 August 2008 - 13:23

[Dfire]

Решить проблему блобов можно только одним способом - переписать сервер с питона и избавиться от десинков.

piroksilin - глупость, будут просто летать 10-ю флотами в одной системе.

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

И как это решит проблему_блобов?
Может от лагов и избавятся, но блобы будут...

[Starslayer]

И как это решит проблему_блобов?
Может от лагов и избавятся, но блобы будут...

а если лагов не будет, то какую тогда проблему создает блоб?

[Ivan Dark]

никакой

[Gmoorick]

Блобы собираются, по причине того что люди хотят победить. Или есть другие причины?

когда ты собираешься победить хантера, собираешь 500 человек ?

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

Вот только для таких трех типов ивентов собираются все возможные пилоты, которые есть в онлайне.

Пинцет. совсем пинцет.

Какой нафиг SQL, мультикоры и т.п. ИМХО, им нужно всем учится. Или я чегото не понимаю в жизни.
http://myeve.eve-onl...amp;page=10#291

Делать все в одном треде? И размышлятъ о том что семафоры это тяжело?

Пинцет, весь мир лет 30 пишет "combat engine" на парралельных вычислениях.

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

Постарайся перевести весь пост. Там описаны причины, чем грозит распараллеливание таких вычислений.

[RAzZin]

А почему бы ССР не ввести стек пенальти просто на количество кораблей во флоте ? >20 - на 25% ниже дамаг скорость лока и скорость.

бтв была такая идея у ССР..

Где-то к весне (надеюсь) запустят новый сервер - на него потратили, если не ошибаюсь, больше 10млн USD. Плюс переписывают очень большой процент кода, переделывают UI.. Плюс ССР должны отказаться от системы нод, сервер будет обрабатывать события полностью динамически. Надеюсь, это улучшит ситуацию с лагами ))

А, ну а блобы - никуда не денутся, их только больше станет %))

Сообщение отредактировал RAzZin: 07 August 2008 - 17:46

[MOH]

Вот только для таких трех типов ивентов собираются все возможные пилоты, которые есть в онлайне.

Постарайся перевести весь пост. Там описаны причины, чем грозит распараллеливание таких вычислений.

1. Ну да, они собираются чтобы проиграть, да?

2. Причины там написаны, которые позволяют сделатъ выводы об небольшой некомпетентности разработчиков в программировании таких систем. На что им резонно советуют поговоритъ со специалистом а еще лучьше, пойти учится, и/или менять среду. (немного дальше в треде).
Это я написал до того как я перевел дословно, дословный вдумчивый перевод меня просто убил. все намного хуже. они даже сейчас дамаг неправилъно (с моей точки зрения) считают.

Do you really want a multi-threaded combat engine? Your using a more complex setup than me and your hit/damage calculations take longer to perform, than mine on a simpler setup, but because of multi-threading mine are threaded out and complete first so my damage is applied to you first, even though when you damage calculations are completed it turns out I am dead .... not really the situation we want.

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

ИМХО, в корне не верное утверждение. Если система использует синхронную систему обсчета дамага, то так иммено и нужно считать, дамаг обоих, потом уже принятие решение кто убит кто нет, и тогда будет честный бой и даже возможностъ убитъ друг друга.

Из того что он пишет, можно сделатъ вывод что у них система не только медленная, но и ИМХО неправильная. Поскольку кто раньше встал, того и тапки. Если они прикладываят дамадж (и сразу убивают) до того как приложили твой. т.е. если тебя убиваеют за ЭТОТ ход, ты свой ход пропускаешь, и молча умираешь не нанеся дамаг противнику.

Т.е. дев утверждает что если 2 коробля (первый с 100 структурой, воторой 110) стреляют одновременно друг по другу с дамагом 101, результат должен бытъ:

один труп а у второго 110 стуктуры?
а не
один труп и у втотрого 9 структуры?

Я фигею дорогая редакция, может у меня совсем плохо с английским? поправте пожалуйста... или так действительно задуманно и реализованно?
Я сначала даже это не так понял, думал он сокрушается что не знает как треды синхронизировать...
Написал стену текста, а все гораздо, ИМХО, хуже. У меня обостренное восприятие справедливости, так как они сейчас считают дамаг это нормально? (если я правильно понял английский текст и сделал правильные выводы)

Сообщение отредактировал MOH: 07 August 2008 - 20:14

[Tamer]

Пинцет. совсем пинцет.

Какой нафиг SQL, мультикоры и т.п. ИМХО, им нужно всем учится. Или я чегото не понимаю в жизни.
http://myeve.eve-onl...amp;page=10#291

Делать все в одном треде? И размышлятъ о том что семафоры это тяжело?

Пинцет, весь мир лет 30 пишет "combat engine" на парралельных вычислениях.

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

Ой лол, а я и не знал, что ева построена на одном потоке на сервер Кошмар, интересно почему они не могут нанять нормальных девов? Денег чтоль не хватает? )

Сообщение отредактировал Tamer: 07 August 2008 - 19:57

[Gmoorick]

Я сначала даже это не так понял, думал он сокрушается что не знает как треды синхронизировать...
Написал стену текста, а все гораздо, ИМХО, хуже. У меня обостренное восприятие справедливости, так как они сейчас считают дамаг это нормально? (если я правильно понял английский текст и сделал правильные выводы)

да боюсь что ты не так понял.

Сейчас имеем.
1 поток ОБРАБОТКИ дамаги. Т.е. приходят мессаги с сообщениями о нанесенном дамаге по такойто цели. Они ставяться в очередь. Обработка этой очереди выполняется в 1 поток. Выстрел - посчитали живой или нет, обработали другой выстрел.

Теперь многопоточность.
Берем по потоку на каждого участника в битве. Чтобы это была многопоточность, надо подсчитывать дамаг за какойто интервал времени. К примеру пусть будет 5 секунд. Маловерятно, но возможно, что первый умирает в 1ую секунду, второй в 4ую. Бах оба умерли. Чтобы таких ситуаций было меньше, надо делать меньше интервалы времени для синхронизации. Можно после каждой нанесенной единицы дамаги, делать блокировки тредов. Оба этих способа могут привести к тому, что линейно решать будет выгоднее чем в несколько потоков. Не забывай, что на поддержку многопоточности и синхронизации тоже тратиться достаточно большое время. И единственно где она реально приносит пользу, это при обработке несвязных событый.

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

Короче, давай сделаем так. Я напишу какуюнить генерацию событый событий типа я такойто нанес столько то дамаги по такомуто + линейный алгоритм подсчета, а ты сделаешь многопоточную реализацию дамаги. Потом сравним что лучше считает. Ок ?

Сообщение отредактировал Gmoorick: 08 August 2008 - 10:02

[DeTech]

Когда-то кто-то писал, что масса 50 дредов сравнима с массой планеты - т.е. мощные гравитационные изменения в системе. В свою очередь сами корабли же напичканы всякой электроникой типа варп движка, сенсоров и тп. Так почему бы не сделать помехи от количества/качества кораблей в системе/гриде. Тогда даже в случае 100 VS 300 помехи будут у всех одинаковые и стрелять/варпать/лочить будет одинакого плохо. Помехи можно поделить на 3 класса - в системе, в гриде и в радиусе N километров своего "power ball".

Во первых писали чушь, масса Земли к примеру равна массе 4,800,000,000,000,000 ревелейшенов
Во вторых, помехи при блобах не приведут к отказу от этих блобов. Просто все будут материть ССР и продолжать драться даже при этих помехах блобами. Собстно опыт боев в лагах это показывает