Подкиньте идею для высоконагруженного сайта.

надо дропбокс с блекджеком и девками

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

Если идея годная, нужная людям, посещаемость будет большой :)

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

>Тут люди неглупые, у кого-то идеи время от времени промелькивают в голове. Я же могу реализовать.
Ты абсолютно уверен, что можешь осилить winfs в одиночку? А то я хочу мир во всем мире.. не поможешь реализовать?

Для начала хочу попробовать gridfs или подобную. У некоторых работает, чем я хуже? :)

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

А сервис твой конечно же никому не нужен, да и не напишешь ты ничего./thread

Siege няшнее. Сайт?.. Ну последний 90 страниц за секунду отдавать может (без кэшей).

А что до моих спосбностей - это не твоё дело же.

>Подкиньте идею для высоконагруженного сайта.

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

А что до моих спосбностей - это не твоё дело же.

Если не наше дело, тогда зачем вообще тут это писать? :) Сделай убийцу Фейсбука и GMail вместе взятых. Способности то твои позволяют.

Ты ничего не напишешь, не потому что не можешь, а потому что это никому не нужно, в том числе и тебе.

Есть еще другой аспект, хранение бинариев в БД - идея глупая и провальная изначально. Всякие NoSQL'и конечно дают шанс наступить на грабли тем кто на них еще не наступал, но идея глупая хотя бы из-за неминуймого оверхеда твоей БД и наличия лишних сущностей.

Siege няшнее

оно ничего кроме http не умеет LOL

ты мне еще про ab расскажи

хранение бинарной информации в БД и быстрая её отдача сотням клиентов одновременно

Это будет медленнее чем отдавать стаитику с локальной фс.

Идея в том чтобы затрахать сервак до смерти? Тогда водрузи оракел, выставь mem=64M, сделай своп на ssd и гоняй бенчмарки пока не подохнет.

А мы будем благодарны за ресурсные испытания ssd.

Подумай на досуге, зачем появился sendfile, а также насчет HTTP_RANGE.

порнолаб 2.0

>хранение бинарной информации в БД и быстрая её отдача сотням клиентов одновременно = это круто.

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

PS: дайте угадаю... ТС наверное изучил SQL в рамках какой-то СУБД и теперь захотелось что-то сваять :). ага? ;)

глупая идея, плохо будет

> Мне без разницы что писать, просто хочу большую нагрузку.

фильмы и видео, раздаваемые по http, и без рекламы. Сервер повалят сразу :-)

Сделай хостинг для любительских огромных панорамных фотографий. Тут тебе и нагрузки, и фоновая обработка (большие панорамы, кстати, хранятся в довольно интересном формате) и быстрая отдача сотням клиентов. Правда, не думаю что у тебя получится оптимально хранить файлы в БД. Но идея хорошая и инновационная.

Если честно, не думаю что у тебя вообще что-нибудь получится :)

Что-то мне припомнилось, как один человек игру писал.

Запили сверхскоростную флибусту

>Если не наше дело, тогда зачем вообще тут это писать? :) Сделай убийцу Фейсбука и GMail вместе взятых. Способности то твои позволяют.

Позволяют. За n месяцев, если нет лет. Ясен пень, я возьмусь только за то, что могу доделать. Закроем этот вопрос.

>Есть еще другой аспект, хранение бинариев в БД - идея глупая и провальная изначально. Всякие NoSQL'и конечно дают шанс наступить на грабли тем кто на них еще не наступал, но идея глупая хотя бы из-за неминуймого оверхеда твоей БД и наличия лишних сущностей.

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

Да, я видел сравнение sendfile и схемы с БД. Второй вариант дичайше тормозит, но авторы уверены что при наличии ~10 серваков некоторый контент будет отдаваться в разы быстрее.

Лично я пока не имел возможности проверить, но мне хочется наступить на свои грабли чтобы в будущем не наступать на них. А с другой стороны, вернуть всё на обычный senfdile всегда успеется.

Опыт, други.

Спасибо :)

> gridfs

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

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

а сама бд не на фс значит лежит? и что сами файлы бд могут сами фрагментируется тебя не смущает.

ты хоть тест какой-нибудь посмотри что ли сколько I/O операций нужно сделать, что бы прочитать файл с фс и сколько нужно этих же операций что бы достать бинарный кусок из бд аналогичного размера.

теоретик в вакууме, вообщем.

А вообще идея хранить файлы в БД возникла не из за проблем с производительностью, а из сооброжения удобства - нахаляву вместе с БД для файлов зарабатает шардинг и бэкапы, быстрый поиск по атрибутам, единообразность и т.д. В смысле производительности - БД это, безусловно, прослойка поверах ФС и причины роста производительности не ясны. Особенно учитывая что в современных ФС индексы файловых имен теперь хранится в В-дереве, а значит даже нет проблем с кучей файлов в одной директории.

БД? Highload?

Не по пути

Существование функции sendfile делает гигантскую разницу между отдачей данных с ФС и БД, которая используется как ФС. Часто за абстрациями БД эта функция перестает работать непосредственно из диска в сокет, посему имеем тормоза. Лучше использовать или ФС или специализированое решение, которое следит чтобы блобы отправлялись в сокет эффективно.

Исследуйте или это - http://www.mongodb.org/display/DOCS/GridFS

Или используете распределенную ФС аля Hadoop, что позволит масштабировать ФС в будущем

Обычно идея проекта опирается на возможности девелоперов, которые либо могут, либо не могут построить его так, чтобы опеспечить его функционирование при высоких нагрузках. А возможности девелоперов опираются на известные им платформы и solution stacks.
Всё это вместе и решает, сможет проект быть высоконагруженным или будет падать от первого же лор-эффекта.

> С слышал что фотографам нужен сервис для ресайза фоток и экспорта их в разные соц. сети. Надо?
Пили. Надо.
Сам не фотограф.

> использование БД в качестве ФС

Хотите скрестить ужа с ежом? Скажу по секрету вы не первый и наверное, не последний, кто пытается получить этот мертворожденный труп.

(Знаю людей которые хотели сделать такое под Windows + MSSQL)

хранение бинарной информации в БД и быстрая её отдача сотням клиентов одновременно = это будет круто тормозить

Предлагаю такую схему: балансировщик нагрузки + фоновая обработка данных + параллельная ФС (Lustre FS, GlusterFS)

>Предлагаю такую схему: балансировщик нагрузки + фоновая обработка данных + параллельная ФС (Lustre FS, GlusterFS)

Если многие говорят, буду начинать с них. Спасибо!

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

понятно, кэши и io ещё не проходили. или прогуливал? )

Проходили. И читали исследования парней, который эту ФС пилят. Я им доверяю, чо уж.

>За n месяцев

Убийцу флибусты и гмыла? Губозакаточную машинку куда выслать?

>Обычно идея проекта опирается на возможности девелоперов

Ну конечно. Если возможностей девелоперов не хватает берут новых, вот и все.