|
Cashed true system
|
11-26-2012, 04:23 AM
linliss Написал:потому что в птсе оно по сети гоняется, сеть на блокирующих сокетах дает 60к+ пакетов/сек(нио я не тестил, хотя нафиг оно там надо, если приложение одно), проблем быть не должно...Просто не думаю, что кто-то кроме крупных проектов будет еще 1 машину под кешед делать. В итоге все будет стоять на 1 машине. 
11-26-2012, 07:39 AM
ASevenfold Написал:Тем что мы тратим кучу процессорного времени на работу с БД напрямую. Кешед очень даже нужная вещь, т.к. он позволяет убрать все это дело нахрен и лишь время от времени заливать данные в БД (эдакий автосейв), при том, что сама вся база кешируется и мы работаем с ней в ОЗУ без лишних обращений, так же и модифицируем, в ОЗУ. На это есть отложенные запросы и bulk-операции, и не понадобится никакой дополнительный кэш, оперативная память ГСа - это и есть кэш, к тому же, наиболее быстрый. Если бы в опен-сорс проектах L2J делали базу изначально по уму, то не было бы огромных проблем с работой БД. Когда только начинал ковырять сборки, находил уйму performance miss'ов по типу кучи отдельных запросов вместо одного, или отсутствия нужных ключей и индексов на таблицах. Ну а о структуре и 3 НФ лучше вообще не упоминать. Чем чаще обновляются данные, тем меньше плюсов становится у кэширующего механизма. Кэшировать тоже нужно уметь, иначе получите ту же кучу говнокода и "лагающий" кэш-двиг.
// aka Deft
11-28-2012, 04:33 PM
rage Написал:А что мешает реализовать работу с БД в отельном потоке? К тому же, не замечал нехватки проца на ява сборках, даже при очень больших нагрузках. Кешед удобен тем, что него намного выше отказоустойчивость, чем с базой напрямую, т.к. ему должно быть пофигу на всякие недоступности подключения к бд.
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче. 
11-28-2012, 04:40 PM
Цитата:Кешед удобен тем, что него намного выше отказоустойчивость, чем с базой напрямую, т.к. ему должно быть пофигу на всякие недоступности подключения к бд.и тем не менее на птс-ах кешед валится как березка едва коннект к БД задержится. И тащит за собой гейм.
11-28-2012, 04:45 PM
pchayka Написал:и тем не менее на птс-ах кешед валится как березка едва коннект к БД задержится. И тащит за собой гейм. Это уже недостаток разработчиков птса, хотя им точно на это наплевать, да и не нужно это им  Во всяком случае, я думал, что мы ведем речь про некий сферический кешед в вакууме, который по функционально схож с птсным.
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче.
11-28-2012, 05:00 PM
Были у нас некоторые вещи сделаны на hibernate и были планы по переводу работы с базой на процедуры. Но по факту это имело смысл только к высокоиспользуемым механизмом вроде сосок. В остальных случаях банальный mysql запрос справляется, хоть и не так красиво.
11-28-2012, 05:30 PM
Представьте, что Вы каждый раз, чтобы что-то сделать говорите контролеру и ждете ответа "хорошо".
Все это Вы ему говорите через посыльного, который ожидай маршрутку, доезжает до места контролера, ждет от него ответа, потом опять садится на маршрутку, едет к Вам и говорит "хорошо". Допустим Вы решили сделать шаг, Вы его не сделаете пока контроллер не скажет "хорошо". Вот теперь, если посчитать временные затраты, то у Вас образовывается дыра пространственно-временном континууме. КЭШ убирает посыльного и ожидание ответа. Про процедуры отдельный разговор. Потом на ПТС распределенные приложение и КЭШ - общая оперативная память. Есть разные модели кэша 1 КЭШ <сеть> приложение (приложения на разных компьютерах) * сеть может быть на оптово волокне, а там одновременная двух сторонняя передача 2 КЭШ <шина/память> приложение (приложение на одном компьютере) 3 КЭШ <память> приложение (отдельная подпрограмма) Много из этого изыски, но это себя оправдывает с появления кэш памяти на процессоре. Так, что в пользу кэш можно поставить большой +. 
11-28-2012, 06:40 PM
Один большой и толстый минус: валится кешед - валится все без возможности восстановления. С какой периодичностью будет в этом "сферическом кешеде" происходить сохранение в базу, чтобы оправдать свое существование и не стать причиной возможной потери данных? 5-10 минут? Стоит заморачиваться? Я думаю нет.
Возьмем к примеру тот же л2 сервер: ну сколько там тех запросов выполняться-то будет, пускай с 5-ю тысячами игроков, в единицу времени? Мизер, на который даже современное железо ухом не поведет. О таких мероприятиях стоит беспокоится, когда вы будете иметь дело с Highload-проектами от 100 тысяч одновременных активных пользователей, где каждая наносекунда важна как воздух - и то всегда есть шанс, что даже "охренеть-какой-энтерпрайзный бекэнд" на@#$тся из-за мелкой невзрачной ошибки, потянув за собой все. |
|
« Предыдущая | Следующая »
|
| Возможно похожие темы ... | |||||
| Тема | Автор | Ответы | Просмотры | Последний пост | |
| System GD kor 480-481 | 3 | 2,141 |
02-15-2021, 10:14 PM Последний пост: Phantom-Dev |
||
| System GF RuOff | 9 | 2,349 |
10-12-2012, 01:08 AM Последний пост: MrShyr |
||
