Provisioning RavenDB instance on Amazon EC2

[Neil Duncan]

I'm new to EC2, and getting bewildered by the options available.

Has anyone got any best practices for how I should be setting this up to run as a RavenDB server?

I'm assuming the things that are important are Memory (indexing and caching), Processor (indexing), and IOPS.

Do I need to worry about a separate EBS Volume for data, or rely on the root one that comes with the instance? 

Thanks,

Neil

[Kijana Woodard]

I would say getting the high iops instance is most important followed by memory. I think you want data on ebs for other reasons like portability, but afaik, that's the aws recommendation.

--
You received this message because you are subscribed to the Google Groups "ravendb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Chris Marisic]

Don't expect stellar performance on any cloud provisioned server. RavenDB performs best with SSDs and almost no cloud data storage can provide that type of IO.

[Kijana Woodard]

Yeah. Azure says the newer disks are all SSDs, but I'm experiencing quite degraded performance. RAM has been my friend for reads,but writes are pretty slow. I don't have a good way to quantify my experience without a Raven Score. ;-)

[Jeremiah Barndt]

Just to kind of bump this thread a bit, but I'm in a similar situation. I've already provisioned some test servers that are currently m1.large standard instances with standard EBS storage (not provisioned IOPS/"optimized EBS" servers which are apparently a lot faster). Does anyone have any idea at what kind of load you would need for the standard storage to start showing its limitations? I've read that standard EBS storage throughput can be rather unpredictable so was wondering if anyone had some actual experience with this that could chime in.

In addition, the recommended configuration for RavenDB in the docs mentions quad core processors. The m1.large instance actually only has two "cores" visible to the OS and I'm wondering as well what kind of throughput I would need on Raven to actually "need" four cores.

Thanks!

[Jahmai Lay]

I read this also, but digging deeper it appears that only the journals sit on SSD and not the bulk storage.

http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx

[Khalid Abuhakmeh]

I like the Idea of a Raven Score, kind of like a Windows Score. It would be cool if that was built into Raven 3.0, somewhere in the Stats section.

On Wednesday, May 22, 2013 11:14:45 AM UTC-4, Kijana Woodard wrote:

[mike....@microgroove.com]

I'm surprised there weren't more follow ups to your post Neil, so here's some notes I made a few months ago while testing different EBS volume set ups. I can't point you to any best practice docs, but I can recommend using the EBS optimized instance types that have high network IO and at least two EBS volume in RAID 0 for your data. 

I settled on m1.large (7.5GB ram, 2 cores) with 2x80GB (each @ 500 IOPS) as 1 striped volume in Windows. Striping two 500 IOPS volumes performed better than one 1000 IOPS volume. Anything over 1000 IOPS made no difference as I think the limiting factor was the IO of the EC2 instance type.

Test - import 1.4 million large docs, 23 indexes using the silverlight studio UI running in a browser on the localhost (before I knew about smuggler or any other way to load test).

Instance Type: 

m1.xlarge

15 GiB memory

8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)

1,690 GB instance storage

64-bit platform

I/O Performance: High

EBS-Optimized Available: 1000 Mbps

AMI

ami-bc79f18c

EBS backed Microsoft Windows Server 2008 R2 SP1 Datacenter 64-bit English with SQL 2012 Express AMI provided by Amazon

C: 30 GB

RavenDB build 2330

EBS test configurations

2 x 200GB (each 2000 IOPS) 2 volumes (data on vol 1, indexes on vol 2)

1st time, IO exception at 416K docs

2nd time, IO exception at 631K docs

1 x 200GB (2000 IOPS) volume

1st time, IO exception at 926K docs (53 minutes)

2nd time, IO exception at 757K docs (46 minutes)

2 x 100GB (each at 500 IOPS) as 1 striped volume

Raven/Esent/MaxVerPages 2048

completed, 90 mins

2 x 100GB (each at 1000 IOPS) as 1 striped volume

Raven/Esent/MaxVerPages 2048

completed, 90 mins

4 x 200GB (each 2000 IOPS) as 1 striped volume

Raven/Esent/MaxVerPages 2048

completed, 75 minutes

[Khalid Abuhakmeh]

Hello Mike,

What does a setup like that cost you a month? (if you don't mind me asking).

[mike....@microgroove.com]

Hi Khalid,

I don't mind at all. The current cost for 1x m1.large w/ 2x80GB (each @ 500 IOPS) is:

On demand: $401.55 mo

  break down:

    Compute: $284.75

    EBS VOlumes: $20

    EBS IOPS: $100

OR

1 yr light reserved: $276.00 up front, $307.12 mo

OR

1 yr medium reserved: $640.00 up front, $263.20 mo

OR

1 yr heavy reserved: $780.00 up front, $241.24 mo

OR

3 yr light reserved: $425.20.00 up front, $284.43 mo

OR

3 yr medium reserved: $1000.00 up front, $249.30 mo

OR

3 yr heavy reserved: $1200.00 up front, $231.73 mo

EC2 is expensive. I would prefer to use RavenHQ, and did for a while, but I need more control of the RavenDB service these days because my indexes are misbehaving.

[Mircea Chirea]

Azure? I think it's cheaper than EC2. I'm not sure about the storage performance though.

[Kijana Woodard]

Not good and not easy to tune.

[Khalid Abuhakmeh]

Hi Mike,

Thanks for sharing. That isn't too bad in terms of pricing, but could be seen as expensive for a bootstrap start-up. I just wish SSD was the standard moving forward, but I guess it is super hard to get the capacity offered by Platter drives. Thanks for sharing again and good luck.

- Khalid