Max
проблема, что знают не все. и узнают в тот, момент, когда всё упало. и потом не все знаю, почему
Snusmumriken
А, ну да, я-то про себя говорю. Так-то я расписывал проблемы luajit. Знаешь какая у него ещё есть проблема? Причём похуже.
Max
примерно представляю парочку)
Snusmumriken
Слишком много логики в одной вм приводят к снижению скорости в ~1000 раз в сравнении с puc lua, потому что генерится слишком много трасс и они там чот не шибко хорошо чистятся и не очень хорошо свитчатся, или что-то подобное. Я не знаю точной причины, тебе объяснят те кто делают свои jit-компиляторы, но общая суть такая. На это дело, кстати, тоже есть патчи.
Snusmumriken
Но есть и решение попроще: не запихивать в одну вм целую самотрансформирующуюся вселенную, потому что все мы теперь знаем об этой проблеме.
Max
проблема со строками не требует много логики. у тебя может быть просто много данных
Snusmumriken
Ну вот все мы теперь об этом знаем, и будем выдирать из огромного xml-чанка только нужное нам, и вызывать collectgarbage время от времени, на всякий случай : )
Snusmumriken
Max
Snusmumriken
Чаво? Xml настолько большой что живёт всё время программы? Я парсю xml на 3-5тб, они вообще никуда не влезут и ничем не распарсятся, там только гусеничкой пробегать: считать пять мегабайт, найти в конце завершающий тег, обрезать по него, считать ещё пять мегабайт и приклеить к хвосту от предыдущего. А остальное разбирать регулярками.
Snusmumriken
Вот так обычно обрабатывают "настолько большие xml"
Snusmumriken
А остальное обычно заливается в базу и хранится на диске, время от времени прогоняя запросами по необходимости выдрать данные. Не?
Max
представь, что тебе надо обрабатывать тысячи запросов в секунду, используя инфу, которая весит несколько гигабайт
Max
диск и база это очень медленно
Snusmumriken
Ну тады распарсить, сжать и запихнуть в бд типа редиски.
Max
обычная lua табличка быстрее
Snusmumriken
Извращения, эх.
Elias
> xml на 3-5тб
u fukken wot m8
Snusmumriken
Привет Элиас! Хоть кто-то в ком я уверен что он не бот.
Max
извращения — это вызывать collectgarbage вручную
Snusmumriken
Кстати нет ))
Snusmumriken
А ещё нормально делать мусорщик более агрессивным.
Max
если экономишь на памяти
Snusmumriken
Разумеется, особенно на микрухах но не только.
Max
но кажется сейчас гораздо чаще экономят на процессинг тайме
Snusmumriken
Elias
Тут уже триллионы :trollface:
Max
Кстати нет ))
после редактирования моё уточнение выглядит не оч ((
Snusmumriken
обычная lua табличка быстрее
Кстати да, луа-табличка быстрее. Но она при этом жрёт куда меньше памяти, если там хранить только необходимые данные:
local cache = {
["guid1"] = "qwe:rty",
["guid2"] = "asd:fgh",
}
local url = mysite.com/blabla?foo=%s&bar=%s
function get(guid)
local s = cache[guid]
local a, b = s:match("(.-):(.*)")
return url:format(a, b)
end
Вместо хранения тупо всех одинаковых урлов. Если урлов несколько — соответственно, держим пару кешей. Ну ты понел.
Max
Snusmumriken
быстрее и жрёт меньше памяти, а какие недостатки подхода?
На одну маленькую пупку медленнее (мы тут ещё чутка строку парсим, жуть какая), и снижается универсальность, приходится или писать больше приложений, или учитывать ещё и это.
>после редактирования моё уточнение выглядит не оч ((
Пофиксил, теперь всё красиво
Max
урлы не тупо одинаковые. или ты предлагаешь пользователю формочки тоже думать о том, что в luajit плохая функция кэширования?
Snusmumriken
> Если урлов несколько — соответственно, держим несколько кешей.
Snusmumriken
Зато не 1000000тб оперативной памяти жрётся, а всего лишь 100тб. Я примерно, но порядков много.
Max
кэши — это что в данном случае (не успеваю за ходом мысли)? таблица или какой-то редис?
Snusmumriken
Таблица же, я код привёл. Табличка быстрее? Ну так будет табличка, просто хранить будем уникальные данные, уменьшая кол-во дубликатов.
Serezha
Max
Snusmumriken
Это чисто для комфорта пользования.
Snusmumriken
Энивей, храня (почти)уникальные данные мы убиваем двух зайцев.
Max
то, что для тебя не дубликат, может легко оказаться дубликатом для luajit. вот в чём проблема
Max
и ты никогда не знаешь заранее
Snusmumriken
Может, но вероятность становится с "довольно вероятной" до "крайне малой". Полностью себя обезопасить не получится никогда, но снизить вероятность с 0.5 до 0.00(куча нулей)005 можно.
Max
или просто взять норм хэш-функцию и жить спокойно 🤔
Snusmumriken
Да : )
Snusmumriken
И жрать больше памяти в миллард раз, потому что "это железная проблема, дайте ещё $1000000 на оперативку" ))
Max
с памятью ортогональная проблема
Snusmumriken
Карочи, с одной стороны это действительно нифига не хорошо, но с другой стороны заставляет шевелить башкой и економно распоряжаться ресурсами. Никто не любит второе, но енто довольно полезно. Особенно если довести до автоматизма.
Max
ммм, подбирать строки, котрые не коллидируются хэш-функцией луаджита. соооу юзфул мач полезно
Snusmumriken
Snusmumriken
Обычно достаточно не "подбирать" а "хранить уникальное" вместо того чтобы грести "всё подряд".
Max
не понимаю про 1000 тб
Max
btw проблема хранения нужных данных в том докладе тоже упоминается
Max
например эта табличка, если она рид-онли, может шэриться на все lua машины в сервере
Snusmumriken
не понимаю про 1000 тб
Кадр из видоса. Сколько полезной информации вот в таком вот списке на 1000 строк, и сколько байт он занимает?
Max
это пользовательский ввод
Max
на каждый чих пользователя придумывать сжимающий алгоритм?
Max
или только после того, как упали тачки, которые этого пользователя обслуживают?
fgntfg
Egor
Скажите, а что такое PID controller?
Egor
В вики прочел..и чет не очень понял...зачем она в луа в игре?
Snusmumriken
это пользовательский ввод
Мммм. Не совсем. Но мы же видим что "пользователь ввёл", вот тут вот, например, это урлы. Следовательно:
Рассекаем строку http://myadsite.org/myhandler/creative_id=15365532&bidder_id=1 по последний слеш /, получаем примерно следующее:
http://myadsite.org/myhandler/ и creative_id=15365532&bidder_id=1. Смотрим, есть ли первая часть в нашем кеше уникальных "первых половин" урлов. Если нет - добавляем, а к второй половине цепляем его идентификатор, например $u1. Вот мы уже получили кеш "уникальных первых половин урлов". Теперь смотрим на вторые. Можем начать их хранить как есть, а можем снова распилить. Закодировать их в выходной строке каким-нибудь. Потом так же пилим параметры.
Это просто, универсально (для урлов, ибо мы знаем их структуру) и безумно жмёт данные.
Egor
fgntfg
Max
Мммм. Не совсем. Но мы же видим что "пользователь ввёл", вот тут вот, например, это урлы. Следовательно:
Рассекаем строку http://myadsite.org/myhandler/creative_id=15365532&bidder_id=1 по последний слеш /, получаем примерно следующее:
http://myadsite.org/myhandler/ и creative_id=15365532&bidder_id=1. Смотрим, есть ли первая часть в нашем кеше уникальных "первых половин" урлов. Если нет - добавляем, а к второй половине цепляем его идентификатор, например $u1. Вот мы уже получили кеш "уникальных первых половин урлов". Теперь смотрим на вторые. Можем начать их хранить как есть, а можем снова распилить. Закодировать их в выходной строке каким-нибудь. Потом так же пилим параметры.
Это просто, универсально (для урлов, ибо мы знаем их структуру) и безумно жмёт данные.
просто, но дороже и всё ещё ничего не гарантирует.
Snusmumriken
Это Совершенно Точно Гарантирует тот факт, что памяти будет жраться в миллиард раз меньше, и уменьшает вероятность коллизий во много раз.
Max
ммм не в миллиард
Egor
Та.
все равно не понял, вот нашел файлик pid.lua там всего 37 строк..и зачем оно?
Snusmumriken
Гарантий в мире НЕ СУЩЕСТВУЕТ. Ты можешь умереть в любой момент выходя из дома, у тебя нет гарантий. Тебя могут уволить, твоя компания может распасться. Это "достаточно" вероятно. Но этого не происходит каждый день. Когда произойдёт — тогда произойдёт. Тут — то же самое, хе. Снижаем вероятность и живём с этим.
fgntfg
fgntfg
А, например, process id
Max
Max
но память не проблема!
Snusmumriken
А ещё, все твои скрипты могут внезапно упасть потому что отрубилось электричество (и внезапно генератор не завёлся) или таракан зажал две дорожки в микросхеме. Гарантий нет, все абстракции текут. Бизнес всегда будет содержать риски, а если ты можешь уменьшить их — это отлично.
Egor