Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 Выбор технологии кеширования  [new]
rabiter
Member

Откуда: SPb
Сообщений: 594
Ребята, доброго времени дня/ночи суток!

Посоветуйте, что взять бы такое для реализации следующей задачки.

Есть проект "Система хранения документов" (ECM) - довольно большая и монструозная. Появилась такая задача:
пользователь открывает документ, в документе может быть несколько аттачей (png, doc, jpeg, что угодно). И пользователь может навигировать по этим аттачам в веб интерфейсе: выбирает аттач, мы его конвертируем в pdf (используем aspose) и показываем в pdf.js viewer. Все шикарно работает. Пользователь выбирает следующий аттач - мы конвертируем - показываем.
Так вот нужно улучшить. Когда пользователь открывает очередной документ, мы хотим заранее конвертнуть и закешировать все аттачи этого документа (такой precache получается). Так вот для конвертации всех аттачей надо запустить несколько потоков параллельно, по потоку на аттач, и результат конвертации сохранить где-то в кеше.
В принципе, проблемы никакой нет в реализации. Но хочется ведь взять что-нибудь готовое уже.
Для кеширования в приложении я давно хочу взять ehcache. Думаю тут самое время (сейчас используем свои механизмы кеширования всего что есть, кешируем в памяти). Собственно вопрос: может кто что посоветует для решения такой задачи? Чтобы можно было запускать сбор данных в несколько потоков и кешировать результат, и при этом не выходить из рамок ресурсов (ограничить число потоков и памяти для кеша). Я имею ввиду что-нибудь готовое, чтобы не городить огород.
14 мар 19, 02:47    [21831975]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 6858
rabiter,

А как можно конвертировать "png, doc, jpeg, что угодно" в pdf.js? Этоже пдф-ная технология.
14 мар 19, 02:55    [21831976]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
rabiter
Member

Откуда: SPb
Сообщений: 594
Relic Hunter,

Ну смотрите, мы с помощью aspose конвертируем то, что можно, в pdf сперва (png -> pdf, doc -> pdf и т.д.), а потом, уже имея pdf, показываем его в pdf.js
14 мар 19, 02:57    [21831977]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
rabiter
Member

Откуда: SPb
Сообщений: 594
Собственно конвертация может занять какое-то время, поэтому и хочется конвертнуть заранее в pdf и закешировать этот pdf. Чтобы когда ползователь нажмет на этот аттач, ему меньше ждать.
14 мар 19, 02:59    [21831978]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 6858
rabiter,

pdf.js это клиентская технология, а не серверная. Сохраняйте сразу в pdf и пусть "клеент" конвертирует.
14 мар 19, 04:37    [21831985]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 37071
rabiter,
Палка о двух концах.
Есть такое в эксплорере - загружать заранее все ссылки что есть на странице.
Я это всегда выключаю. Нафига загружать всё подряд?
14 мар 19, 07:15    [21831996]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 37071
Делайте для всех доков превью в jpeg 60 DPI.
Это статика, и загрузится сразу и мгновенно.
14 мар 19, 07:17    [21831997]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3052
rabiter
Есть проект "Система хранения документов" (ECM) - довольно большая и монструозная.
...
В принципе, проблемы никакой нет в реализации. Но хочется ведь взять что-нибудь готовое уже.
Для кеширования в приложении я давно хочу взять ehcache. Думаю тут самое время
Мде, ECM у вас, скажем прямо, так себе. То что вы хотите в ECM называется rendition и имеет тенденцию храниться не в каком-то кеше, а в вместе с остальными файлами/метаданными, и генерироваться (и сохраняться) либо по запросу, либо после сохранения основного документа.

rabiter
png, doc, jpeg, что угодно ... и при этом не выходить из рамок ресурсов
Удачи, у aspose генерация "толстых" документов тупит так, что какой-нить ворд на 600 страниц конвертируется по 10 минут и выжирает весь процессор, так что вы описываете - это потенциальный DoS.
14 мар 19, 07:22    [21831998]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Lyaka
Member

Откуда:
Сообщений: 1
спасибо!
14 мар 19, 07:24    [21831999]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
mayton
Member

Откуда: loopback
Сообщений: 39264
Не совсем понятен юзкейс. Будет ли пользователь редактировать документы.
А так - можно плюсануть к кешированию картинок.
14 мар 19, 08:24    [21832023]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3052
mayton
Не совсем понятен юзкейс. Будет ли пользователь редактировать документы.
ТС хочет все документы которые есть в системе отображать в режиме просмотра через iframe с pdf.js - типа так универсально получается (в целом можно все в pdf не конвертировать, а к примеру pdf крутить через pdf.js, картинки как есть, офис через onlyoffice какой-нить, но мороки какбы больше)
14 мар 19, 08:33    [21832024]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
qasta
Member

Откуда:
Сообщений: 54
rabiter
Ребята, доброго времени дня/ночи суток!

Посоветуйте, что взять бы такое для реализации следующей задачки.

