Загрузка файлов на разные серверы, диски. Структура, ахритектура

[Активист]

Maxsystems
Вот что ты не веришь все?

Сколько процессорного времени нужно, что бы на лету ресайзить и отдавать картинку в браузер - правильно - дох...я. (если картинка 10 MB)

Сколько процессорного времени нужно для того, что бы отправить в бразуер файл - правильно - сооооовсем чуть чуть

Уронить сервер (час будет фотки обрабатывать в 100% CPU) достаточно послав пару сотню асинхронных запросов к твоей фотке

 

[Maxsystems]

Автор оригинала: Активист
Maxsystems
Сколько процессорного времени нужно, что бы на лету ресайзить и отдавать картинку в браузер - правильно - дох...я. (если картинка 10 MB)

Это согласен, но мысль немного другая
Есть графика 1600х1200.jpg = 2.5 mb мы её того уменьшаем пропорционально => 400x300.jpg она весит уже не 10 мб, килобайт ~75 ... Думаю это не большой вес, и легко пропарируеться в любой нужный размер меньше.

Вариант второй, мы не перекодируем картинку, а тупо вычисляем пропроционально размер в браузере, например нужна картинка 100х75, мы подставляем адрес оригинала и задаем размеры в html разметке тоесть:
<img src="400x300.jpg" width="100" height="75">

Минус конешно есть - сайт немного тяжеловат становиться, но если учесть что сейчас у людей выделинки и они киношки качают с тырнета, думаю сильно на это не скажеться, а еще сейчас модно иметь широформатные мониторы, а кто нибудь видел как смотряться на них сайты? они крошки, но просматривать можно - несколько раз ctrl+ и сайт увеличиваеться, вот только косяки с картинками они тоже увеличиваются, а так как они маленькое разрешение на экране они расплывчатые и не красивые, а вот если увеличивать картинку заданную с уменьшенными width и height чем реальные, то картинка просто начинает показывать свой настоящий размер, и смотрится очень красиво.

Думаю последний вариант ему больше подойдет чем хз как хранить копии 4 миниатюр..

 

[pilot911]

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

это экономит не только дисковое пространство, но и процессорное время


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


это аплоад-серваки выбирал бы рандомно из конфига при каждом формировании <form action="path.....">

-~{}~ 01.11.08 06:06:

Автор оригинала: phprus
Maxsystems

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

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

 

[Angerslave]

pilot911
Попрофайли ресайз картинок, особенно на потербление оперативы
Всё-таки лучше 1 раз сделать и потом отдавать статический контент, чем постоянно проделывать серьёзный объём работы. Например, если сервер выдержит 10 динамических картинок в секунду, то статических он, пожалуй, 3000 в секунду отдаст, и то всё в сеть упрётся.

 

[fixxxer]

да чо вы с ним спорите, уже давно понятно что его надо по нику игнорить

 

[pilot911]

Автор оригинала: Angerslave
pilot911
Попрофайли ресайз картинок, особенно на потербление оперативы
Всё-таки лучше 1 раз сделать и потом отдавать статический контент, чем постоянно проделывать серьёзный объём работы. Например, если сервер выдержит 10 динамических картинок в секунду, то статических он, пожалуй, 3000 в секунду отдаст, и то всё в сеть упрётся.

нет, не согласен со скоростью конвертации
если конвертить имаджмеджиком жпег - скорость конвертации буквально миллисекунды, если конвертить гиф с фреймами - скорость заметно падает, но сколько таких гифоф загружает пользователь?

все фотки в основном жпег....

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

 

[Angerslave]

pilot911
Google bot, Yandex bot, Yahoo! slurp и т.п. - сожрут и не подавятся сервером, который будет при каждом запросе заново генерить картинку. Ок, чтобы не быть голословным, приведу тесты:

SRC: 200x150, DEST: 100x75
ab -n 1000 -c 20 *php* - 141.7 req/sec
ab -n 1000 -c 20 *file* - 921.8 req/sec

// Весьма благоприятный исход, учитывая маленький размер. попробуем увеличить исходник до 1000x750(тоже вполне щадящий режим).

