You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: samples/features/in-memory/ticket-reservations/README.md
+9-8Lines changed: 9 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,14 +50,15 @@ The demo is run in this [17-minute video explaining In-Memory OLTP](https://www.
50
50
51
51
11. Go back to the app and run the workload again. No need to recompile or restart the application.
52
52
53
-
The perf gains from In-Memory OLTP as shown by the load generation app depend on two factors:
54
-
- Hardware
55
-
- more cores => higher perf gain
56
-
- slower log IO => lower perf gain
57
-
- Configuration settings in the load generator
58
-
- more rows per transaction => higher perf gain
59
-
- more reads per write => lower perf gain
60
-
- default setting is 100 rows per transaction and 1 read per write
53
+
The perf gains from In-Memory OLTP as shown by the load generation app depend on two factors:\
54
+
55
+
- Hardware
56
+
- more cores => higher perf gain
57
+
- slower log IO => lower perf gain
58
+
- Configuration settings in the load generator
59
+
- more rows per transaction => higher perf gain
60
+
- more reads per write => lower perf gain
61
+
- default setting is 100 rows per transaction and 1 read per write
61
62
62
63
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:
63
64
`ALTER DATABASE CURRENT SET DELAYED_DURABILITY = FORCED`
0 commit comments