New Account Restrictions: Necessity not Spite

A few people are expressing slight unhappiness at not getting a new account. If you’re one of those we’d just like you to know that it’s from necessity not spite. Below is a graph of the CPU utilisation on the server. The red line is the CPU and the top of the graph is 100%.


The reason for the high utilisation is a problem we have with the database access software. If/when we can get it solved CPU utilisation is expected to drop to more like 40 or 50%. At that stage we’ll open up the system for new accounts again. In the meantime the trickle for new ones is the only way to keep the service available for anyone.

Yes we could use a bigger Amazon EC2 instance or spread the load to multiple instances but then the cost of running it starts to go above what is viable for a free service.


  1. Sri Sri’s avatar

    Why not accept donations or charge a nominal subscription fee?

    Of course fixing Database access software has to be addressed. Going with a larger hardware will temporarily solve the problem but you will hit capacity problems soon. Out of curiosity – is DLINQ the root cause for high CPU utilization?


    1. sipsorcery’s avatar

      Yes DbLinq is definitely the cause of the high CPU. Some quick and dirty testing has indicated that DbLinq requires at least 7 to 8 times the CPU resources for a simple select query compared to using hand crafted SQL.


    2. Esente’s avatar

      Have you ever taken a look at Erlang and Yaws? It’s a really efficient language on concurrency. I believe it can help you reduce the load on your server. It may have a steep learning curve if you’re not familiar with functional programming language, but with OOP background, it should not be too hard. It’s worth the effort learning.


    3. Esente’s avatar

      Oh, by the quay, Erlang has its own DBMS called Mnesia, written in Erlang itself. They come hand in hand.


    4. sipsorcery’s avatar

      Functional programming appeals to me and I have already found myself starting to pass around delegates in preference to objects in C#. In this case the server load is almost certainly down to DbLinq converting the Lambda expressions to SQL. DbLinq has a few bugs that prevent conversions being cached meaning every SQL select is incurring somewhere between 7 and 8 times more CPU than it would be for hand crafted SQL. That’s a big hit for a SIP Registrar which when you boil it down has the sole job of querying and updating the database. I’m in the process right now I’ve reverting a few high volume queries to hand crafted SQL. The DbLinq abstractions are an extremely elegant solution but for the time being we’ll need to pick and choose where the sipsorcery software can use them.



Your email address will not be published. Required fields are marked *