Статика, естественно, также выдаётся, а вот скрипт на порядок медленнее - всего 15.2 req/sec. И чем больше мегапикселей в исходной картинке, тем больше будет разрыв.

 

[MiksIr]

pilot911, не нада думать, сколько ресайз занимает времени, надо думать - что лучше
Предварительный ресайз
+ Фото ресайзится 1 раз
+ Легко масштабируется отдача фото
+ Быстро отдается
- Фото занимает ~ на 10% больше дисков
"На лету"
+ Не занимает лишнего места на диске
- Фото ресайзится много раз. Для тех фото, что просматриваются с частотой сопоставимой с временем жизни временного кеша - ресайз на каждый просмотр.
- Одна нода будет отдавать на порядок-два меньше фото (а значит для достижения той же производительности - нужно на порядок больше нод)
- Сложности в масштабировании - нужно организовывать очереди и т.д. - усложнение архитектуры.

И.. что лучше? Хотя для сайта, на которых заходят 15 инвалидов в день считая ботов... все-равно. Но если вдруг побольше - все ляжет. Вы хотите такие сайты делать?

-~{}~ 01.11.08 18:45:

PS: несомненно, могут быть задачи, когда ресайз "на лету" будет более выгоден. Как правило это большое хранилище с малым числом просмотров "превьюшек". Ну в общем фотогалерея никак не вписывается в такую задачу.

 

[pilot911]

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

зачем при каждом запросе ресайзить картинку ?

поступил запрос на данный размер - отресайзили и сохранили картинку в файл...

неужели вы думаете, что фотохостинги ресайзят на все 5 масштабов все заливаемые картинки ?

все делается по запросу и созданные фотки сохраняются в виде файлов, и потом отдаются статикой, естесссно


-~{}~ 01.11.08 19:48:

Автор оригинала: fixxxer
да чо вы с ним спорите, уже давно понятно что его надо по нику игнорить

в каждой бочке затычка ?

 

[Angerslave]

> ресайзить картинки нужно по запросу, мы это уже обсуждали
Хммм. Я из этой фразы сделал вполне логичный вывод - ресайзить картинку при каждом запросе. Это типа обратный ход?

 

[pilot911]

Автор оригинала: Angerslave
> ресайзить картинки нужно по запросу, мы это уже обсуждали
Хммм. Я из этой фразы сделал вполне логичный вывод - ресайзить картинку при каждом запросе. Это типа обратный ход?

при каждом запросе .. ну не знаю.. кто до этого додумается вполне может претендовать на премию IgNobel Prizes

 

[флоппик]

Между прочим, pilot911 в общем частном случае прав. И аргументирует внятно. Хоть и с хромой терминологией.

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

Хайлоад требует деградированного кода. И это факт.

 

[pilot911]

ПС.

после заливки ресайзится сразу же только дефолтный размер и сохранятся в файл

 

[MiksIr]

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

Я вот правда не понимаю о чем тут спорят. Что вы, сторонники ресайза на запросе, хотите выиграть? Сколько процентов диска... м?

 

[fixxxer]

уберите этого клоуна.

по теме.
вообще если проект будет расти то столкнешься с тем, что фоток будет сильно дофига, и узким местом станет диск, то есть его seek-и. вообще как устроена ос, она всю доступную память использует под кэш файловой системы, то что закэшилось отдается быстро, то, что надо читать с диска, медленнее. то есть прежде всего надо определить объемы горячего контента (того, к которому часто обращаются); если оперативы достаточно, чтобы там он поместился, то все прекрасно. если же нет, то следует разделить задачи хранения и раздачи. для хранения вполне подходят "медленные" сата массивы, для раздачи уже скорее надо что-то побыстрее, те же scsi, или даже ssd. тут уже придется организовать двухуровневую систему, когда хранение происходит на бэкенд-стораджах, а фронтенты являются кэшем (как в памяти так и на диске), и кэшируют на своих быстрых дисках контент, к которому обращались в последнее время (если в кэше не найдено - проксируем запрос на бэкенд и сохраняем картинку в кэше). когда в nginx появится полноценное кэширование, можно использовать его, пока же приходится использовать разный самопал

