избежать 2х данных, если они передумают завтра ватермарки юзать - просто отключить лип бандл. + вопрос был не в том где хранить картинки с ватермарками, а в том как скорость увеличить) по сути без разницы куда положить картинку, ее надо обработать сначала ))

а че не сгенерить копии всех картинок с вотермарками и их отдавать?

Ну обычно одними ватермарками дело не заканчивается, часто нужен ресайз опять же встроенные postprocessor тоже круть. А скорость у амазона повыше, чем у среднестатического VPS.

места на диске жалко?)

тем более ресайзы

места на диске жалко?)

Для этого амазон и нужен.

а че не сгенерить копии всех картинок с вотермарками и их отдавать?

Liip генерит их по запросу. Я так понял у ТС не получается настроить LIIP чтобы он брал картинку из амазона добавлял ватермарк и ложил в проект

та жесткий диск для этого нужон)

Liip генерит их по запросу. Я так понял у ТС не получается настроить LIIP чтобы он брал картинку из амазона добавлял ватермарк и ложил в проект

ну там можно поиграться и он был работал.

там же можно юзать процессор отдельно.

ай ладно

Да это пытаемся выяснить, жаль только ТС не участвует :)

Всем привет! Liip - почитаю доку внимательней, отпишусь потом. извините пока занят)

точняк https://github.com/doctrine/doctrine2/pull/1482

это ж давно уже было

а че не сгенерить копии всех картинок с вотермарками и их отдавать?

а зачем если можно делать это по требованию?

чтобы задержка была меньше?

чтобы задержка была меньше?

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

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

норм вариант, не надо 10 амазонов юзать

поменялась вотермарка - перегенеривать все?

основная причина - отсутствие необходимости перегенеривать все. Скажем у меня есть 4 варианта превьюшек разных размеров для каждой платформы, но 90% картинок никто даже грузить не будет. Да и "размеры могут поменяться в любой момент". А так - у меня это на уровне CDN просто кэшируется.

да и с тулами вроде imaginary это куда проще чем со всякими liip-ами

если у тебя запросили 2к картинок одним запросом

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

из каких-нибудь 4к разрешений

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

меньше чем заресайзить все 100K

ну сайзы не часто меняются

ну сайзы не часто меняются

наивный)

у нас 3 года назад добавились сайзы только

ну зависит же от трафика и требований

так что можно закрыть вопрос

у нас картинок не 100к

ну вот смотри... imaginary выдавал мне где-то 40-60 rpc (картинок в секунду). Большая часть картинок за которыми ходят пользователи - общие, так что один кто-то запроси, и всем загенерилось и закэшировалось. Описанный тобой кейс - 2000 картинок разом - это чушь.

а где-то 100кк

хотя уже больше

как минимум потому что никто не будет отображать/грузить столько скопом

каждый день заходит по 100к новых только

если у тебя есть такие кейсы - можно уже по другому говорить.

плюс нужно дубликаты удалять, обрабатывать их и тд. там целая цепочка обработки после того как пришла картинка

на лету это делать долго)

плюс нужно дубликаты удалять, обрабатывать их и тд. там целая цепочка обработки после того как пришла картинка

удаление дубликатов - это действительно не стоит делать на лету (ибо глупо)

но давай все же спустимся с небес на землю

у тебя вряд-ли в большнстве случаев будет более 100 уникальных запросов на картинки в секунду

в моем кейсе запрашивается около 2-4к картинок

за один поисковый запрос

но они у тебя не за одну секунду скачиваются, так?

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

ну юзер увидит за раз штук 30 только

остальные спрятаны под пагинацией в жсе

ну вот я и говорю - не более 100 уникальных запросов на картинки.

но показываем их быстро)

а если их просто кешировать, то попадание в кеш вообще минимальное будет

а если их просто кешировать, то попадание в кеш вообще минимальное будет

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

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

Вы что инжектите EntityManager или EntityManagerInterface?

Вы что инжектите EntityManager или EntityManagerInterface?

интерфейс

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

Вы что инжектите EntityManager или EntityManagerInterface?

тебе даже симфони скажет чтобы интерфейс инжектил

если хочешь автовайринг

А что тогда делать с этим?)

Получить в отдельную переменную и добавить phpdoc ?

не юзать getRepository

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

но тут мы тогда не будем делать оптимальных ресайзингов под клиент и будем выдавать какие-то фиксированные размеры. В моем же случае - размеры "вьюпорта" сильно менялись и в зависимости от этого нужны были разные размеры.

поддерживаю - не юзай getRepository

ERROR: S client not available

но тут мы тогда не будем делать оптимальных ресайзингов под клиент и будем выдавать какие-то фиксированные размеры. В моем же случае - размеры "вьюпорта" сильно менялись и в зависимости от этого нужны были разные размеры.

если был размер 350 и стал 300 то в принципе потерпеть с этим сайзом можно

пусть браузер ресайзит)

поддерживаю - не юзай getRepository

+1

ну в общем я подумаю на счет ресайзить на лету, надо попробовать. возможно есть смысл

Если есть возможность поднять отдельную тулзу для ресайза, можно заюзать это https://github.com/thumbor/thumbor

если был размер 350 и стал 300 то в принципе потерпеть с этим сайзом можно

ну я про всякие ретины.... когда разброс вьюпорта с 5K до 460px

Если есть возможность поднять отдельную тулзу для ресайза, можно заюзать это https://github.com/thumbor/thumbor

там вообще наверное есть смысл поднимать сервер на чем-то очень быстром

если сам ресайз с imagemagick будет на сях идти, то остальной оверхед надо исключать полностью

если сам ресайз с imagemagick будет на сях идти, то остальной оверхед надо исключать полностью

https://github.com/jcupitt/php-vips

может тебе будет интересно

угу, спс

как по мне - неплохая замена imagemagic-у

кто-то применяет json schema валидацию? возникла идея запилить общую валидацию для фронта и бека на ее основе

кто-то применяет json schema валидацию? возникла идея запилить общую валидацию для фронта и бека на ее основе

можно еще формочки на фронте генерить под нее)

Можно как то через yaml добавить сервису тег, если этот сервис был объявлен в другом yaml файле?

Можно как то через yaml добавить сервису тег, если этот сервис был объявлен в другом yaml файле?

нет

только через компайл пасс

(ну или при build контейнера короч)

бяда

бяда

бяда это необходимость лепить теги не твоим зависимостям

https://github.com/symfony/symfony-docs/issues/8097#issuecomment-348963302

можно еще формочки на фронте генерить под нее)

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

https://github.com/symfony/symfony-docs/issues/8097#issuecomment-348963302

зачем тебе доставать из контейнера приватные сервисы?

поправка - не свои приватные сервисы

не свои не надо

Не хочется на свои теги вешать, так как придётся явно их объявлять. Autowire же позволяет не объявлять

их - сервисы

если ты их явно не объявляешь - они деталь реализации)

ну или у нас все плохо с инверсией зависимостей)

Почему это?

App\: resource: '%kernel.project_dir%/src'

Почему это?

потому что нет инверсии зависимостей. Иначе у тебя были бы интерфейсы а значит нужны элиасы