Так вот для конвертации всех аттачей надо запустить несколько потоков параллельно, по потоку на аттач, и результат конвертации сохранить где-то в кеше.

Лучше запустить один поток на пользователя (а не на аттач), который последовательно подготовит все аттачи
rabiter
В принципе, проблемы никакой нет в реализации. Но хочется ведь взять что-нибудь готовое уже.
Для кеширования в приложении я давно хочу взять ehcache.


С точки зрения "прямващевсёужереализованоиготово" думаю, что нет смысла искать, т.к. черновой вариант напишется максимум за день (с перекурами и перерывами на кофе/сон) :)

Берите ehcache - штука очень гибкая и мощная: в том числе и на диск из памяти сможет сбрасывать при определенных условиях, различные варианты "устаревания" кеша, работает уже давно в промышленных средах. Интегрируется в проекты ну очень легко.
14 мар 19, 09:21    [21832042]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 4849
Petro123
Делайте для всех доков превью в jpeg 60 DPI.
Это статика, и загрузится сразу и мгновенно.


Андрей Панфилов
храниться не в каком-то кеше, а в вместе с остальными файлами/метаданными, и генерироваться (и сохраняться) либо по запросу, либо после сохранения основного документа.


если нагрузка вас уже беспокоить, то вам следует прислушаться к господам.
14 мар 19, 09:38    [21832063]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 37071
Я не пойму вообще смысла тут кеша.
Если не преобразовывать все в pdf, то и кеш не нужен.
14 мар 19, 09:43    [21832069]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 37071
Андрей Панфилов
типа так универсально получается (
зато понадобился кеш. Обратная сторона.
14 мар 19, 09:45    [21832072]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3052
Petro123
зато понадобился кеш. Обратная сторона.
там кейсов довольно много можно накидать, к примеру у документа гриф ДСП стоит и пользаку нужно его отдавать модифицированным (от банальных водяных знаков, до игры со шрифтами, кириллицой/латинцией и пр.) чтобы понять кто документ слил.
14 мар 19, 09:59    [21832081]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
mayton
Member

Откуда: loopback
Сообщений: 39264
Автор что-то over-проектировал. Тут определённо нужно обсуждать саму задачу.
Причем не на уровне "я хочу" а на уровне чего на самом деле нужно бизнес-пользователю.

Преобразование картинок в pdf выглядит уж-точно какой-то гипертрофированной задачей.
14 мар 19, 10:00    [21832082]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 37071
Андрей Панфилов
чтобы понять кто документ слил.
прикольно))
14 мар 19, 10:04    [21832089]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
alex55555
Member

Откуда:
Сообщений: 1727
mayton
Автор что-то over-проектировал.

И теперь хочет по быстрому всё наладить. Прикрутит кэш, какое-то время даже наверно работать будет, а потом ему опять по быстрому захочется. В общем здесь всё безнадёжно.
14 мар 19, 11:51    [21832276]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
mayton
Member

Откуда: loopback
Сообщений: 39264
Да. А если цель стоит - ставить watermark на все документы - тогда кеш будет поделен
по горизонтали на количество пользователей. Вобщем как всегда или скорость или секюрность.
Надо выбирать. Мдя.
14 мар 19, 11:57    [21832290]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
rabiter
Member

Откуда: SPb
Сообщений: 594
Relic Hunter
rabiter,

pdf.js это клиентская технология, а не серверная. Сохраняйте сразу в pdf и пусть "клеент" конвертирует.


Конвертация происходит на сервере, браузеру отдаем уже сконвертированный pdf
14 мар 19, 13:10    [21832430]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
rabiter
Member

Откуда: SPb
Сообщений: 594
Petro123
Палка о двух концах.
Есть такое в эксплорере - загружать заранее все ссылки что есть на странице.
Я это всегда выключаю. Нафига загружать всё подряд?


У нас есть ТЗ от одного из кастомеров на precache. Надо делать)

Petro123
Делайте для всех доков превью в jpeg 60 DPI.
Это статика, и загрузится сразу и мгновенно.


Удобнее работать через pdf.js - можно листать страницы мышкой, зумить, копировать текст и т.д.
Мы от картинок ушли из-за этого.
14 мар 19, 13:15    [21832440]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
rabiter
Member

Откуда: SPb
Сообщений: 594
Андрей Панфилов
rabiter
Есть проект "Система хранения документов" (ECM) - довольно большая и монструозная.
...
В принципе, проблемы никакой нет в реализации. Но хочется ведь взять что-нибудь готовое уже.
Для кеширования в приложении я давно хочу взять ehcache. Думаю тут самое время
Мде, ECM у вас, скажем прямо, так себе. То что вы хотите в ECM называется rendition и имеет тенденцию храниться не в каком-то кеше, а в вместе с остальными файлами/метаданными, и генерироваться (и сохраняться) либо по запросу, либо после сохранения основного документа.