а с адресацией вроде все совсем просто - например если у нас есть структура пользователь-фотоальбом-фото, то можно каждому пользователю поставить в соответствие координаты, где хранится его статика (номер сервера, номер диска итд), а там уже использовать структуру например /{floor(user_id%1000)}/user_id/{floor(photoalbum_id%1000)}/photoalbum_id/photo_id-width-height.jpg, ну тут в зависимости от.

 

[pilot911]

Автор оригинала: fixxxer
уберите этого клоуна.

по теме.
вообще если проект будет расти то столкнешься с тем, что фоток будет сильно дофига, и узким местом станет диск, то есть его seek-и. вообще как устроена ос, она всю доступную память использует под кэш файловой системы, то что закэшилось отдается быстро, то, что надо читать с диска, медленнее. то есть прежде всего надо определить объемы горячего контента (того, к которому часто обращаются); если оперативы достаточно, чтобы там он поместился, то все прекрасно. если же нет, то следует разделить задачи хранения и раздачи. для хранения вполне подходят "медленные" сата массивы, для раздачи уже скорее надо что-то побыстрее, те же scsi, или даже ssd. тут уже придется организовать двухуровневую систему, когда хранение происходит на бэкенд-стораджах, а фронтенты являются кэшем (как в памяти так и на диске), и кэшируют на своих быстрых дисках контент, к которому обращались в последнее время (если в кэше не найдено - проксируем запрос на бэкенд и сохраняем картинку в кэше). когда в nginx появится полноценное кэширование, можно использовать его, пока же приходится использовать разный самопал

а с адресацией вроде все совсем просто - например если у нас есть структура пользователь-фотоальбом-фото, то можно каждому пользователю поставить в соответствие координаты, где хранится его статика (номер сервера, номер диска итд), а там уже использовать структуру например /{floor(user_id%1000)}/user_id/{floor(photoalbum_id%1000)}/photoalbum_id/photo_id-width-height.jpg, ну тут в зависимости от.

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

 

[флоппик]

вы считаете кеши - деградацией кода?

Выберите другое слово. Более подходящее.
Я считаю, что любой код, нацеленный на грубый прирост производительности — деградацией приложения.
Полностраничный кеш —_грубый метод. Conditional get — идеологически верный. И кеш, и денормализация БД, это все нужные вещи. Но это все практика. Суровая реальность.
Я считаю, что перед тем, как учится пользоватся брутальными техниками, нацеленными на жесткий прирост производительности, нужно научится писать приложения.

Что вы, сторонники ресайза на запросе, хотите выиграть? Сколько процентов диска... м?

Типичная логика Хайлоадщика. Нисколько. Я хочу выиграть эффективность общей логики.
Золотое правило — перед тем, как оптимизировать узкое место, ОНО ДОЛЖНО ПОЯВИТСЯ!
Нельзя применять хайлоад-приктики к теоретическим, абстрактным приложениям.
И именно поэтому, мнение pilot911 — ценнее. Оно содержит в себе мысль, описание процесса. А не тупую логику уровня «А вот тут мы кеш впендюрим, он понизит нам нагрузку при ддос-атаках!!»

Я вот правда не понимаю о чем тут спорят.

 

[MiksIr]

pilot911 а вы работали? Часом не на фотофайле, который так повеселил своим докладом "как мы прикрывали очередную жопу" Прям как флоппик завещал - сначала не думая огребаем узкое место, а потом его уже оптимизируем. Конечно, если так проектировать, навека останется ощущение - что это деградация, ибо логика "оптимизация, когда уже все упало" - это логика "а щас это присрем, это приделаем - и вроде клевый костыль получился... правда, красота приложения нарушилась, ну и ладно"

Кстати, сказать чья типичная логика "нада как-то написать, не думая, а потом уже мож оптимизируем как-нить"? Тут много таких... просит "посмотрите мой код"

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

А чем мнение pilot911 ценнее, кстати? Тем, что он осмелился выступить "против этих хайлоадщиков"? Ну да, наверно это серьезная заявка на выбор верной архитектуры... корнями еще в древний мир тянеца А чем лучше его вариант, чем ЭФФЕКТИВНЕЕ логика то, как флоппик изволил выразится? - Какие плюсы и минусы, какой выигрыш... ах, извините, выигрыш - это уже не для настоящих программистов, забыл опять

