Autogrowth, shrink and database performance I have already asked some questions about Autogrowth and shrink. But I have some doubts related to it.

I have a database which grows about 300 MB every month. So is it best to set Autogrowth of 300 MB to it? Now 10 MB is set.

I have so many small databases which really have data of about 50 MB. But it's physical size is about 900 MB.(So 850 is free space). I have not shrunk this database. As if I shrink it then again when data gets added autogrowth occurs.  But adding data to this database is rare. So I think it will not grow more than 200MB for next one year.
So should I shrink the database? If I keep it as it is? Should that cause any performance problem? Or having more free space(more than 90%) in database will cause any problem? I think most of the people think having large physical size will cause performance problem. So is it true or not?

SQL Server 2008 R2 Express database size limit is 10 GB. So is it physical size of both mdf and ldf file together? Because I need to consider this if I should shrink database at any point.
Yes, picking an autogrowth size that makes sure you minimize or eliminate the number of growth events during your business cycle is ideal. I would venture to say that if 300 MB per month is that predictable, you should also - in addition to setting more reasonable autogrowth settings - to grow the file right now by 4 or 8 GB to allow for one or two years of growth without having to worry about interruptive growth events (even with instant file initialization, data file growths still cause transactions to wait while they complete). If you know you're going to grow by about 300 MB per month, why put off all those growth events? What are you going to do with the space in the meantime? Lease it out month-to-month?
You are probably fine shrinking that specific database to 200 MB. Be sure to do this with DBCC SHRINKFILE or ALTER DATABASE MODIFY FILE, not DBCC SHRINKDATABASE.
The Express limitation is on the data file only. You can have a 9.99 GB data file and a 600 GB log file, and SQL Server won't complain. Well, it will in other ways, but not due to exceeding any arbitrary file size limitation. That said, you should either make sure to be in simple recovery or back up your log at a reasonable rate. Log files should never be growing uncontrolled - and if you're worried about the log file on an Express instance, something isn't right. Please see the following posts for plenty of discussion:


SHRINKFILE best practices and experience
Sql Server - Best Practices for Growing Database Files
Why Does the Transaction Log Keep Growing or Run Out of Space?