15

I am playing with the idea of using RavenDB as the data store for an application that will most likely have an HTML UI, a WebService UI, and server utilities that will access the data as well. One reason for using RavenDB is the horizontal scaling it offers through replication and sharding. However, it seems like there are several considerations around running Raven as a windows service or running it through IIS.

  • Security - Is the Raven service more secure or will using IIS allow me more flexibility to restrict by IP address, .NET Membership, etc.
  • Caching - It seems like IIS is the better choice for this feature
  • Architecture - Since I would not want any third party to access the data store would it really make sense to expose Raven through IIS. Also, there would be a business layer between Raven and the various UI's and utilities, so involving IIS seems unnecessary and may introduce unneeded complexity.
  • Performance - The IIS pipeline probably has more overhead on each request than a windows service
  • Scaling - Using IIS is probably more complicated to scale out across multiple servers as opposed to just installing the Raven service with a small batch file

EDITED

I can understand using Raven's Embedded configuration if all you have is a single web client but when you have several different clients, Raven's API needs to be exposed independently to prevent a single client from locking the data files.

jedatu
  • 4,053
  • 6
  • 48
  • 60

2 Answers2

16

Jedatu, We generally host RavenDB inside IIS, it makes some things easier, in particular, management of the server is easier when IIS is taking care of all the activation, etc. We haven't seen any meaningful perf difference, and IIS has nicer options for fine grained management.

Ayende Rahien
  • 22,925
  • 1
  • 36
  • 41
5

Security - Is the Raven service more secure or will using IIS allow me more flexibility to restrict by IP address, .NET Membership, etc.

Using a separate process is more secure.

Caching - It seems like IIS is the better choice for this feature

DB caching (caching entity documents) is not the same as IIS caching (which caches generated pages or parts of pages)

Architecture - Since I would not want any third party to access the data store would it really make sense to expose Raven through IIS. Also, there would be a business layer between Raven and the various UI's and utilities, so involving IIS seems unnecessary and may introduce unneeded complexity.

Anyone accessing the Data folder can open it with raven. Doesn't matter where it's located unless you protect it using windows security features.

Performance - IIS probably has more overhead than the windows service

Are you referring to a cold start? Using embedded Raven removes the HTTP requests between the client and the server.

Scaling - Using IIS is probably more complicated to scale out across multiple servers as opposed to just installing the Raven service with a small batch file

Multiple servers needs a separate Raven instance that all IIS:es can talk with.

jgauffin
  • 99,844
  • 45
  • 235
  • 372
  • This is helpful information, however I can't tell which option are you recommending for this scenario? – jedatu Dec 29 '11 at 22:18
  • I'm just saying that your considerations are not really valid. I would go for a service if I could. Seems more robust and scales better. Having it's own dedicated memory helps too, the IIS app pool can't f*ck it up. – jgauffin Dec 29 '11 at 22:24
  • Ayende has always said IIS server > windows service, with regards to RavenDb. – Pure.Krome Dec 30 '11 at 00:05
  • @Pure.Krome do you happen to have link where Ayende comments on the issue? I can't seem to find anything. – jedatu Dec 30 '11 at 05:13