Ребята, доброго времени дня/ночи суток!

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

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

Relic Hunter,

Ну смотрите, мы с помощью aspose конвертируем то, что можно, в pdf сперва (png -> pdf, doc -> pdf и т.д.), а потом, уже имея pdf, показываем его в pdf.js

Собственно конвертация может занять какое-то время, поэтому и хочется конвертнуть заранее в pdf и закешировать этот pdf. Чтобы когда ползователь нажмет на этот аттач, ему меньше ждать.

Relic Hunterrabiter,

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

Конвертация происходит на сервере, браузеру отдаем уже сконвертированный pdf

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

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

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

Удобнее работать через pdf.js - можно листать страницы мышкой, зумить, копировать текст и т.д.
Мы от картинок ушли из-за этого.

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

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

Андрей Панфиловrabiterpng, 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.

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

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

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

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

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

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

Вооот, все верно подметили, получается кеш user specific. Ну тут нужна золотая середина. Я хочу как можно более safe решение, такой маленький кеш, для кеширования маленьких аттачей и не больше N штук на пользователя (на большие аттачи сделаем настраиваемый threshold). Кастомеров много, у всех своя специфика данных.

qastarabiterРебята, доброго времени дня/ночи суток!

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

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

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


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


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

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

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

Да, я ehcache уже оценил!

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

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

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

Нагрузка не то, чтобы беспокоит сейчас уже, я просто предвижу эту проблему. Хранить pdf в основном хранилище рядом с оригинальными аттачами - да, мы так делаем для некоторых кастомеров. Но не для всех подходит, потому что либо из-за user specific watermarks (каждому пользователю отдается модифицированный аттач), либо кастомеры не хотят платить за место в storage за прекеш данные. Вообщем идея в таком light weight кеше в памяти "здесь и сейчас" для маленьких аттачей (настраивается размер).

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

Да зависит от кастомера... Ну вообще вот перед тобой табличка, в табличке документы, у каждого документа несколько аттачей. Пользователь кликает на документ, появляется окошко с метаданными документа и список его аттачей, первый аттач выбирается автоматически и показывается его превью. Пользователь выбирает второй аттач - опять конвертация, опять превью. Это как работает пока. Надо чтобы определенное число аттачей (настраиваемая велечина), конвертировалось сразу при открытии документа. Так что пока пользователь работает с первым аттачем, остальные уже на подходе. Это реальзый use case от одного из кастомеров. Причем если осталось место для прикеша, то начинаем автоматом конвертировать и кешировать уже аттачи из следующего документа в списке.
Вообще я думаю тут должна быть настраиваемся предсказательная стратегия того, какой аттач пользователь откроет следующим, но это все пока не приоритет.

Вообщем я в принципе определился. Для кеша - ehcache (только heap tier). С offheap и disk я думаю потом можем проблемы огрести, потому что там уже надо будет более индивидуально подходить к каждому кастомеру в плане настроек offheap и disk tiers.
Ну и будет один поток на пользователя, который будет последовательно аттачи конвертировать и добавлять в кеш. И да, пока для каждого пользователя будет свой экземпляр кеша. Пусть пока так, дальше посмотрим.

maytonrabiter, nginx используете?

Не уверен, может быть на каких-нибудь инсталляциях и используем... Я, если честно, не в курсе. Вы намекаете на то, что можно кешировать nginx-ом?

Petro123rabiter,
И эта вся бодяга т.к. кастомер не имеет памяти в хранилище для превью?

Petro123rabiterПользователь выбирает второй аттач - опять конвертация, опять превью.то есть либо купить терабайт для превью, либо писать код.
Так?

Вообще я согласен с Вами. Первое о чем я подумал, какого черта, какой-то непонятный кеш на уровне приложения, мелко мыслим! Предложил начальству хранить сконвертированный pdf рядом в том же архиве с оригинальным аттачем. Выяснилось, что для некоторых кастомеров это уже реализовано на уровне rendition. Ну, короче, не буду вдаваться в детали, все же нужен такой легковесный настраиваемый кеш / прикеш. Относимся к нему как к этакому light подспорью.

Petro123rabiterпропущено...


Не уверен, может быть на каких-нибудь инсталляциях и используем... Я, если честно, не в курсе. Вы намекаете на то, что можно кешировать nginx-ом?кешировать можно готовое.
А у вас нет готовых превью.

Вот, в том-то и дело

Petro123rabiter,
Размер обычных аттачей и время что ждет юзверь?

Нет у меня данных, слава богу, я далеко от суппорта и кастомеров.

Petro123rabiterлибо кастомеры не хотят платить за место в storageпусть ждут раз не платят. Нефиг)))
Ну, или сделайте отдельный rest http сервис с превью.
Как платная опция.
Заплатил, будет летать. Нет - терпи генерацию превью.

это тема, кстати. Я возьму это на заметку, спасибо! Я имею ввиду вообще выделить эту опцию прикеша в отдельный модуль. Хочешь - на, не хочешь - убираем модуль из сборки, отключается прикеш.

mayton,

Все, я сделяль, осталось причесать. А цифр не будет. Я вообще-то в целом с вами согласен, нелепая таска. Я бы кешировал так кешировал по взрослому, в архиве, отдельной джобой. Но я не могу драйвить такие решения.
Кстати, ehcache клевый, особенно его read through пригодилась.

maytonПокажи свою конфигурацию ehcache. Без бизнес-названий разумеется... Только цифры.

кеш только в хипе, по количеству entries - настраивается индивидуально через админку для каждого документного типа - админ кастомера может вообще поставить 0 и отключить, если надо. Вообще ходовое значения, я думаю, будет что-то в районе 5 сущностей на пользователя. Кеш не глобальный, SessionScoped, т.е. для каждого пользователя. Пользователей много одновременных не бывает (до 1000 одновременных). Размер аттачей, для которых превью отключается, тоже настраивается через админку индивидуально для каждого документного типа.

KachalovmaytonПокажи свою конфигурацию ehcache. Без бизнес-названий разумеется... Только цифры.
- наверняка там еще показывать нечего, прикинули хрен к носу и решили что надо в память файлы кэшировать, а когда память кончится тогда начнут считать

Да, именно так как вы сказали, и даже хуже

На мой взгляд проблема еще вот какая, так как это pdf.js, ему нужно загрузить всю pdf с сервера, прежде чем он сможет ее отобразить.
Толку, что у нас на сервевере лежит готовая pdf в кеше. В смысле это, конечно, хорошо, но эту pdf надо еще до браузера донести всю целиком. Вообще помимо pdf.js есть другие решения, которые парсят pdf на сервере, а клиенту отдают части pdf по мере необходимости (например, при пролистывании документа), но эти решения платные, да и сложнее их было интегрировать. Но так как это плагин у нас, всегда можно pdf.js заменить вообще на что угодно.

А вообще логика у руководства такая по этому кешированию - кешируем в памяти, кастомер про это знает, если хочет - включает и настраивает для документных типов необходимые ему значения кеша, соотносит с размером оперативной памяти, колличеству пользователей. Т.е. мы как бы не занимаемся настройками кеша, все вынесено в конфигурацию.