What are the restrictions?

Discussion in 'Questions about Everleap' started by Rob den Boer, Mar 20, 2015.

  1. Hey Guys

    My trial period is running well so far, but I have been thinking ahead to possible expansion and loading.

    Your 'Reserved Cloud Servers' marketing states:

    Reserved Cloud Servers have no constraints on idle time out, CPU limit or concurrent connections! All of your sites in this account will run on the Reserved Cloud Server.

    However I cannot find details on what the constraints are for shared servers.

    Mines not a web site, but a back end rest service. I'm trying to simulate approx traffic and looking at CPU times (25 ms per hour under load currently) and wondering at what point I would notice CPU limiting and what is the maximum connections etc.

    Also, if you get a multiple site package do they all share the same SQL server? Is it possible to have more then 1 SQL server to have some form of manual mirroring. ( writing to both and reading from 'a' , failing over to reading from 'b')


  2. Takeshi

    Takeshi Everleap staff

    In general if you notice general performance issues that would be a sign that you may need to scale your site. There are different ways to scale so you can contact us and we'll review your site activity and make recommendations.

    On the Shared Cloud Servers the idle timeout is set to 30 min. If this is causing an issue with your app, then Reserved Cloud Servers will help alleviate that.

    On the Shared Cloud Servers there is a constraint on the app pool memory allocation which you can increased with the Power Pack or by moving to a Reserved cloud server. You can monitor your memory usage in the control panel.

    Because its a cloud system, there is no set percentage of CPU usage or number of connections. The constraints are more along the lines of an algorithm. If you are seeing high CPU usage in the control panel stats or performance issues, you can contact us and we'll review your site activity and make recommendations.

    As for your SQL question - we cannot guarantee which server the SQL database will be created on. Please contact us about your account and we can look into this.
  3. Thanks.. I know this is an old thread.. but I have just gone live a month or so ago and I am adding customers slowly , so I am watching the resources.
    My site is used as an API, so no interface, just REST interfaces and allot of SQL queries.

    What is considered high CPU usage in the control panel?

    How do I know if I am creating too much traffic on the shared SQL box?

    I am looking at adding another API which uses SQL Queues. Client apps will be waiting and timing out looking for data. ( rather than polling really fast).
    I have tested this and it's working fine, but I am uncertain of what load this will put on the shared SQL server and if it was acceptable.

    I have just started 1 client to see what affect this has on performance.. but I guess I cannot see whats happening on the SQL side of things in the dash.

    Any recommendations appreciated. ( Obviously if I get enough users I will add power packs and dedicated SQL, but I am trying to work out what I can get away with without the added cost to start with!)


  4. Unfortunately, you are not able to see gather those statistics. The load is based on what his query does. This load is usually attributed to database locks or a nonoptimized database design
  5. Well in this case it would be using Service Broker and a bunch of Queues ( say 40) and there would be 1 query at a time to each queue which is waiting for something to be populated. ( so with 40 queues there could be 40 waiting queries)

    So the query is just a waitfor - receive ...from a Queue ( with a timeout of 20 secs ) So there is no database design, Queues are fixed with the table definition etc.

    I am not certain of the impact / load these waitfor receives will have on your shared SQL box and I don't really want to release this as a solution and have you guys shut me down for having a detrimental affect on one of your SQL boxes!

    I imagine there will be some load ( but from my experience these types of queries add little CPU for SQL) but perhaps I may get limited on the number of active connections to the SQL box? ( or some other limitation I may hit)

    I was thinking I can create 50 queues on one of your dB servers and test this to see what happens with 50 separate clients sending requests.. but of course I cannot tell from my Status board whats happening.

    Can you suggest anything proactive , or do I just do this and see what happens?


Share This Page