Видеозапись будет. За прошлый вебинар тоже.
Вопрос времени.
Так как данный формат докладов у нас проводится впервые, то возникают некоторые технические трудности.
Storage должен отдавать статично файлы, чем быстрее тем лучше.
Вынесение логики работы приложения на Storage это во-первых замедление отдачи файлов, во-вторых дополнительная точка отказа.
Тем более в вашем примере вообще 3 варианта запроса, это значит, что Backend сначала делает запрос Try, в случае отказа — запрос Make, а потом запрос Give. Итого 3 запроса на одно превью — пример действительно тупой.
Даже лишнее обращение к диску на предмет существования файла для высоконагруженных систем — уже плохо.
Нет, давайте уж мухи отдельно, котлеты отдельно.
Это раздел ngnix, следовательно он используется априори, остальное не имеет значение.
Можно. Можно сделать через обработчик 404 ошибки, можно через mod_rewrite, но это будет скрипт, который, впрочем, тоже не всегда подойдет для любого хостинга.
Экономия достигается за счет того, что для старых фото, превьюшки не лежать в кеше, так как их никто не смотрит, реально в кеше лежат сгенеренные превью для фото, загруженных за последние 2-3 дня + топовые, а это ничтожно мало по сравнению с остальным контентом.
Не понял вопроса про то, что нам приходится хранить оригиналы фото, все таки это основная задача фотохостинга.
Как раз для этого и используется ngx_http_secure_link_module.
На приложение может формировать любые размеры, но извне сгенерить URL любого превью достаточно сложно не зная secure_link_secret.
Тут только вопрос насколько можно давать пользователям доступ к функции формирования URL превью приложения.
Все зависит от архитектуры, например у меня на фотохостинге storage-сервера и backend-сервера стоят раздельно, при этом на storage-серверах процессорное время не использовалось. Проставили на них ресайз на лету — сэкономили 30 % дискового пространства, но при этом 30 % загрузка процессоров в пике, но они и так простаивали до этого.
В моем примере предоставлена возможность формировать размеры исходя из того что передано в uri.
Ничто мешает сделать location ~ /i/sm… в котором жестко указать размеры и фильтр для этого вида изображений. Тем более их можно будет менять без вреда для здоровья, для всех сразу.
Правда, придется каждый дополнительный размер описывать отдельно в конфиге, но это гораздо проще, чем кодинг.
Почему нет? Кстати для онлайн СМИ это более оправдано, так как в них присутствует «горячий» контент, который будет кешироваться. Картинки старых новостей не будут занимать лишнего места. При смене дизайна, не нужно будет задумываться о том, что бы проводить глобальный ресайз по всем картинкам, формировать новые и удалять старые превью.
В общем-то, именно поэтому ресайз выделен в отдельный хост, что бы можно было вообще разделить сервера: frontend-сервер с кешированием, storage-сервер с ресайзом.
Вопрос времени.
Так как данный формат докладов у нас проводится впервые, то возникают некоторые технические трудности.
habrahabr.ru/blogs/webdev/99108/?reply_to=3057636#comment_3057641
Это объясняет остановку проекта на 9 дней.
А потом еще, при следующем редизайне.
Говно вопрос.
Не в качестве рекламы, а так, как защита от тупого перекладывания картинок из одного размера в другой.
Вынесение логики работы приложения на Storage это во-первых замедление отдачи файлов, во-вторых дополнительная точка отказа.
Тем более в вашем примере вообще 3 варианта запроса, это значит, что Backend сначала делает запрос Try, в случае отказа — запрос Make, а потом запрос Give. Итого 3 запроса на одно превью — пример действительно тупой.
Даже лишнее обращение к диску на предмет существования файла для высоконагруженных систем — уже плохо.
Это раздел ngnix, следовательно он используется априори, остальное не имеет значение.
Можно. Можно сделать через обработчик 404 ошибки, можно через mod_rewrite, но это будет скрипт, который, впрочем, тоже не всегда подойдет для любого хостинга.
А зачем?
> Как вообще указанный модуль работает, я что-то не совсем понял?
sysoev.ru/nginx/docs/http/ngx_http_secure_link_module.html
Не понял вопроса про то, что нам приходится хранить оригиналы фото, все таки это основная задача фотохостинга.
На приложение может формировать любые размеры, но извне сгенерить URL любого превью достаточно сложно не зная secure_link_secret.
Тут только вопрос насколько можно давать пользователям доступ к функции формирования URL превью приложения.
Ничто мешает сделать location ~ /i/sm… в котором жестко указать размеры и фильтр для этого вида изображений. Тем более их можно будет менять без вреда для здоровья, для всех сразу.
Правда, придется каждый дополнительный размер описывать отдельно в конфиге, но это гораздо проще, чем кодинг.