Есть у нас rendition, есть кастомеры, у которых мы все аттачи конвертируем в pdf и храним эти pdf вместе с оригинальными аттачами в хранилище. Но кастомеров много, не все могут позволить себе большие хранилища, чтобы в них хранить экстра данные, вот для них нужен небольшой прекеш в памяти, о котором я написал.
И опять же, действительно, у некоторых кастомеров бывают user specific watermarks, так что получается user specific кеш должен быть.

Андрей Панфилов
rabiter
png, doc, jpeg, что угодно ... и при этом не выходить из рамок ресурсов
Удачи, у aspose генерация "толстых" документов тупит так, что какой-нить ворд на 600 страниц конвертируется по 10 минут и выжирает весь процессор, так что вы описываете - это потенциальный DoS.

Ну в реальности редко бывают аттачи картинки, это я для примера скинул. Вообще aspose не я выбирал, и корвертацию всего и вся в pdf, Я когда узнал об этом, удивился немного, ну да ладно. Но, кстати, doc Война и Мир (4 мегабайта на 1700 страниц) конвертируется в PDF на моем ноуте за 7 секунд. Но у нас для каждого документного типа можно выставить трешхолд на превью. Часто бывают аттачи маленькие совсем.

Андрей Панфилов
mayton
Не совсем понятен юзкейс. Будет ли пользователь редактировать документы.
ТС хочет все документы которые есть в системе отображать в режиме просмотра через iframe с pdf.js - типа так универсально получается (в целом можно все в pdf не конвертировать, а к примеру pdf крутить через pdf.js, картинки как есть, офис через onlyoffice какой-нить, но мороки какбы больше)

верно, универсальность. Кастомеров много, у всех свои use cases, у кого много маленьких аттачей, у кого-то мало, но большие. Все у нас настраивается, какие типы файлов конвертировать в pdf, какие нет, у какиз будет preview, у каких нет, по типам, по размерам.
pdf.js у нас как плагин вообще дефолтный, отдельные кастомеры используют свой вьювер.
Главное, в будущем если будет необходимость мы можем для разных типов аттачей использовать разные вьюверы. Но пока вот pdf.js

Андрей Панфилов
Petro123
зато понадобился кеш. Обратная сторона.
там кейсов довольно много можно накидать, к примеру у документа гриф ДСП стоит и пользаку нужно его отдавать модифицированным (от банальных водяных знаков, до игры со шрифтами, кириллицой/латинцией и пр.) чтобы понять кто документ слил.

Да, так и есть, каждому пользователю может отдаваться аттач со специфичным watermark.
14 мар 19, 13:29    [21832463]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
rabiter
Member

Откуда: SPb
Сообщений: 594
mayton
Не совсем понятен юзкейс. Будет ли пользователь редактировать документы.
А так - можно плюсануть к кешированию картинок.


Редактировать нет, но вот листать колесиком мышки страницы, зумить, копировать текст - look and feel намного приятнее чем если тебе дают картинку понюхать.

mayton
Автор что-то over-проектировал. Тут определённо нужно обсуждать саму задачу.
Причем не на уровне "я хочу" а на уровне чего на самом деле нужно бизнес-пользователю.

Преобразование картинок в pdf выглядит уж-точно какой-то гипертрофированной задачей.


Да, преобразование картинок в pdf это огонь, согласен :D

mayton
Да. А если цель стоит - ставить watermark на все документы - тогда кеш будет поделен
по горизонтали на количество пользователей. Вобщем как всегда или скорость или секюрность.
Надо выбирать. Мдя.


Вооот, все верно подметили, получается кеш user specific. Ну тут нужна золотая середина. Я хочу как можно более safe решение, такой маленький кеш, для кеширования маленьких аттачей и не больше N штук на пользователя (на большие аттачи сделаем настраиваемый threshold). Кастомеров много, у всех своя специфика данных.
14 мар 19, 13:36    [21832479]     Ответить | Цитировать Сообщить модератору
 Re: Выбор технологии кеширования  [new]
rabiter
Member

Откуда: SPb
Сообщений: 594
qasta
rabiter
Ребята, доброго времени дня/ночи суток!

Посоветуйте, что взять бы такое для реализации следующей задачки.

Так вот для конвертации всех аттачей надо запустить несколько потоков параллельно, по потоку на аттач, и результат конвертации сохранить где-то в кеше.

Лучше запустить один поток на пользователя (а не на аттач), который последовательно подготовит все аттачи


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


qasta
rabiter
В принципе, проблемы никакой нет в реализации. Но хочется ведь взять что-нибудь готовое уже.
Для кеширования в приложении я давно хочу взять ehcache.


С точки зрения "прямващевсёужереализованоиготово" думаю, что нет смысла искать, т.к. черновой вариант напишется максимум за день (с перекурами и перерывами на кофе/сон) :)

Берите ehcache - штука очень гибкая и мощная: в том числе и на диск из памяти сможет сбрасывать при определенных условиях, различные варианты "устаревания" кеша, работает уже давно в промышленных средах. Интегрируется в проекты ну очень легко.


Да, я ehcache уже оценил!
14 мар 19, 13:39    [21832489]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / Java Ответить