1. Клиент хочет выгружать для своих клиентов гибко настраиваемый список объектов и полей этих объектов. Это работает. Поля и отборы задаются на СКДшке, все норм. Выгрузка идет через FTP, причем FTPшников может быть указано несколько.
2. При этом у клиента есть PDFки, которые он хочет отправлять клиенту, конвертируя в PNG/JPG с разными ширинами и высотами картинок. Здесь как бы тоже все работает. Через imagemagick все конвертируется. 1 картинка примерно 5 сек.
3. А потом он хочет в выгружаемых объектах из п.1 указывать ссылки на выгруженные картинки, соответствующие этим объектам. И чтобы все работало прям быстро-быстро.

И вот тут у меня наступает когнитивный диссонанс.
Нужно понимать, что выгрузилась картинка или нет. Это опрашивать все FTP на наличие картинки в таком-то разрешении с таким-то форматом.
Нужно максимально уменьшить время выгрузки, поскольку клиентов может быть куча.
И понимать, выгружать картинки с указанными параметрами из 2. для данного клиента на указанный FTP, или нет. Но по времени это пипец как долго будет.
1 клиент * 200 объектов * 3 картинки на объект * 5 секунд на картинку. И это только на выгрузку. Т.е. на одного клиента примерно 1 час на выгрузку.
Можно процессы выгрузки картинок и объектов разделить. Но тогда надо понимать, что мы выгрузили, что нет.

Думал, про веб-сервисы. Чтобы клиент сам указывал, что он хочет по какой настройке в каких форматах, получить. Но тогда конвертация картинок при выгрузке также будет происходить долгое время.
Может, у кого-нибудь будут еще взгляды, как можно сделать выгрузку быстрой, но при этом гибко настраиваемой?

Вроде как, пока файл не записался полностью, имеет размер 0 байт. Можно на это проверять

Чтобы картинка конвертировалась быстрей - нужно взять более мощный компьютер...

(0) вопрос, а зачем вообще конвертировать pdf в картинку?? Проще сразу pdf выплевывать клиенту. Он нормально в вебе открывается

(0) если все же нужно время на обработку, делайте через токены. Клиент запрашивает, вы ему сразу возвращаете токен. Далее клиент по этому токену получает сконвертированные файлы, если они готовы.

(3) pdf уже можно вставить в <img../> ? С каких пор?

(5) а накой вам в img вставлять? можете ссылку на pdf скидывать, либо в теле возвращать

а почему не складывать картинки в облако и не давать на них ссылки

(0) Если же нужно ускорить фтп, могу посоветовать winscp библиотеку. Через нее гораздо быстрее отрпавка и получение отрабатывает, так же есть возможность работать с sftp

(5) типа такой ссылки давать да и все https://www.cryptopro.ru/sites/default/files/products/pdf/files/CryptoProPDF_UserGuide.pdf

(0) В общем, если получится договориться без конверта в картинку, то просто выгружаете свой файл обмена с привязкой к ссылке на pdf. Файлик этот выплевываете после того как через winscp библиотеку успешно выгрузка прошла pdfок, там приходит ответ от библиотеки. И будет вам счастье.

(1) Не понял. Как это повлияет на скорость выгрузки картинок?
(3) Не хотят отдавать pdf-ку, хотят изображения. Один отдел готовит эти pdf-ки, а во что они будут сконвертированы и куда отправлены им уже пофиг.
(7) Можно. Но как связать, что вот эта вот картинка нужна вот в этой вот настройке выгрузки и если уже выгружена, то не выгружать?
(8) Знаем, есть такая. Но непонятно, как она поможет ускорить выгрузку. Т.е. 1 файл конвертируется 5 сек. А Xml-ка выгружается секунд 30. В основном время тратится на отбор нужных объектов.
(10) Не получится договориться, уже проверено) А потом клиент удалил картинку, и нам надо понимать, выгружать картинку заново или нет. Или мы удалили, у клиента тоже эта картинка должна удалиться.

А в чем проблема то?
Ты же знаешь куда картинка ляжет

(12) Проблема в том, что картинок может быть куча. А в момент выгрузки картинки я или не знаю, какому объекту она принадлежит, если выгружать данные и картинки разными процедурами. Или знаю, но конвертация картинки происходит долгое время, что тоже не устраивает клиента.

(13) чот бардак какой-то. нельзя структурированно раскладывать файлы на ftp?

(13) ну так в имени картинки привяжи ее к объекту

(13) но ты же знаешь заранее что картинки будут и в каком формате тоже известно

Чтобы не было битых ссылок, сначала выгружай картинки

(11) эта библиотека возвращает ответ, когда ты файлы передаешь. Это помогает на 100% удостовериться, что файл ушел на фтп. А после грузишь уже свою xml/jsn с привязкой ссылки на картинку к нужному объекту

