You can tune LOB performance by specifying certain options in the Create table DDL for the table containing the LOB.
create table lob_data (id number not null, data lob)
LOB (data) STORE AS (
INDEX (TABLESPACE lob_indx)
DISABLE STORAGE IN ROW
CACHE READS NOLOGGING
STORAGE (INITIAL 5M NEXT 5M)
Here I've assigned separate tablespaces for the Lob and lob_index, and also specified the NOLOGGING option. Also specified the chunk size as 8k, and tuned the storage params.
EDIT - Based on comments from kubanczyk
Perhaps I should have elaborated a bit more, so here goes.
I assumed the question was specifically asked because the author was seeing performance problems with inserts for his dataset. So the default chunk size, the 'storage in row' were NOT giving him the performance he expected to begin with.
I agree that I should have warned about the NOLOGGING suggestion. But then again, I assumed that the author would research a bit more, before simply copy pasting my solution.
Usually BLOBs/CLOBs come from external sources, so the database is more often a storage space for them, but not the authoritative source. By that I mean that even with NOLOGGING turned on for the LOB, the assumption is that in case of data loss , the external sources can be re-processed and the data re-populated.
Again this is a application /design specific issue. If the data simply can't be regenerated in case of data loss, then NOLOGGING is out of the question. But to simply dismiss the 'NOLOGGING' option as careless is not knowing and weighing the pros/cons of ARCHIVELOG in my opinion.
As to the chunk size, the question said that the average blob size was 3K, and by that I assumed, that there were a good many BLOBs well over 3K. If the average is approaching the upper limit of the in-row storage (i.e. 4K), I think it is fair to assume that 'out of row' storage is going to give better performance. Also consider this, today the average might be 3K, what if an year from now the average is 5K, then you've bypassed the 4K limit, and you are really better off with the 'out of row' storage, and 8K chunk size, anticipating a future increase in data size.
So while it is very easy to down vote , I would still stand by my suggestions, given the fact that this is a performance related question and not a 'how to do XYZ ?' type of questions. Performance is a tricy thing, and you've to weigh in all the pros/cons of all the options you have. There is simply not a one solution fits all type of response you can give for performance related issues. You can suggest pointers, and it would be up to the original auther to see what best fits his setup.