From dc0494caaf4605f52d7fa465ae04062b6275955b Mon Sep 17 00:00:00 2001 From: Jos de Bruijn Date: Wed, 20 Dec 2017 13:56:24 -0800 Subject: [PATCH] updated formatting --- .../in-memory/ticket-reservations/README.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/samples/features/in-memory/ticket-reservations/README.md b/samples/features/in-memory/ticket-reservations/README.md index 07ce2c4c..03200667 100644 --- a/samples/features/in-memory/ticket-reservations/README.md +++ b/samples/features/in-memory/ticket-reservations/README.md @@ -50,14 +50,15 @@ The demo is run in this [17-minute video explaining In-Memory OLTP](https://www. 11. Go back to the app and run the workload again. No need to recompile or restart the application. -The perf gains from In-Memory OLTP as shown by the load generation app depend on two factors: -- Hardware - - more cores => higher perf gain - - slower log IO => lower perf gain -- Configuration settings in the load generator - - more rows per transaction => higher perf gain - - more reads per write => lower perf gain - - default setting is 100 rows per transaction and 1 read per write +The perf gains from In-Memory OLTP as shown by the load generation app depend on two factors:\ + +- Hardware + - more cores => higher perf gain + - slower log IO => lower perf gain +- Configuration settings in the load generator + - more rows per transaction => higher perf gain + - more reads per write => lower perf gain + - default setting is 100 rows per transaction and 1 read per write If the performance profile after migration to In-Memory OLTP looks choppy, it is likely that log IO is the bottleneck. This can be mitigated by using [delayed durability] (https://msdn.microsoft.com/en-us/library/dn449490.aspx). This is enabled by running the following statement in the database: `ALTER DATABASE CURRENT SET DELAYED_DURABILITY = FORCED`