81 ответов в теме

[Trimutius III]

Нет ну просто ситуацию представьте, летит флот в 100 рыл. И тут фк грит варп на такую-то буку, до пустим у всех корп эта бука внесена в корп буки, и весь этот флот тыкает чтобы показало корпбуки, и скока раз одни и те же буки будут считаны во время такого полёта? причём учтите что одна и та же бука будет считываться для разных компов 100 раз, это совсем не то же самое что брать личную инфу из разных мест и пересылать игрокам... тут эффективно распараллелить куда как сложнее...

[Korvin]

Нет ну просто ситуацию представьте, летит флот в 100 рыл. И тут фк грит варп на такую-то буку, до пустим у всех корп эта бука внесена в корп буки, и весь этот флот тыкает чтобы показало корпбуки, и скока раз одни и те же буки будут считаны во время такого полёта? причём учтите что одна и та же бука будет считываться для разных компов 100 раз, это совсем не то же самое что брать личную инфу из разных мест и пересылать игрокам... тут эффективно распараллелить куда как сложнее...

Что такое кеш надеюсь все знают?

Вобщем "лагов" не будет, если сделать грамотно все.
Остальное - от чьей-то лени или некомпетентности.

Сообщение отредактировал Korvin: 23 November 2011 - 22:12

[Trimutius III]

Что такое кеш надеюсь все знают?

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

[LapaM]

Что такое кеш надеюсь все знают?

Вобщем "лагов" не будет, если сделать грамотно все.
Остальное - от чьей-то лени или некомпетентности.

С такой формулировкой не поспоришь. Но лично у меня сложилось мнение, что CCP = лень и некомпетентность. Надеюсь этот патч улучшит мое мнение о них

[Korvin]

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

Так и сейчас нельзя - вся инфа с бук копируется при открытии папки с буками в клиента, в этот самый кеш.
Еще запрос на выборку этих бук на конкретную солнечную систему поступает при пропрыге в систему, для ПКМ.

Потом уже со стороны клиента идет тупо запрос - варп на буку ИД такой-то.

Так что похрену, сколько их и где, если они разложены по папкам. Лаг будет только при открытии этой папки в первый раз - у человека что открыл. И то не изза трафика там, и запросов - ибо напомню - 10к бук - это не больше 300кб, а изза тупого рендеринга интерфейса.

Сообщение отредактировал Korvin: 24 November 2011 - 0:04

[Snark]

И то не изза трафика там, и запросов - ибо напомню - 10к бук - это не больше 300кб

ты сначала это предположил, а теперь выдаешь за достоверную информацию.

[Korvin]

ты сначала это предположил, а теперь выдаешь за достоверную информацию.

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

Даже в этом случае, даже с учетом юникода, и предположением что имена бук хранятся в той же базе, что и ид с координатами.
242 байта на запись - это 2,3 мегабайта на 10к бук. При скорости подключения 1мб - это 2 секунды загрузки в кеш при логине + раз в 5 минут проверка на наличие новой записи в корп буках (дополнительный запрос от клиента на сервер, как при пропрыге) байтов 10 максимум и ответ с новыми буками - 242 байта на буку. Все это может делаться в фоновом режиме.

Сообщение отредактировал Korvin: 24 November 2011 - 9:20

[CHoh]

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

Даже в этом случае, даже с учетом юникода, и предположением что имена бук хранятся в той же базе, что и ид с координатами.
242 байта на запись - это 2,3 мегабайта на 10к бук. При скорости подключения 1мб - это 2 секунды загрузки в кеш при логине + раз в 5 минут проверка на наличие новой записи в корп буках (дополнительный запрос от клиента на сервер, как при пропрыге) байтов 10 максимум и ответ с новыми буками - 242 байта на буку. Все это может делаться в фоновом режиме.

Вдруг там радостно выделяется аж целый стринг на название буки и куча стрингов на каждое поле с циферками
Мы не знаем, добрались ли переписыватели кода евы до кода самих букмарок. А то, что написано исландскими студентами 10 лет назад, может наверно любого в ступор вогнать.

Алсо если они планируют монетизировать функцию доп.места под буки, им нет особого резона давать всем по 10тыщ.

Сообщение отредактировал CHoh: 24 November 2011 - 15:35

[Korvin]

Алсо если они планируют монетизировать функцию доп.места под буки, им нет особого резона давать всем по 10тыщ.

Вот с этого и надо начинать, а не отмазываться дешевым "мы экономим ресурсы".

Сообщение отредактировал Korvin: 24 November 2011 - 20:08

[serfguygbv]

Нахрена их вообще ограничивать?

Каждый игрок за свою жизнь сделает допустим 10000 букмарок, допустим каждая букмарка весит 30 байт, итого за всю свою жизнь игрок сделает бук аж на... 293 килобайта!
Возьмем базу подписчиков вместе с офлайн чарами по моим данным около 8 миллионов. Итого на букмарки ВСЕЙ ЕВЫ затрачивается всего 2160 гигабайт. Это всего 3 харда по терабайту в рейде.
На самом деле у среднего игрока около 2к букмарок.

