SharePoint Products and Technologies support large lists. However, you must carefully control how end-users view the lists to help prevent adverse effects on performance.

• For best performance, do not exceed 2,000 items in a list level (for example, the root of the list or a single folder).
• If you must create and browse large lists, use the following best practices:
• Index the list on one or more columns.
• Change the default view of the list to a customized filtered view that follows these recommendations
  • The view returns fewer than 5,000 items
  • The first column that you use to filter the view has an index and that it sufficiently reduces the total number of items returned.
  • The view displays only those columns that are absolutely required.
  • The view includes as few lookup columns as possible. Each lookup column in a list that is included in a view causes an additional join and additional calls to the database.
• Evaluate list size with regard to the number of columns in a list. Lists with lots of columns can perform slowly.

Be aware that the following settings and operations can significantly affect the performance of a site that has large lists.

• Complex explicit permissions (permissions on the list or library, folder, or item or document level) force authorization checking on each item.
• Changing authorization settings.
• Creating, updating, and deleting indexes.
• Importing and exporting content.
• Deleting a list.
• Deploying new content types or updating existing content types.
• If you have workflows that generate lots of task and history items, you might be creating large lists. For very active workflows, follow these practices:
• Keep the AutoCleanupDays timer job running to clean up tasks on completed workflows older than 60 days.
• When you create workflow associations, if you expect that a workflow will be heavily used or will create lots of task and history items, use non-default task and history lists.

Please be aware that if you have a site that uses large lists, it can slow down the performance of site collection backups performed with the Stsadm backup operations.

More info http://technet.microsoft.com/en-us/magazine/2009.08.insidesharepoint.aspx

Binary Large Objects

The main function of the BlobCache is to cache large objects from the database to the web front-ends and eliminate the need for database round trips thus improving performance. The objects are retrieved from the database once and stored in the local cache. Further requests are served from the cache and trimmed based on security. The configuration includes

• specify which extensions or objects which you wish to trap like image, sound, video files, code fragments etc.
• a local folder to drop the cached files on the WFEs
• an expiration (in seconds)
• whether to enable it or not. 

Example

<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" max-age="86400" enabled="false"/>

Now BlobCache also has a secondary function which is to send "better" Http Headers to clients so that they can also cache the files along the way.  Basically what it means is that it will send a "Cache-Control: public, max-age=86400" to the browser and by having it public, it means that anything along the way (proxies etc.) can cache it.  The 86400 is the default value for max-age and it means that the file will expire in 1 day.

Here's something which you can try for BlobCache issues (these are very basic troubleshooting steps)

• flushing it through the GUI (Site Settings - Site Collection Object Cache - Force flush on this server). Note that if you have multiple zones (i.e. you extend a web application) then each of them has its own BlobCache folder. It also means that the "Force flush" only works for the zone that you are pointing to in the URL. Also if you have multiple web front ends, each server holds its own copy of the the disk based cache.
• Deleting the files manually on disk, 'C:\BlobCache' (by default) folder.
• Perform an IISreset.

Detailed information about BlobCache is available here