Как минимум, не забудьте при отправке картинок выдавать заголовок Last-Modified, что позволит использовать механизм кэширование клиентских браузеров и прокси-серверов. За счет чего можно заметно снизить трафик и загрузку сервера.

BlazkowiczПомоему HTTP сервер с этим сам чудесно справляется работая на прямую с файловой системой.
- да, если файлы берутся из файловой системы. Мой совет на тот случай если файлы будут браться напрямую из базы (как это сделано сейчас), возможно после отправки необходимых заголовков HTTP острота проблемы заметно снизится и можно будет обойтись без самодельного кэша, т. е. решить проблему "малой кровью".

branicki Kachalov возможно после отправки необходимых заголовков HTTP острота проблемы заметно снизится и можно будет обойтись без самодельного кэша, т. е. решить проблему "малой кровью".

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

- а зачем тогда Вы их вообще храните в БД?

branickiу меня приложение такого плана что большинство транзакций будет на чтение (я имею ввиду картинки) или лишь малая часть на запись. Поэтому и хочу сделать грамотный кеш чтобы базу не дергать при каждом запросе а выдавать изображения как статику.
NFS + RAID 1 - Вам помогут в вопросах скорсти чтения, надежности хранения данных и одновременного доступа нескольких нод! Не кладите картинки в базу, даже при относительно небольшой нагрузке сильно поедаются ресурсы, память стремится к нулю а загрузка процессора к 100%

branickiВообщем у меня в плане было как и сказал y3u ставить связку Apache HTTP c прицелом на контенер сервлетов.
- ну вот, начали про сервера приложений, а теперь они стали контейнерами сервлетов :(

branickiК Apache HTTP привинтить PHP и ...
- Вы еще про базу ничего не сказали. Часом не MySQL?

branickiтотже Томкат идет ведь в составе сервера приложений
- если речь идет о сервере приложений, то подразумевается использование технологии EJB, в идеологию которой хранение картинок в базе вполне вписывается, а если речь идет о "голом" контейнере сервлетов (сервлеты/JSP/JSF и т.п.), то это другой уровень решения проблемы производительности и соответственно другие способы решения этой проблемы, т. е. опять ставится под сомнение необходимость хранить картинки в базе :)

branickiпочему ирония? :-) MySQL позорно использовать в качестве БД когда заходит речь о серверах приложений и высоких материях а-ля кластеризация??? :-)))))
- проблема не в кластеризации, а в тех данных и объемах данных которые Вы собираетесь хранить в базе. Вот Вы писали что храните картинки в базе для "контроля целостности данных" (видимо имелась в виду обработка данных в рамках транзакций?), но транзакционный механизм в MySQL работает на таблицах типа InnoDB, которые заметно проигрывают по быстродействию и т. д. таблицам типа MyISAM, которые собственно и позволяют характеризовать MySQL как надежную и быструю БД, простую в обслуживании. Если Вы откажетесь от InnoDB в пользу MyISAM, то просто теряется единственный аргумент как-то оправдывающий хранение картинок в базе. В общем странновато выглядит описание задачи вместе с выбором продуктов. Дело конечно Ваше, но мне кажется что Вы сейчас роете себе яму из которой потом придется выбираться :(

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

при выкладывание около 600 000 файлов размеров до 30К каждый в файловую систему /webapp/my_root скорострельность под Томсат была никакой даже при относительно низкой загрузке - порядка 20-30 просмотров в минуту.

проблему удалось решить как раз засовыванием в базу.
- вообще то было бы неплохо добавить к такому сообщению более подробное описание системы:
ОС?

файловая система?

наличие RAID и его уровень?

тип выкладываемых файлов? статика? динамика?

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