Task #8
Track server load
| Status: | Closed | Start date: | 03/28/2012 | ||
|---|---|---|---|---|---|
| Priority: | Normal | Due date: | |||
| Assignee: | lee | % Done: | 90% | ||
| Category: | - | Estimated time: | 0.00 hour | ||
| Target version: | Alpha Testbed Launch v1 | Spent time: | - | ||
| Component: |
Description
Test how sound works and how the server responds to several people making encrypted calls over ostel at the same time.
History
#1 Updated by lee almost 6 years ago
- Status changed from New to In Progress
- Assignee set to lee
- % Done changed from 0 to 80
The current sound quality is as high as it will go. This has been confirmed on both ends. I set up some graphs that monitor server resources. In this case "server load" will be synonymous with "network I/O" since Freeswitch isn't doing anything complicated with CPU, disk or memory. The graphs are public and visible at https://ostel.me/stats/ select "network" to see current, min, max, average values.
#2 Updated by lee almost 6 years ago
I think the last 20% for this will be a bit of work. There is an open source package called CDR-stats http://www.cdr-stats.org/ that will give a report dashboard to see some graphs about the call load, including concurrent calls. There is an online demo of the report interface at http://demo.cdr-stats.org/ login with demo:demo
#3 Updated by n8fr8 almost 6 years ago
lee wrote:
The current sound quality is as high as it will go.
When you say "high as it will go", what do you mean exactly? I think our target is 16-32kbps in terms of quality, as we want reliable and low stutter, over high resolution.
#4 Updated by lee almost 6 years ago
Right now the security model requires us to trust each client and proxy the codec on the server. This means the client defaults are our defaults and they are high quality 64k in each direction, or 128k dual mono or ISDN quality. Compressed codecs will require the clients to agree on the codecs before an audio channel is created.
#5 Updated by lee almost 6 years ago
- % Done changed from 80 to 90
#6 Updated by n8fr8 almost 6 years ago
In order to close this ticket, i would like us to at least test four similtaneous calls occuring, to understand what that type of very reasomablr load lppls like.
#7 Updated by ex1st almost 6 years ago
I can do this today after installing it on a number of phones in the office.
Lee, can you send me credentials to do so?
N8, which phones would be best to use?
#8 Updated by n8fr8 almost 6 years ago
- Estimated time set to 0.00
the pile of phones on the left on the workbench are in the best shape. the gtablet should also work.
this should be an all hands test as well so recruit Hans, Harlo, Derek, Miron, David etc who should all be setup anyhow.
Brian Conley is also on now at x1011 I think. Bryan Nunez should be able to help.
#9 Updated by lee almost 6 years ago
Because of the architecture I choose for Freeswitch, the scarce resource is bandwidth. There is about 300mbits of sustained pipe in the single server, which will support thousands of concurrent calls. So a test of 4 concurrent calls (8 users) will only be a test of those 8 users internet connections.
There are some OS level issues I can think of that might effect Freeswitch at high network I/O, in particular open file handles will run out because the default is 1024 I think. Lemme up that configuration right now. As for CPU and Memory, there is very little going on during a call in CPU and RAM on Freeswitch since all the crypto and codecs happens on the clients.
#10 Updated by ex1st almost 6 years ago
So we're at about 2,343 concurrent calls with the settings we have. In theory.
We'll still have to test for bugs and call quality.
#11 Updated by n8fr8 almost 6 years ago
I also want to think about configuring the client to default to 16 or 32kbps. csip also supports the Skype silk codec
#12 Updated by lee almost 6 years ago
the default right now is 16khz but I set mine to favor 8khz speex and confirmed that it works at about 8kbps, I think that's as low as it'll go without getting crazy with some proprietary codecs. The iPhone default is 64kpbs G.722. Speex is not available on the iPhone.
#13 Updated by lee almost 6 years ago
- Status changed from In Progress to Resolved
okay, I'm officially logging caller detail records into a SQLite database. I've shut off the CSV logging. This was bizarrely more difficult than I expected due to some constraints in the freeswitch cdr_sqlite module that conflicted with constraints in the Asterisk CDR schema which is required for the dashboard application I'm working with. Database schema conflicts For The Lose. So I had to manually resolve the schema conflicts. And it works now.
Anyhoo, the data is flowing in so when I get Django + nginx configured to use it, we'll be able to see the dashboard with all call data from this point forward displayed in pretty graphs. I'm going to close this ticket since the performance data is being logged so we are "tracking server load". I'll open another one for "look at tracked server load" :)
#14 Updated by n8fr8 almost 6 years ago
- Status changed from Resolved to Closed
Good enough for jazz in this round. Closing this ticket out.
Let's plan to talk more about logging and performance tracking in future phases.