10000 бук * 350000 игроков = 3.500.000.000 бук. Три миллиарда пятьсот миллионов бук.
Только безмозглый хомяк не понимает, какую нагрузку будет давать выолпнение даже элементарного запроса к БД, в которой болтается три с гаком миллиарда записей, и какие будут лаги, если эта БД будет получать сотни запросов в секунду. Даже если под эту БД выделить отдельный сервер - лаговать такие буки будут безбожно.
Флитком командует варп на буку, все дружно тыкают - и... начинают варп с разбросом +- 1 минута. И начинаются стоны "лаги, лаги". Хомячки такие хомячки.

Я уж не говорю про то что 10к бук на тело - это нифига не предел. Когда тело варпает и спамит постановку бук - за один заход тело может легко поставить под сотню бук. А потом полениться их стереть. 100 таких варпов со спамом бук - и 10к бук готово. Потом тело улетает из сисы (если это скажем была какая-нить ВХ) - и больше так и не вспомнит, что у него уже поставлено 10к бук. И продолжит срать буками через день снова в другой сисе.

Когда хомяки срут где попало и сколько попало - приходится их ограничивать, иначе они могут засрать все доступное пространство - сколько им его не давай. А потом сами же начнут вайнить что все засрано и не получается быстро бегать. Так что ничего не поделать.

Ах да. Это идеальный вариант - когда можно лишь посмотреть список бук, удалить ненужную, добавить новую, и варпнуть на выбранную.
Про поиск буки по части названия и прочее при таком раскладе можно забыть 100% - что тоже вызовет вайн хомячков.

Сообщение отредактировал serfguygbv: 25 November 2011 - 15:47

[Korvin]

10000 бук * 350000 игроков = 3.500.000.000 бук. Три миллиарда пятьсот миллионов бук.
Только безмозглый хомяк не понимает, какую нагрузку будет давать выолпнение даже элементарного запроса к БД, в которой болтается три с гаком миллиарда записей, и какие будут лаги, если эта БД будет получать сотни запросов в секунду. Даже если под эту БД выделить отдельный сервер - лаговать такие буки будут безбожно.
Флитком командует варп на буку, все дружно тыкают - и... начинают варп с разбросом +- 1 минута. И начинаются стоны "лаги, лаги". Хомячки такие хомячки.

Я уж не говорю про то что 10к бук на тело - это нифига не предел. Когда тело варпает и спамит постановку бук - за один заход тело может легко поставить под сотню бук. А потом полениться их стереть. 100 таких варпов со спамом бук - и 10к бук готово. Потом тело улетает из сисы (если это скажем была какая-нить ВХ) - и больше так и не вспомнит, что у него уже поставлено 10к бук. И продолжит срать буками через день снова в другой сисе.

Когда хомяки срут где попало и сколько попало - приходится их ограничивать, иначе они могут засрать все доступное пространство - сколько им его не давай. А потом сами же начнут вайнить что все засрано и не получается быстро бегать. Так что ничего не поделать.

Ах да. Это идеальный вариант - когда можно лишь посмотреть список бук, удалить ненужную, добавить новую, и варпнуть на выбранную.
Про поиск буки по части названия и прочее при таком раскладе можно забыть 100% - что тоже вызовет вайн хомячков.

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

Ты когда в систему прыгаешь - такой запрос проходит каждый раз. Омг лаги?
Все варпают на фк сейчас - все делают запрос на сервер, сервер всем спамит координаты флиткома, будет спамить координаты букмарки. Разница есть?

Это изменение меняет всего 1 штуку - добавляет в поле букмарки ид корпы кроме ид чара. Соответственно в запросе проверка на ид корпы чара = ид корпы буки. Все.
Сейчас можно тыкать 100500 бук. Что изменится с введением 1 поля? Несколько байт на каждую буку. Так что ввод ограничений не оправдан с техничесой стороны. Возможно есть другие причины - гейм дизайн, прицел на донат, но уж точно не проблема лагов.

[gwinblade]

вопрос в количестве инфы в поле "координаты в системе"

[serfguygbv]

Ты когда в систему прыгаешь - такой запрос проходит каждый раз. Омг лаги?
Все варпают на фк сейчас - все делают запрос на сервер, сервер всем спамит координаты флиткома, будет спамить координаты букмарки. Разница есть?

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

Если сделать как ты предлагаешь - неограниченное число букмарок на тело - то будет таблица с несколькими миллиардами записей. Ты понимаешь разницу между миллионом и миллиардом? И разницу между стоимостями запросов к таблицам с миллионом и с миллиардом записей?

