Загрузка файлов на разные серверы, диски. Структура, ахритектура
- Автор темы Spear
- Дата начала
MiksIr
miksir@home:~$
pilot911, а там осталось впечатление, что и не пытались предсказывать. Просто писали, не думая об этом. А потом уже никак кроме костылей. Дык, теперь даже гордятся 
Кстати, пришло в голову, а сколько телодвижений придется еще сделать для бизилоков... а то, знаете ли, придет несколько запросов на одну фотку.. нехорошо будет, если она будет ресайзица 10 раз одновременно... или это тоже "хайлоад"?
10 пользователей на протяжении суток загрузили 10 фотографий. На следующий день пришло 10 человек и посмотрело эти 10 разных фото одновременно. Получили прямо обратное - пиковую нагрузку на процессор. Утрировано, конечно, но загрузка фоток все же более предсказуемый процесс.
Кстати, пришло в голову, а сколько телодвижений придется еще сделать для бизилоков... а то, знаете ли, придет несколько запросов на одну фотку.. нехорошо будет, если она будет ресайзица 10 раз одновременно... или это тоже "хайлоад"?
ыыыыы =)))))))
ну я вобщем то скорее отвечал на изначальный вопрос тредстартера.
если уж хочется обсудить бред с генерацией на лету, то, помимо уже озвученного, во первых, надо париться с блокировками, чтобы два ресайза сразу не запустились, во вторых, время генерации, особенно если не тупо а проходиться фильтрами типа шарпа, становится неприемлемым.
pilot911
Новичок
Автор оригинала: MiksIr
pilot911, а там осталось впечатление, что и не пытались предсказывать. Просто писали, не думая об этом. А потом уже никак кроме костылей. Дык, теперь даже гордятся
10 пользователей на протяжении суток загрузили 10 фотографий. На следующий день пришло 10 человек и посмотрело эти 10 разных фото одновременно. Получили прямо обратное - пиковую нагрузку на процессор. Утрировано, конечно, но загрузка фоток все же более предсказуемый процесс.
Кстати, пришло в голову, а сколько телодвижений придется еще сделать для бизилоков... а то, знаете ли, придет несколько запросов на одну фотку.. нехорошо будет, если она будет ресайзица 10 раз одновременно... или это тоже "хайлоад"?
речь о разных фотках, только что заметил
в общем, все теория.. эхх
Нет, это верно. Но на самом деле, с бизлоками нет таких проблем, как кажется, если генерить сначала файл, а потом уже класть в нужную папку.
В любом случае, либо у тебя одномоментно пользователь, загружающий фото получит (неприемлемое время * число превью), либо несколько разных пользователей в разное время по одному разу неприемлемое время. Я бы, на самом деле, вообще вынес генерацию превью в фоновый процесс, а если юзер запросил раньше фоновой генерации - генерил бы на лету.
-~{}~ 02.11.08 02:01:
MiksIr, я пытаюсь обьяснить, что хайлоад — это всегда частный случай. Который всегда рассматривается применительно к реальной системе, а не к абстракции. Ты считаешь, что это не так?
Есть такое слово «рентабельность».
И если у меня
-~{}~ 02.11.08 02:15:
Я понимаю, что хайлоад — это модно, это круто. Этим хочется хвастаться. А что вы делали до хайлоада? Мир не делится только на гостевые Васи Пупкина и хайлоаденный Яндекс.Фотки. Есть множество градаций задач, причин и нужд. И нужно к ним идти — постепенно.
И когда вы жалуетесь на проблему отсутствия кадров — причина отчасти в вас. Вы учите этих самых кадров тому, что вы знаете и умеете. Забывая при этом о фундаменте, который наживали потом и кровью. О том, как писать нормальные приложения.
-~{}~ 02.11.08 02:19:
Хотя на ответ именно топикстартера, а не последововшего позже холивара, правильный ответ дал именноMiksIr
И если у меня
то да, это хайлоад. Можно придумать сколько угодно гипотетических ситуаций. Но возьмем твой пример. Ты можешь привести среднюю статистику посещаемости проекта, достаточную для того, чтобы более-менее регулярно возникала ситуация одновременного (в пределах времени генерации превью) запроса ее генерации? Даже без учета фоновой генерации превью?
-~{}~ 02.11.08 02:15:
Я понимаю, что хайлоад — это модно, это круто. Этим хочется хвастаться. А что вы делали до хайлоада? Мир не делится только на гостевые Васи Пупкина и хайлоаденный Яндекс.Фотки. Есть множество градаций задач, причин и нужд. И нужно к ним идти — постепенно.
И когда вы жалуетесь на проблему отсутствия кадров — причина отчасти в вас. Вы учите этих самых кадров тому, что вы знаете и умеете. Забывая при этом о фундаменте, который наживали потом и кровью. О том, как писать нормальные приложения.
-~{}~ 02.11.08 02:19:
Хотя на ответ именно топикстартера, а не последововшего позже холивара, правильный ответ дал именноMiksIr
MiksIr
miksir@home:~$
флоппик, просто мы вкладываем разные понятия в хайлоад У тебя это почему-то ассоциируется с каким-то шаманством, тюнингом и костылями У меня хайлоад - это что-то вроде следующей стадии развития думалки. Когда ты не просто думаешь архитектуру, а ты еще думаешь как это будет работать и где может быть затык, и как его красиво обойти сейчас или потом(!)...
Да, возможно на эту галерею никогда не придет более 1 человека в сутки, и можно ваше не парица и генерировать на лету без сохранения. Результатом является огромное количество продуктов, от которых потом на форумах стоны "у меня всего-то 500 уникалов в сутки, а хостинг блокирует за нагрузку". Это не правильно так разрабатывать...
Для кого-то может и построение индексов нужных является гипотетическим действием... действительно, зачем это делать, если на сайте один калека.
Так что примеры нагрузки тут абстрактны. Но подумай вот о чем... для того, что бы оценить характер нагрузки при предварительном ресайзе тебе достаточно знать распределение того, как пользователи загружают фотки. Достаточно предсказуемое распределение. Для прогнозирования того, как поведет себя ресайз на лету нужно знать дофига больше параметров - как ходят пользователи по альбомам, как и в каких разрешениях они любят смотреть фотки. Именно по-этому оценить потенциально узкие места сложнее, чем в первом случае.
Есть еще один ньюанс... ясно, что затык (будем считать затыком когда в очереди накапливается больше, чем она способна отресайзить) может произойти в обоих случаях. В случае прересайза этот затык приведет к тому, что загруженная пользователем фотка появится на сайте чуть позже (можно даже нарисовать типа "ждите"). Затык в случае ресайза на лету приведет к тому, что посетители сайта не увидят фотку, а получат в лучшем случае заглушку. Что хуже?
А если смотреть схему прересайза основной превьюшки и ресайза на лету остальных... ну не ясно зачем, правда. Распределение нагрузки на процессор тут не аргумент - очень сложно спрогнозировать как он будет грузится (причем в случае ресайза на лету - гораздо сложнее будет).
Насчет обучения... ну зачем учить плохому? Человек же не просто галлерейку написать решил - у него явно желание узнать, как это сделать правильно, что бы и масштабировать в случае чего. Да, иногда хайлоад решения излишние и нафиг не нужны. Иногда эти решения настолько обычны, что применимы и в домашней страничке - хуже то не будет, а у человека задел останется от чужого опыта.
-~{}~ 01.11.08 23:38:
pilot911, не понял вопроса? Предлагаете разработать архитектуру фотохранилища с возможностью пропажи фоток?
У тебя это почему-то ассоциируется с каким-то шаманством, тюнингом и костылями У меня хайлоад - это что-то вроде следующей стадии развития думалки. Когда ты не просто думаешь архитектуру, а ты еще думаешь как это будет работать и где может быть затык, и как его красиво обойти сейчас или потом(!)... Да, возможно на эту галерею никогда не придет более 1 человека в сутки, и можно ваше не парица и генерировать на лету без сохранения. Результатом является огромное количество продуктов, от которых потом на форумах стоны "у меня всего-то 500 уникалов в сутки, а хостинг блокирует за нагрузку". Это не правильно так разрабатывать...
Для кого-то может и построение индексов нужных является гипотетическим действием... действительно, зачем это делать, если на сайте один калека.
Так что примеры нагрузки тут абстрактны. Но подумай вот о чем... для того, что бы оценить характер нагрузки при предварительном ресайзе тебе достаточно знать распределение того, как пользователи загружают фотки. Достаточно предсказуемое распределение. Для прогнозирования того, как поведет себя ресайз на лету нужно знать дофига больше параметров - как ходят пользователи по альбомам, как и в каких разрешениях они любят смотреть фотки. Именно по-этому оценить потенциально узкие места сложнее, чем в первом случае.
Есть еще один ньюанс... ясно, что затык (будем считать затыком когда в очереди накапливается больше, чем она способна отресайзить) может произойти в обоих случаях. В случае прересайза этот затык приведет к тому, что загруженная пользователем фотка появится на сайте чуть позже (можно даже нарисовать типа "ждите"). Затык в случае ресайза на лету приведет к тому, что посетители сайта не увидят фотку, а получат в лучшем случае заглушку. Что хуже?
А если смотреть схему прересайза основной превьюшки и ресайза на лету остальных... ну не ясно зачем, правда. Распределение нагрузки на процессор тут не аргумент - очень сложно спрогнозировать как он будет грузится (причем в случае ресайза на лету - гораздо сложнее будет).
Насчет обучения... ну зачем учить плохому? Человек же не просто галлерейку написать решил - у него явно желание узнать, как это сделать правильно, что бы и масштабировать в случае чего. Да, иногда хайлоад решения излишние и нафиг не нужны. Иногда эти решения настолько обычны, что применимы и в домашней страничке - хуже то не будет, а у человека задел останется от чужого опыта.
-~{}~ 01.11.08 23:38:
pilot911, не понял вопроса? Предлагаете разработать архитектуру фотохранилища с возможностью пропажи фоток?
Ты прав. 
Потому что многие «хайлоадеры» считают хайлоад умением подоткнуть под приложения костыли, когда оно падает.
Вот когда ты перестаешь сумбурно излагать, и собираешься, то с тобой очень приятно дискутировать.
Но я просто пытаюсь обьяснить... что нельзя опиратся на чужой опыт. Просто это очень часто превращается в «а вон там человек работал на видеохостинге, они юзали Hadoop, значит, и нам нужно!». И неважно, что мы делаем онлайн-фотошоп. Где нам важнее процессорное время, чем целостность хранилища. Или затык у нас —_в сети, и нам надо менять пресловутый размер TCP сегмента, что бы получить нужную эффективность между серверами.
И гадать, какой способ ресайза в несозданном еще приложении будет эффективнее — пустое дело.
Кстати, вот придумал пример, где ресайз-он-деманд будет полезнее: представь хостинг с обоями для рабочего стола, где они генерируются под все разрешения.
Для меня это не хайлоад, это нормальное проектирование. А почему ассоциируется
ты ж сам понимаешь, почему.
Потому что многие «хайлоадеры» считают хайлоад умением подоткнуть под приложения костыли, когда оно падает.Все понятно. Я согласен с тобой, на самом деле, полностью.
Вот когда ты перестаешь сумбурно излагать, и собираешься, то с тобой очень приятно дискутировать.
Но я просто пытаюсь обьяснить... что нельзя опиратся на чужой опыт. Просто это очень часто превращается в «а вон там человек работал на видеохостинге, они юзали Hadoop, значит, и нам нужно!». И неважно, что мы делаем онлайн-фотошоп. Где нам важнее процессорное время, чем целостность хранилища. Или затык у нас —_в сети, и нам надо менять пресловутый размер TCP сегмента, что бы получить нужную эффективность между серверами.
И гадать, какой способ ресайза в несозданном еще приложении будет эффективнее — пустое дело.
Кстати, вот придумал пример, где ресайз-он-деманд будет полезнее: представь хостинг с обоями для рабочего стола, где они генерируются под все разрешения.
Angerslave
Новичок
Вэй, сколько наговорили, да
Хайлоад это не заточка, это распределённая архитектура. Но мы сейчас скорее про оптимизацию говорим - как быстрее, а не как распределённее.
Что-то кто-то там про seek на диске упоминал... Хаха, учитывая, что фотка 1600x1200 будет весить 1,5Мб, то в ОЗУ таких поместится не сильно много. На ресайзнутых фоток размером 30Кб в ОЗУ поместится гораздо больше, то в любом случае ресайз не в выигрыше. Ведь вместо "взять маленький файл и просто отдать" надо "взять большой файл(найти, прочитать), уменьшить(распаковать, уменьшить, запаковать), отдать".
Безусловно, есть случаи, когда из-за принципиальных причин статическая кешированая картинка не подойдёт - например, ставить на картинке текущий таймстэмп. Или какие другие динамические даннные. В каком-то случае, вероятно, кэш будет невыгоден. Но если хотя бы каждый 2й запрос будет аналогичен ранее обработаному, то кеш будет выгоден. Ведь оверхед от сохранения мизерный и зачастую полностью нивелируется за счёт уменьшения времени чтения файла с диска, не говоря уже о нагрузке на процессор и ОЗУ. А каждый второй запрос у очень многих систем будет аналогичен какому-нибудь ранее обработаному.
У кэша, имхо, два минуса - увеличение сложности и увеличение расхода места на винте. И с тем, и с другим в наше время вполне успешно справляются.
Хайлоад это не заточка, это распределённая архитектура. Но мы сейчас скорее про оптимизацию говорим - как быстрее, а не как распределённее.
Что-то кто-то там про seek на диске упоминал... Хаха, учитывая, что фотка 1600x1200 будет весить 1,5Мб, то в ОЗУ таких поместится не сильно много. На ресайзнутых фоток размером 30Кб в ОЗУ поместится гораздо больше, то в любом случае ресайз не в выигрыше. Ведь вместо "взять маленький файл и просто отдать" надо "взять большой файл(найти, прочитать), уменьшить(распаковать, уменьшить, запаковать), отдать".
Безусловно, есть случаи, когда из-за принципиальных причин статическая кешированая картинка не подойдёт - например, ставить на картинке текущий таймстэмп. Или какие другие динамические даннные. В каком-то случае, вероятно, кэш будет невыгоден. Но если хотя бы каждый 2й запрос будет аналогичен ранее обработаному, то кеш будет выгоден. Ведь оверхед от сохранения мизерный и зачастую полностью нивелируется за счёт уменьшения времени чтения файла с диска, не говоря уже о нагрузке на процессор и ОЗУ. А каждый второй запрос у очень многих систем будет аналогичен какому-нибудь ранее обработаному.
У кэша, имхо, два минуса - увеличение сложности и увеличение расхода места на винте. И с тем, и с другим в наше время вполне успешно справляются.
Angerslave
ещё не проснулся?
причём тут seek на диске до ОЗУ?
да и о резайсе обсуждали когда выгоднее делать, а не нужно ли вообще. зачем превьюхи в озу сунить?
да и я вообще не понимаю почему решили, что генерация превьюх в большом проекте может стать тонким местом, учитывая количество серваков занятых только под файлы
ещё не проснулся?
причём тут seek на диске до ОЗУ?
да и о резайсе обсуждали когда выгоднее делать, а не нужно ли вообще. зачем превьюхи в озу сунить?
да и я вообще не понимаю почему решили, что генерация превьюх в большом проекте может стать тонким местом, учитывая количество серваков занятых только под файлы
Angerslave
Новичок
AmdY
> вообще если проект будет расти то столкнешься с тем, что фоток будет сильно дофига, и узким местом станет диск, то есть его seek-и.
> да и о резайсе обсуждали когда выгоднее делать, а не нужно ли вообще. зачем превьюхи в озу сунить?
Потому, что из ОЗУ всё берётся на пару порядков быстрее, чем с диска.
> да и я вообще не понимаю почему решили, что генерация превьюх в большом проекте может стать тонким местом, учитывая количество серваков занятых только под файлы
А никто и не говорит, что это станет самым узким местом. Но проблем вполне может принести.
> вообще если проект будет расти то столкнешься с тем, что фоток будет сильно дофига, и узким местом станет диск, то есть его seek-и.
> да и о резайсе обсуждали когда выгоднее делать, а не нужно ли вообще. зачем превьюхи в озу сунить?
Потому, что из ОЗУ всё берётся на пару порядков быстрее, чем с диска.
> да и я вообще не понимаю почему решили, что генерация превьюх в большом проекте может стать тонким местом, учитывая количество серваков занятых только под файлы
А никто и не говорит, что это станет самым узким местом. Но проблем вполне может принести.
korchasa
LIMB infected
Проблемы принести может что угодно. В чем тут может быть узкое место? CPU из-за большого количества ресайзов? Тогда организуем очередь на каждом сторадже, и слушаем ее ограниченным количеством потоков.
2pilot911
Фотохостинги разные. Я участвовал в трех, и на всех использовали прегенерацию, ибо это избавляет от dog-pile, и позволяет размазать нагрузку от генерации равномерно. Фотохостинг где пользователь заливает фотки, а потом сам не смотрит их тумбы, это очень странный ресурс.
pilot911
Новичок
тумбы и дефолтный размер генерятся сразу после заливки, перед редиректом юзера на страницу
но помимо дефолтного размера есть еще 5 других, которые юзер чаще всего просто проигнорирует
ПС. самая лучшая тема - это прегенерация размеров на машине юзера через activeX или экстеншен FF, которые позволяют заливать сразу целую директорию
korchasa
LIMB infected
Автор оригинала: pilot911
Т.е. вы признаете, что это не "дорого". hint: не обязательно генерировать вариации из оригинала
И в чем смысл on-demand в этом случае? Проц "дорогой" или место на винчестере? Любое подобное архитектурное решение не имеет смысла без цифр. Все будет зависеть от размеров исходных фото, размеров вариаций, времени на конвертации, требований по отклику, ограничений по диску, прочая-прочая. Невозможно сделать идеальное решение для общего случая, т.к. оно будет проигрывать любому узкоспециализированному решению.Это не решение - это фенечка, которой будут далеко не все пользоваться.
Spear
почемучка
Ох вы тут наоффтопили я считаю что ресайт картинок на лету - это клиника. Тем более что ресайз делается в 3 варианта (стандартный и 2 маленьких, превьюшки под разные нужды). Ещё рассматривается возможность сохранения оригинала, но вопрос состоял ведь не в том как ресайзить, мне было интересно как лучше всё это чудо хранить.
я считаю что ресайт картинок на лету - это клиника. Тем более что ресайз делается в 3 варианта (стандартный и 2 маленьких, превьюшки под разные нужды). Ещё рассматривается возможность сохранения оригинала, но вопрос состоял ведь не в том как ресайзить, мне было интересно как лучше всё это чудо хранить.
оригинал по возможности следует сохранять обязательно (и никто не говорит что его надо отдавать наружу).
во первых ты можешь решить вдруг изменить размеры.
во вторых могут случиться баги при ресайзе.
как хранить - см. мой пост выше, главная суть что хранение и раздача это две большие разницы.
вообще вся задача делится на три части
1 загрузка
2 хранение
3 отдача
во первых ты можешь решить вдруг изменить размеры.
во вторых могут случиться баги при ресайзе.
как хранить - см. мой пост выше, главная суть что хранение и раздача это две большие разницы.
вообще вся задача делится на три части
1 загрузка
2 хранение
3 отдача
Alexandre
PHPПенсионер
делал подобное решение: файлообменник (нагрузка 150-200к хостов, файлы любого размера, около 1.2Гб не проблема ):
1) сервер отдачи статики, балансировщик
2) сервера отдачи контента (их было 3-5 шт)
3) сервера приема и загрузки контента (было 2 шт )
4) сервер БД
идет загрузка на определенные сервер отдачи...
данные сохраняются в БД
при запросе на отдачу контента, по БД определяется с кокого сервера необходимо произвести отдачу и идет перенаправление.
интересен алгоритм выбора сервера отдачи (или куда грузить контент):
- либо по странам, регионам
- либо рандомно
- либо по первой букве имени файла
1) сервер отдачи статики, балансировщик
2) сервера отдачи контента (их было 3-5 шт)
3) сервера приема и загрузки контента (было 2 шт )
4) сервер БД
идет загрузка на определенные сервер отдачи...
данные сохраняются в БД
при запросе на отдачу контента, по БД определяется с кокого сервера необходимо произвести отдачу и идет перенаправление.
интересен алгоритм выбора сервера отдачи (или куда грузить контент):
- либо по странам, регионам
- либо рандомно
- либо по первой букве имени файла