(11) >>Можно. Но как связать, что вот эта вот картинка нужна вот в этой вот настройке выгрузки и если уже выгружена, то не выгружать?

ну как - взять и связать в РС )

(11) при удалении картинки, так же вначале проверяешь на наличие, если есть, то удаляешь с фтп и выгружаешь свою xml/json с записью, что такая картинка удалена. К примеру добавить тек <deleted_picture>ГуидКартинки</deleted_picture> либо свойство добавить для блока картинки, типа <active>false</active>

(20) тут конечно, лучше в обратном порядке, сначала файл удалением, а потом само удаление. Если же клиент сам удаляет картинку, то это надо через http сервис мутить.

(11) Если же клиентов дофига и все же нужно конвертировать данные, то тогда лучше свою апишку поднять. Пускай клиенты сами запрашивают, что им надо. Как я и писал в (4) Клиент просит документы, ты ему даешь токен и пишешь в свою базу с привязкой массиву нужных данных для конверта и формат конверта. Далее, как у тебя по рег заданию все сконвертится сможешь по токену вернуть нужные данные.

"1 клиент * 200 объектов * 3 картинки на объект * 5 секунд на картинку"

Запустить 600 фоновых заданий. И если сервак сдюжит, через 5 минут будет 600 картинок. :)

(23) 5 секунд, конечно же.

(24) он конвертит через какую то прогу, думаешь она поддержит 600 запусков параллельно?

каждому клиенту своя версия картинки? рили?

(25) какую-то, лол

(27) не работал с ней, для меня какая то)

схоронить у себя все картинки один раз, отдавать клиенту уже предварительно сконвертированные ранее не выгруженные картинки (например сделать план обмена с реквизитом "ftp" и на него регистрировать новые данные для выгрузки, в дальнейшем отдавать только новые данные)

(29) тут все зависит от специфики и соотношения. Если нужно конвертировать всего 10% от общего числа файлов и файлов ооочень много, то лучше по запросу.

(23) Это так не работает. Даже на разбивку на 600 заданий требуется время

(14) не бардак. Я в момент создания настройки определяю не объекты, а отборы. Файлы структурированно раскладываются. А вот их добавление/обновление/удаление на FTP и синхронизация с базой, в которой эти картинки храниться не должны, а должны только выгружаться по запросу, вот это да, проблема.
(17) Да это понятно, ну представь, ты отправил запрос и ждешь 3 часа, пока выгрузятся картинки. Норм?)
(29) Наши отказываются у себя сохранять, потому что место будет сжираться очень быстро и много. А база уже и так немаленькая.
Планы обмена не подойдут, потому что я не знаю какие конкретно объекты по каким настройкам будут выгружаться, и соответственно, таблицу изменений в момент записи объектов заполнить не смогу. Или при записи каждого объекта надо будет читать кучу настроек, что тоже будет очень долго.
(21)(22) Про веб- и хттп-сервисы думал, но тогда время на получение картинок также получается большим, и ждать 3 часа одного вызова веб-сервиса как-то не комильфо) Или имеешь ввиду, что запрос сделал, время прошло, данные подготовились, результат куда-то выложился, и клиента оповестить?

(32) зачем ждать 3 часа на один вызов, вызовы должны быть практически моментальными! У тебя Вася запросил УПДшку в формате jpg к примеру. Твой сервис вернул Васе токен 3355501123. У себя в базе записали например в регистр токен, нужный формат, нужный документ, строчка с путем для сформированного файла и признак, выгружен или нет. Далее делаешь рег задание, которое будет по этому регистру проходить, формировать картинки и пихать путь для них в него. Вася через какое то время заново долбится в твой веб сервис сообщая полученный токен, ты со своей стороны проверяешь, сформированы ли все пути по данному токену, если да, то возвращаешь васе пакет документов в виде ссылок. Если не готов, то так же сообщаешь. Как то так, можно регистр конечно обыграть по разному, это лишь один из примеров, который первый в голову пришел)

(32) та же почта россии использует данный способ, когда хочешь получить историю по 3тыс посылок. Чтобы не заддосить, они дают токен, по нему готовят для тебя историю и через какое то время ты можешь получить всю историю по посылкам переданным в токен.

(33)(34) Понял, спасиб, подумаю.

(35) а ещё подумай, чтобы после каждого ресайза и формата сохранить у себя на сервере эту версию. тогда в следующий вызов с такими параметрами не нужно будет запускать конвертер, а достать из своей библиотеки миниатюр.

(32) "А база уже и так немаленькая." - так храни в томе.

(36) + (37) + регламент по очистке самых старых и ненужных миниатюр.