Ты все про теорию говоришь. В каком количестве будут сыпать в базу insert при фармящих 500 человек. Возможно со всеми хитростями крихтя пердя и задыхаясь выдержит, но что делать с онлайном 1к+? А на старте? Когда из этой 1000 не на трейде половина, а постоянно фармит и получает/расходует предметы.Почему не будет? Давайте поговорим о фактах.
Хорошие вопросы. Фактов нет, одни теории (не я про это начал).Ты все про теорию говоришь. В каком количестве будут сыпать в базу insert при фармящих 500 человек. Возможно со всеми хитростями крихтя пердя и задыхаясь выдержит, но что делать с онлайном 1к+? А на старте? Когда из этой 1000 не на трейде половина, а постоянно фармит и получает/расходует предметы.
Если она такая удобная и звездатая то почему никто в мире не использует её для нагруженных проектов? Задумайся. Есть случаи использования SQLite, но только в связке с полноценной БД.
В дефолтной ява-сборке 80% кодовой базы не подходит для лайв проекта. При этом, никому это не мешает открываться и пилить фиксы по факту, не занимаясь излишней оптимизацией там, где этого не требуется.Ему говорят что SQLite не подойдет для лайв проекта.
Ну а хули нам. Уникальная концепция сервера под названием "Одна жизнь". Делаем рамдиск и запускаем оттуда сборку. В дц вырубили свет = вайп нахой.
Отличная идея! Скорость будет на уровне RAM! Кажется в этом диспуте родилась сессионка ла2Ну а хули нам. Уникальная концепция сервера под названием "Одна жизнь". Делаем рамдиск и запускаем оттуда сборку. В дц вырубили свет = вайп нахой.
До 1000, с гаком свободно. О чем вы вообще говорите? Либо вы технологии как таковой не понимаете, либо вы ничего подобного вообще не строили. Посмотрите на Яву и их потребности в БД, сколько обновлений идет в секунду? SQLite спокойно, без напряга работает на 10,000 обновлений в секунду. Можно почитать что к чему тут:На самом деле, даже SQLite на хорошем железе спокойно закроет потребность проекта до 50(пятидесяти) человек на пару дней после старта, а большего сейчас и не требуется. Большинство фич той же MariaDB не используется ни в одной сборке, а для большинства админов, держащих легендарные сервера, использование SQLite фактически не отличается от использования MariaDB, т.к они даже репликацию не настраивают, а часто еще на одной тачке GS и DB держат, да еще и под рутом сидят.
Это очень идет сейчас к соревнованиям от разработчиков на Яве. Ни туды, ни сюды. Зато все как обычно. Как родились в навозной яме, так и продолжают борьбу там же, не вылезая.
А, так что же вы раньше не сказали, что ваши заявления не голословны, а базируются на реальных кейсах с вашего лайв-сервера? Это совершенно меняет дело. Мы просто пишем про свой опыт разработки и сопровождения высоко нагруженных систем, с 3000+ живых игроков. Если у вас релевантный опыт, то о чем тогда спорить?без напряга работает на 10,000 обновлений в секунду
Вы привели абсурдно низкий номер без каких-то фактов, или же подтвержения и я привел достаточно высокий номер, но с фактами и числами в ссылке. Так в чем же разговор? Я понимаю что вы приводите мнение, мнительные доводы и номера. Я приводил факты которые можно проверить (я раньше уже рассказывал что тестировал свой сервер с 96 клиентам, вам как-то не удосужелось прочитать, но можно ведь все проверить, мой код есть, толко нужно прописать несколько номерков с клиентами что-бы протестировать...), и досих пор жду нормального диалога а нe мнимых доводов.А, так что же вы раньше не сказали, что ваши заявления не голословны, а базируются на реальных кейсах с вашего лайв-сервера? Это совершенно меняет дело. Мы просто пишем про свой опыт разработки и сопровождения высоко нагруженных систем, с 3000+ живых игроков. Если у вас релевантный опыт, то о чем тогда спорить?
Посмотреть вложение 87878
Потеря 57% пропускной способности при 100 клиентах, это не так много, да. На 1000 клиентов наступит наверное ситуация отрицательной пропуской, когда на запрос записи, база будет закачивать данные обратно в клиент.
Вы поймите что происходит. Здесь очень много людей сo своими мнениями. Им охота что-либо сказать. И я понимаю что разговаривать и действительно применять факты которые можно проверить это достаточно сухо. Далее, люди не хотят иметь диалог, рассуждения на технические темы. Почему? Можно сказать либо знаний не хватает, либо просто охота поговорить о мнениях. Ну вот, я тожe решился включиться в разговор. Всетаки мой проект как-то обсуждают...PS: Постоянно триггерите меня своими сообщениями))) Надо быть более терпеливым)
В таком случае, вы упираетесь в скорость одного ядра процессора(в IO диска скорее всего вы не упретесь уже на современных nvme) + для такой реализации требуется какой-то внутренний буфер или очередь задач. Которая так же аналогично становится узким местом. Что несет на себе риски потери данных при переполнении этого буфера или падении приложения. + это скорее всего очень сильно увеличивает латентностьЭто 100, а у меня один. Это серверный процесс который все либо читает, либо записывает. Это не 100 запросов, не обновлений, это чисто подсоединений на уровне файловой системы
Хороший критицизм, только мнимый. Я про то что это все что вы описали теоретическое, как и три пункта. Вы же сами раньше меня спрашивали пишу ли я эмулятор L2J (эмулятор эмулятора). Все что вы описали сейчас идет как раз из такого мышления - недопонимания. Я понимаю ваше мнение, вот и все, но не принимаю его.MrThirtyOddSix
Проблема в том, что опытному программисту обычно достаточно общего понимания архитектуры какой-то технологии, чтобы примерно прикинуть точки отказа и узкие места.
Для того, чтобы понять, что SQLite является крайне хуевым выбором для сервера Lineage 2, достаточно знать всего лишь несколько фактов об архитектуре этой самой SQLite.
Лично я, например, понимая, что SQLite, это библиотека работающая с файлом базы данных, имеющая критические ограничения на конкурентную запись, невозможность горизонтально масштабироваться, не имеющая механизмов разграничения прав доступа и репликации, уже никогда не выберу ее для высоконагруженого сервера. Просто потому, что я не хочу решать эти проблемы на уровне кода приложения, а хочу получить готовый нужный мне функционал из коробки.
Я не отрицаю, что SQLite хороший инструмент в подходящих задачах, для которых он собственно и был спроектирован, но приложение с очень интенсивным конкурентным доступом на чтение и запись, требующее разграничения прав доступа, и требующее максимальной надежности хранения и обеспечения консистентности данных не подходит под это описание. Зато замечательно подходит под описание того, для чего использование SQLite является анти-паттерном.
Да, безусловно, это занятный челендж, с помощью программных костылей обходить фундаментальные ограничения используемого программного стека, но я предпочитаю тратить время на разрабатываемый продукт.
Поэтому, смотря на ваш выбор движка базы данных для l2 эмулятора, у меня всего лишь несколько вариантов логических объяснений:
1) Вы понимаете, что с вероятностью математически неотличимой от 100%, ваш код никто не станет использовать в настоящем серьезном проекте, поэтому делаете этот выбор осознано, чтобы снизить сложность разработки и упростить код, а на форуме просто развлекаетесь, тролля собеседников.
2) Вам интересно превозмогать и это ваш личный хакатон. + пункт 1
3) Вы изначально не задумывались об этом, а теперь уже слишком поздно и вам просто лень переписывать все на нормальный движок, т.к пункт 1.
В таком случае, вы упираетесь в скорость одного ядра процессора(в IO диска скорее всего вы не упретесь уже на современных nvme) + для такой реализации требуется какой-то внутренний буфер или очередь задач. Которая так же аналогично становится узким местом. Что несет на себе риски потери данных при переполнении этого буфера или падении приложения. + это скорее всего очень сильно увеличивает латентность
PS: При этом, я не буду отрицать, что в конкретных условиях и под конкретные задачи такое решение может быть жизнеспособно и даже лучше классической модели. Просто я проецирую это решение на себя и отвергаю его, как потенциально непредсказуемое и повышающее риск отказа в критически важном элементе движка сервера.
Я не спорю. Но мне непонятнa сама идея того что люди сидят и думают что сегодняшний подход к решению проблем (даже мысление) должен быть строго применим к любому проекту. За 15 лет L2J что изменилось? Да отполировали код, да он работает, худо-бедно иногда круто. Но каким то образом не поменялся подход к решению проблем. Почему применяется MariaDB, когда есть други базы данныx? Почему формат геодаты как-то не меняется (я говорю про начинку которой почти 25 лет, формат от PTS) ? Почему нельзя урезать множество запросов от БД что-бы не нужно было заботиться о ее тонкой настройке? Вопросы реторического характера неправда? Все что я видел показывает на то что никому ничего не интересно разрабатывать. Помните я тут написал про навозную яму? По теме Ява серверов почти все так и осталось тем же, нигде улучшений кроме как поддержка новых клиентов. Единственное что меня удивило так это Lucera. Там есть интересные вещи, но и она не так далеко ушла.Дак о чем спорить то? Вы хотите конструктивной критики? Хотите объективной оценки? Нет. Мне(и скорее всего не только мне), тупо не досуг тезисно отвечать на ваши сообщения, писать простыни контр аргументов, искать в сети цитаты, бенчмарки и прочее. Это сугубо ваш пет-проект и все особенности реализации - только ваш осознанный выбор. Если в рамках ваших компетенций вас все устраивает, у вас ничего не щелкает в голове, не закрадываются нехорошие подозрения, то значит все отлично.
Я не пытаюсь обесценить ваше решение или ставить себя в позицию ментора. Я лишь указываю, что моя точка зрения сформирована в том числе и моим опытом. Поэтому, в вашем решении вы берет на себя риски, которые я, пропуская через призму своего опыта, считаю недопустимыми в моих задачах. Вопрос сугубо к контексте и уровне рисков.Хороший критицизм, только мнимый. Я про то что это все что вы описали теоретическое, как и три пункта. Вы же сами раньше меня спрашивали пишу ли я эмулятор L2J (эмулятор эмулятора). Все что вы описали сейчас идет как раз из такого мышления - недопонимания. Я понимаю ваше мнение, вот и все, но не принимаю его.
Насчет процессора. Любая программа будет упираться в скорость одного или друго-го ядра процессора. Но вы недосказали о том почему вы так высказались. Я думаю что вы посчитали что сервер у меня будет работать только на одном процессе и одром потоке. Нет конечно. Есть задачи которые будут решаться на других потоках. Сейчас используется два потока: один главный а другой отвечающий за движение всех персонажей. Немного похоже на то что и работает в L2J и всех его вариантах. Дальше будут внесены потоки на поиск пути. Посмотрим где и как.
Я не спорю. Но мне непонятнa сама идея того что люди сидят и думают что сегодняшний подход к решению проблем (даже мысление) должен быть строго применим к любому проекту. За 15 лет L2J что изменилось? Да отполировали код, да он работает, худо-бедно иногда круто. Но каким то образом не поменялся подход к решению проблем. Почему применяется MariaDB, когда есть други базы данныx? Почему формат геодаты как-то не меняется (я говорю про начинку которой почти 25 лет, формат от PTS) ? Почему нельзя урезать множество запросов от БД что-бы не нужно было заботиться о ее тонкой настройке? Вопросы реторического характера неправда? Все что я видел показывает на то что никому ничего не интересно разрабатывать. Помните я тут написал про навозную яму? По теме Ява серверов почти все так и осталось тем же, нигде улучшений кроме как поддержка новых клиентов. Единственное что меня удивило так это Lucera. Там есть интересные вещи, но и она не так далеко ушла.
Про упор в CPU, но при этом не в упор в NVME кринжанул
Это связано. Я имел ввиду не упор в CPU при записи в базу, а упор в CPU на разгребании внутренней очереди, которая неизбежно появляется в такой модели. Хотя, я возможно тоже мысль не корректно изложил.Простыни текста читал наискосок
Я описал причины, по которым для меня SQLite бы не стал хорошим выбором. Скорости в этом списке нет.И выбирают их совсем не из-за скорости работы.
а как же сервер для себя...Я только одно не понимаю, а кому оно надо? Мы вот щас тут наоптимизируем и на выходе все равно получим продукт с высоким риском на фейл. зОчем?
А че не таблицы в excel?а как же сервер для себя...
Стоп, а есть ли нафиг разница какая база данных? Хоть в .csv пиши.
если уж выбирать БД, то AccessА че не таблицы в excel?
Йо, тут имеется в ввиду активных соеденений. Тобишь "client".А, так что же вы раньше не сказали, что ваши заявления не голословны, а базируются на реальных кейсах с вашего лайв-сервера? Это совершенно меняет дело. Мы просто пишем про свой опыт разработки и сопровождения высоко нагруженных систем, с 3000+ живых игроков. Если у вас релевантный опыт, то о чем тогда спорить?
Посмотреть вложение 87878
Потеря 57% пропускной способности при 100 клиентах, это не так много, да. На 1000 клиентов наступит наверное ситуация отрицательной пропуской, когда на запрос записи, база будет закачивать данные обратно в клиент.
PS: Постоянно триггерите меня своими сообщениями))) Надо быть более терпеливым)
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?