Load testing and the real reason you need Charles in your repertoire.

We’ll consider three slightly more advanced uses of Charles Proxy here. But all of them share something in common: They allow you to understand how your app will perform under load, and in an enterprise environment. That’s the real reason you need Charles: To make a faster app for your customers.

Charles Proxy intercepts requests on their way to the server and responses on their way from the server back to your app.

It allows you to inspect and even change these requests or responses. You can therefore

• change the size of the data.

• test your server’s response to invalid or malicious data.

• change the latency of the response from the server to mimic bad connections in a way that gives you far more control than the developer settings on the iPad.

• change the bandwidth  by throttling the data to any number of bytes. This is a powerful way to mimic what happens as the number of users of your server starts to grow.

• and you can even set up repeated requests based on actual requests. This is another powerful way to measure your server response as you increase the load. And though there are plenty of specialty tools to measure load on a server, Charles is one of the most accessible for the iOS developer.

Understanding and testing these items is more than just playing with Charles. (Though it IS fun!) It’s crucial to moving your app to enterprise-level functionality and moving your career to enterprise level worthiness.

We’ll consider the last three in the list:

1. Throttling. Go to the Charles Proxy menu and select Throttle Settings. Check ‘Enable Throttling.’ You will optionally want to throttle ‘Only for selected hosts’ because you may have other work going on in the background from your iPad or iPhone. So check that too, and then click the ‘Add’ button to add your specific host. In my case, as before I’m sending requests  to my bestart blob in azure. I’ll enter the top level domain for that host. I’ll enter https for the protocol and a wildcard for the port, because I don’t know it. Then you can set the bandwidth. Start with something easy that you know will succeed. Then decrease the bandwidth and watch your server response duration by selecting ‘Sequence’ and filtering again for your domain. In my case, simply selecting 3G doubled all my response times.

2. In the same modal — the Throttling modal — you can change the minumum latency. Part of the reason for doing this is to ensure that background tasks you may be starting are still completing in the app, even when the data is arriving later than expected. And even moreso: You should be testing that tasks that return data late are being handled gracefully if the user leaves the controller that requested the data in the first place. I simply increase the ‘Round-trip latency (ms)’ value to 500 — half a second — and could see my request durations go up further. But the app continued to perform. For Bestart, downloaded art is added to a linked list. Art is displayed from that list in a loop so that newly requested art is only displayed once the data is inserted into the linked list.

3. Repeated requests are easily created. And this is an excellent way to mimic what happens in real life even though as a dev, you seldom work with more than one or two devices simultaneously. Repeated requests are a way to mimic tens or hundreds of devices all making requests of your service at almost the same time or even simultaneously. The best way to set this up is to select a request from the tree in the ‘Structure’ tab on the left side. Right click on a request and you can then set up a repeat of that specific request. After right-clicking, select ‘Advanced Repeat.’ The rest of the settings are obvious: Choose the number of iterations. Choose whether the requests are concurrent or now. And optionally change the delay between requests. Can you bombard the server enough to make it come down? Or send an exception? That is your first goal. The second is: Can you bombard the server enough to cause the response to fail entirely on the iOS side? Can you lose the connection? Can you crash the app?