Lab 16 Observations

[pstueck]

Module: 8 – Implement a data modeling and partitioning strategy for Azure Cosmos DB for NoSQL

Lab/Demo: 16 – Measure performance for customer entities

Task: Prepare your development environment

Using student account resp. student-VM.

Generally (and not just this lab) … consider making the data loads more “free tier” friendly.
Otherwise a test/free/demo account would burn thru the given credit (USD 200.- at the time of writing) in no time.

e.g. setting up each container – slowly – with a small bunch of items (5 to 10) in the first attempt and only after this scaling everything up. This should everybody give enough insight what it is about.

Step: 7

The auto-typer does not send a CRLF after the last line (dotnet run --load-data). So if you indeed – as suggested – take a break, you are in for a surprise (as in … coming back and still most of the work to do).

Also loading the data usually fails.
As far as I remember, I ran this lab two to four times … and every single time there has been an issue with the setup of the database and containers.
I got “unavailable due to demand”, “request timed out” … and those are that I can remember.
That said … it would be helpful for the data loader to be able to continue wherever it ran into an issue.
And I am quite sure that at least once already the initialization script init.sh failed.

[MScalopez]

Observation 1: I tested this lab, and the free account should have enough credit to complete this lab by itself. Note that our labs are designed to be run independently of each other, so while this lab might be related to a previous lab, the amount of credit given per lab should allow you to complete each lab by itself. If there is a need to run multiple labs at once, perhaps to not repeat some similar steps between labs, we recommend you bring your own subscription and that way not be limited by the credit provided.

Observation 2: Great suggestion, I have added a comment at the end of the bash load script, if anyone forgets to do a CRLF after the last like, its ok, since it's just a comment and the load script would have run as expected. As for the failure because of available demand, I will research a way we could improve the load script for a future version of the lab, unluckily we are limited by the actual zone the resource group was automatically created for the free account. A retry logic might work, but we might need to rewrite the whole upload script. I have added this comment to the improvement list for our refresh of the actual course itself later during the year.

[WigF1]

@MScalopez When this lab or lab 17 fails with a 429, what are students meant to do? Delete the account and run the whole thing again?

[MScalopez]

@WigF1, good question, as you know a 429 means that the request rate is too large (e.g. too many requests in a short period of time). If you look at the azuredeploy.json file, you will see we set the RUs to 4000.

• My first question is, does this happen often? I just asked because I had run this lab dozens of times and never had a 429, but since you see dozens or hundreds of students you might see it regularly.
• We could push line 21, "defaultValue": 4000, to 8000 or 10000 before they run the init.sh script. I can do it on the repo, but must make sure that I don't eat up the learner's account's budget too soon (so I got to test it).
• Or we could change the line 769 on both lab 16 and lab 17 of the Program.cs file to a smaller number like 1000, but that might make the load even slower: int maxDegreeOfParallelismPerWorker = 1500;
• Second I assume that you are just worried about this happening when the init.sh file is running and dying, right?

Please let me know your observations on these questions, so we can determine which is the better solution to this problem.