Cashed true system

[Zubastic]

Сообщение от linliss

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

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

Просто не думаю, что кто-то кроме крупных проектов будет еще 1 машину под кешед делать. В итоге все будет стоять на 1 машине.

[Ozzy]

Оффтоп:

Свернуть ↑

Сообщение от ASevenfold

Тем что мы тратим кучу процессорного времени на работу с БД напрямую. Кешед очень даже нужная вещь, т.к. он позволяет убрать все это дело нахрен и лишь время от времени заливать данные в БД (эдакий автосейв), при том, что сама вся база кешируется и мы работаем с ней в ОЗУ без лишних обращений, так же и модифицируем, в ОЗУ.

Как служится?

Свернуть ↑Развернуть ↓

[Yorie]

Сообщение от ASevenfold

Тем что мы тратим кучу процессорного времени на работу с БД напрямую. Кешед очень даже нужная вещь, т.к. он позволяет убрать все это дело нахрен и лишь время от времени заливать данные в БД (эдакий автосейв), при том, что сама вся база кешируется и мы работаем с ней в ОЗУ без лишних обращений, так же и модифицируем, в ОЗУ.

На это есть отложенные запросы и bulk-операции, и не понадобится никакой дополнительный кэш, оперативная память ГСа - это и есть кэш, к тому же, наиболее быстрый. Если бы в опен-сорс проектах L2J делали базу изначально по уму, то не было бы огромных проблем с работой БД. Когда только начинал ковырять сборки, находил уйму performance miss'ов по типу кучи отдельных запросов вместо одного, или отсутствия нужных ключей и индексов на таблицах. Ну а о структуре и 3 НФ лучше вообще не упоминать.

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

[n3k0nation]

Сообщение от rage

А что мешает реализовать работу с БД в отельном потоке? К тому же, не замечал нехватки проца на ява сборках, даже при очень больших нагрузках.

К тому же "кешировать БД" не совсем правильный подход, если БД не справляется то нужно ее тюнить либо менять. БД на то и БД, что бы все работало быстро и удобно, без всяких надстроек.

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

:

Свернуть ↑

Сообщение от Ozzy

Оффтоп:

Свернуть ↑

Как служится?

Свернуть ↑Развернуть ↓

На новый год в отпуск

Свернуть ↑Развернуть ↓

[pchayka]

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

и тем не менее на птс-ах кешед валится как березка едва коннект к БД задержится. И тащит за собой гейм.

[n3k0nation]

Сообщение от pchayka

и тем не менее на птс-ах кешед валится как березка едва коннект к БД задержится. И тащит за собой гейм.

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

[Ozzy]

Оффтоп:

Свернуть ↑

Сообщение от ASevenfold

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

:

Свернуть ↑
На новый год в отпуск

Свернуть ↑Развернуть ↓

Ну тогда обязательно надо будет поговорить

Свернуть ↑Развернуть ↓

[pchayka]

Были у нас некоторые вещи сделаны на hibernate и были планы по переводу работы с базой на процедуры. Но по факту это имело смысл только к высокоиспользуемым механизмом вроде сосок. В остальных случаях банальный mysql запрос справляется, хоть и не так красиво.

[Gattsu]

Представьте, что Вы каждый раз, чтобы что-то сделать говорите контролеру и ждете ответа "хорошо".
Все это Вы ему говорите через посыльного, который ожидай маршрутку, доезжает до места контролера, ждет от него ответа, потом опять садится на маршрутку, едет к Вам и говорит "хорошо". Допустим Вы решили сделать шаг, Вы его не сделаете пока контроллер не скажет "хорошо". Вот теперь, если посчитать временные затраты, то у Вас образовывается дыра пространственно-временном континууме.
КЭШ убирает посыльного и ожидание ответа. Про процедуры отдельный разговор.


Потом на ПТС распределенные приложение и КЭШ - общая оперативная память.

Есть разные модели кэша

1 КЭШ <сеть> приложение (приложения на разных компьютерах)
* сеть может быть на оптово волокне, а там одновременная двух сторонняя передача
2 КЭШ <шина/память> приложение (приложение на одном компьютере)
3 КЭШ <память> приложение (отдельная подпрограмма)

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

Так, что в пользу кэш можно поставить большой +.

[ANZO]

Один большой и толстый минус: валится кешед - валится все без возможности восстановления. С какой периодичностью будет в этом "сферическом кешеде" происходить сохранение в базу, чтобы оправдать свое существование и не стать причиной возможной потери данных? 5-10 минут? Стоит заморачиваться? Я думаю нет.

Возьмем к примеру тот же л2 сервер: ну сколько там тех запросов выполняться-то будет, пускай с 5-ю тысячами игроков, в единицу времени? Мизер, на который даже современное железо ухом не поведет. О таких мероприятиях стоит беспокоится, когда вы будете иметь дело с Highload-проектами от 100 тысяч одновременных активных пользователей, где каждая наносекунда важна как воздух - и то всегда есть шанс, что даже "охренеть-какой-энтерпрайзный бекэнд" на@#$тся из-за мелкой невзрачной ошибки, потянув за собой все.