И кстати до кучи - твои слова про "три винта по терабайту" - это полный бред. Ты никак не можешь вкурить, что проблема не в хранении данных, а в их использовании и в поиске по ним. Ну лежат у тебя эти три лярда букмарок на винтах, и что? Ты представляешь сколько будет выполняться один запрос на поиск и извлечение одной букмарки? Ты будешь ждать полминуты, пока сервер букмарок будет лопатить 3 терабайта данных в поиске твоей букмарки когда ты жмакнул варпнуть на нее?

Ты вообще осознаешь, что у сервера оперативки - ну 64гига? Ну 128гиг максимум. Это значит что твои три терабайта данных лежат на винтах. Это значит, что чтобы найти твою букмарку, по одному твоему запросу, серверу надо лопатить по этим трем терабайтам через интерфейс с пропускной способностью в сотню мб/c.

Да, есть индексирование, есть бинарные деревья - но все то позволит сократить время поиска твоей букмарки до долей секунды в самом лучшем случае. А теперь представь что в еве каждую секунду происходит сотня выборок букмарок - потому что десятки людей одновременно варпают на буки, делают их, удаляют, просматривают. И когда ты жмакнул на букмарку - твой запрос на получение данных этой букмарки стал сотым в очередь, в которой каждый из запросов - поиск среди трех терабайт данных, который займет 0.1с в лучшем случае.
Тебе придется ждать десятки секунд "лага" до начала варпа на буку - пока дойдет очередь до твоего запроса на сервере букмарок, и он выполнится - и ты тут же побежишь вайнить - что все лагает, что букмарки бесполезны при таких лагах, что разработчики игры тупые.

А секрет прост - на самом деле тупой - ты, потому что совершенно не представляешь о чем говоришь. А если представляешь, и знаешь как сделать поиск по 3-х-терабайтной базе данных - то пиши скорее такую базу данных - станешь миллиардером, а mssql канет в лету.

Сейчас можно тыкать 100500 бук.

Сейчас это твои личные буки, среди которых не надо искать при выполнении запроса на получение буки Джоном или Васей.

Сообщение отредактировал serfguygbv: 25 November 2011 - 18:42

[Psihius]

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

Так что, парни, прекратите спорить - не похоже что бы у вас был опыт в построении хотя бы серверных приложений с более-менее приличным трафиком запросов к ним.

[Korvin]

Сейчас это твои личные буки, среди которых не надо искать при выполнении запроса на получение буки Джоном или Васей.

Ок, мои личные буки, я на них варпаю, идет запрос.
Джон и Вася - тоже имеют свои буки, тоже на них варпают, тоже идет запрос.

Теперь есть одна общая бука - на нее делает варп Джон и Вася, те же 2 запроса.

Есть разница? Нет.

Если ты переживаешь изза массовости запросов - типа варпает флот на буку.
Такий запрос идет при пропрыге в систему вместе с прогрузкой всего остального в любом случае, ничего страшного не случается.

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

[Snark]

Корвин, тебе про Фому, а ты про Ерему тебе же болдом выделили важные моменты, а ты на запросах залип. Понимание проблемы на уровне обычного геймера, но считаешь, что "тупые" именно в ССР.

[Korvin]

Корвин, тебе про Фому, а ты про Ерему тебе же болдом выделили важные моменты, а ты на запросах залип. Понимание проблемы на уровне обычного геймера, но считаешь, что "тупые" именно в ССР.

С чего ты взял, что миллионы превратятся в миллиарды? XD

На данный момент никаких ограничений нет, и все работает нормально.

Корп буки от бук игроков ничем кроме 1 поля не отличаются.

Бук прибавится ровно столько, сколько есть активных корпораций. По сравнению с количеством чаров - это мизер.

Сообщение отредактировал Korvin: 26 November 2011 - 12:10

[Snark]

да я вообще не понимаю, что ты за эту тему зацепился, новость клевая, точка

[amardil]

Ну я в последнее время частенько замечаю, что у Корвина какая-то попоболь в отношении ЦЦП. Столько желчи я от него раньше не видел. Могу даже предположить зависть к Дичу: при нем-то самом в ЦСМ ЦЦП так не шевелились

[Korvin]

Ну я в последнее время частенько замечаю, что у Корвина какая-то попоболь в отношении ЦЦП. Столько желчи я от него раньше не видел. Могу даже предположить зависть к Дичу: при нем-то самом в ЦСМ ЦЦП так не шевелились

Хех. Почитай результаты самитов 4 и 5 ЦСМ, сравни с девблогами, увяжи с проектом 1000 мелочей - у тебя резко наступит прозрение.

В отличии от нынешнего ЦСМ, протоколы наших обсуждений открыты.
НДА распространяется на решения и планы компании, а не мнение и обсуждение проблем игры членами ЦСМ.
В отличии от нас, нынешний ЦСМ сам решил зарыть процесс обсуждений.

И таки да, мое мнение не всегда совпадает с мнением ЦЦП.

пы.сы. Какая может быть зависть к Дичу, если я сознательно не балатировался на этих выборах?

Сообщение отредактировал Korvin: 28 November 2011 - 0:42