Вы поместили слишком много изображений в свою подпись или в свое последнее сообщение. Пожалуйста, возвратитесь и исправьте эту ошибку.

Изображениями считаются смайлики, vB код и HTML <img> тэги. Использование их возможно только с разрешения администратора.[/QUOTE]
О, вижу форум написан настоящими программистами ;)

[size=1][i]-~{}~ 01.11.08 22:07:[/i][/size]

[b]fixxxer[/b] ну если честна, то написанное тобой про горячий контент не имеет отношения к способу генерации превьюшек. Ну или я не вижу разницу - как мы сгенерили превьюшку, которая потом уже ляжет в горячий кеш.

 

[pilot911]

Автор оригинала: MiksIr
pilot911 а вы работали? Часом не на фотофайле, который так повеселил своим докладом "как мы прикрывали очередную жопу" Прям как флоппик завещал - сначала не думая огребаем узкое место, а потом его уже оптимизируем. Конечно, если так проектировать, навека останется ощущение - что это деградация, ибо логика "оптимизация, когда уже все упало" - это логика "а щас это присрем, это приделаем - и вроде клевый костыль получился... правда, красота приложения нарушилась, ну и ладно"

Кстати, сказать чья типичная логика "нада как-то написать, не думая, а потом уже мож оптимизируем как-нить"? Тут много таких... просит "посмотрите мой код"

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

А чем мнение pilot911 ценнее, кстати? Тем, что он осмелился выступить "против этих хайлоадщиков"? Ну да, наверно это серьезная заявка на выбор верной архитектуры... корнями еще в древний мир тянеца А чем лучше его вариант, чем ЭФФЕКТИВНЕЕ логика то, как флоппик изволил выразится? - Какие плюсы и минусы, какой выигрыш... ах, извините, выигрыш - это уже не для настоящих программистов, забыл опять


О, вижу форум написан настоящими программистами

-~{}~ 01.11.08 22:07:

fixxxer ну если честна, то написанное тобой про горячий контент не имеет отношения к способу генерации превьюшек. Ну или я не вижу разницу - как мы сгенерили превьюшку, которая потом уже ляжет в горячий кеш.

флоппик абсолютно прав насчет того, как создаются хайлоад проекты

посмотрел выступление фотофайла на конференции - ведь не от отсутствия денег возникали проблемы с переписыванием движка, верно ?

причина в том, что невозможно на все 100% предсказать узкие места будущего крупного проекта


ПС. количество смайликов ограничивает модер

 

[флоппик]

) А чем лучше его вариант, чем ЭФФЕКТИВНЕЕ логика то, как флоппик изволил выразится? - Какие плюсы и минусы, какой выигрыш... ах, извините, выигрыш - это уже не для настоящих программистов, забыл опять

Выигрыш что нагрузку на процессор в обычном, не перегруженным запросами приложении — выгодно распределить по времени. Чем генерировать ее пиково единовременно.

"нада как-то написать, не думая, а потом уже мож оптимизируем как-нить"

Оптимизация и хайлоад — разные вещи. Хайлоад — это грубая заточка. И она нужна после того, когда заканчиваются архитектурные решения. И она нужна на реально узком месте.
Давай расскажи, что надо еще размер сегмента в TCP менять, для оптимизации сетевой нагрузке, и к чему мы прийдем в итоге? Ненадо фетешировать на хайлоад, ничего в нем необычного нет.
И ненадо говорить про «недумая огребаем». Как раз надо думать. Но до любого хайлоада — надо дожить. И есть такие вещи, как мониторинг ресурсов, и узкое место будет видно заранее. Нет таких приложений, которые пишутся раз —_и все идеально. И не будет никогда.

-~{}~ 02.11.08 01:17:

причина в том, что невозможно на все 100% предсказать узкие места

Причина в том, что их не нужно предсказывать. Нужно брать, и мерить. А вот MiksIr прав, у нас в этом плане все через жопу, мы сначала запустим в продакшн, а потом будем писать приложение. Хорошее приложение начинается не с кода. И не с хайлоада.