Dear Wiki user, You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.
The "Performance" page has been changed by RobertNewson: http://wiki.apache.org/couchdb/Performance?action=diff&rev1=17&rev2=18 Many of the individual wiki pages mention performance when describing how to do things. It is worthwhile refreshing your memory by revisiting them. = DELETE operation = + When you delete a document the database will create a new revision which contains the _id and _rev fields as well as a deleted flag. This revision will remain even after a [[Compaction#Database_Compaction|database compaction]] so that the deletion can be replicated. + Deleted documents, like non-deleted documents, can affect view build times, PUT and DELETE requests time and size of database on disk, since they increase the size of the B+Tree's. You can see the number of deleted documents in [[HTTP_database_API#Database_Information|database information]]. If your use case creates lots of deleted documents (for example, if you are storing short-term data like logfile entries, message queues, etc), you might want to periodically switch to a new database and delete the old one (once the entries in it have all expired). - When you delete a document the database will create new revision of it which contains _id, _rev, _deleted fields. This revision will be stayed even after a [[Compaction#Database_Compaction|database compaction]]. The reason of it to ensure that deletion of document will be replicated to other databases. - Such documents will affect on views calculation time, PUT and DELETE requests time and size of database on disk. If you use CouchDB for sessions for example (which is not recommended), you will find that after a few millions of deleted document the database may start working much slower. In this case you may regular recreate database to fix this. If you really need database for documents with short period of life, we recommend to use another NoSQL solution. - - You also may be interested in [[Purge_Documents|purging deleted documents]] but we recommend this is only for information because this solution have much more side effects than advantages. = File size = The smaller your file size, the less I/O operations there will be, the more of the file can be cached by CouchDB and the operating system, the quicker it is to replicate, backup etc. Consequently you should carefully examine the data you are storing. For example it would be silly to use keys that are hundreds of characters long, but your program would be hard to maintain if you only used single character keys. Carefully consider data that is duplicated by putting it in views.
