Ian Bennett

My feedback

  1. 37 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  API Management » Policies  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett supported this idea  · 
  2. 122 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  4 comments  ·  API Management » Security  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett supported this idea  · 
  3. 44 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  4 comments  ·  API Management » Pricing  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett commented  · 

    @Andrew, OAuth is fine if you don't want to provide any user functionality such as per API security, self-service, per user monitoring etc. To do that, you have to either pay a fortune or get your internal users to sign up with personal microsoft accounts which is a bit tacky.

    Ian Bennett shared this idea  · 
  4. 3 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Azure IoT  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett supported this idea  · 
  5. 46 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Azure Cosmos DB » SQL API  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett commented  · 

    In regards to the Lambda Architecture, that is sort of what I have done but more simply and cheaper by just creating a second Cosmos collection with a TTL setting of a few days only. I write to this and the long term collection simultaneously. Using database level RU allocation I can efficiently utilise RU between the short term collection which is mainly queried adhoc during the day and the long term collection which is mainly queried in batch overnight.

    Ian Bennett commented  · 

    My partition keys are GUIDs in order to evenly distribute eclectic data over the partitions. I therefore do not know the keys upfront and "DISTINCT partitionKey" is of no use.

    Ian Bennett commented  · 

    Also, it looks like the node.js SDK does not support passing of partition keys when executing a stored procedure.

    Ian Bennett shared this idea  · 
  6. 86 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    13 comments  ·  Web Apps  ·  Flag idea as inappropriate…  ·  Admin →

    Hi Ibrahim,

    What issue are you trying to solve? What use case would this be used for?

    It seems to me that placing a restart option on the plan level might do more harm than good, by resetting the memory on all the apps under the plan. Depending on your scenario, auto-heal would be a great solution to solve individual machine issues. See a video by my colleagues here for more details: https://channel9.msdn.com/Series/Windows-Azure-Web-Sites-Tutorials/Auto-Healing-an-Azure-App-Service

    Placing this idea under review for now until I understand what’s at the base of the request here.

    Thanks!
    Oded

    Ian Bennett supported this idea  · 
    Ian Bennett commented  · 

    There are some services that appear to be App Service Plan based and if broken, cannot be resolved by restarting at the App Service level. For example, MSI (Identity) which was apparently a VM plugin (there appears to have been major changes to MSI so not sure if this is still the case). Also I am having problems with Always On across all of my App Services (i.e. it has stopped working) so I suspect this may be another case.

  7. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Logic Apps » Management  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett commented  · 

    Agree that there needs to be some way to organise related Logic Apps. I have to use 3 Logic Apps just for overnight scheduling of lights at one site (1 to turn lights on, 1 to dim at a later time, 1 to turn off). If I am to roll this out in ernest I would likely end up with thousands of Logic Apps which will be a nightmare to manage, so am having to look at other solutions.

    Ian Bennett supported this idea  · 
  8. 2 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Azure Time Series Insights » General  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett shared this idea  · 
  9. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Web Apps  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett shared this idea  · 
  10. 1 vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Azure Active Directory » Licensing  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett shared this idea  · 
  11. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Web Apps » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett shared this idea  · 
  12. 7,254 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    193 comments  ·  Web Apps  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett supported this idea  · 
  13. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Web Apps » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett shared this idea  · 
  14. 614 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    28 comments  ·  Azure Cosmos DB » Gremlin API  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett supported this idea  · 
  15. 2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Azure Cosmos DB » Other  ·  Flag idea as inappropriate…  ·  Admin →

    @Ian.

    With regards to secondary regions having different RU/s we do not have this on our road map at this time. There is another User Voice items which have this suggestion, Please feel free to vote that item up.

    @Nick.

    For scenario 1. Same answer.

    For scenario 2. Typically, just putting the front-end closer to users is not something we see help with application latency where they are backed by a database as the app still needs to call the database which is still separated by some distance.

    With regards to knowing which region to point to I would suggest conducting tests to see which regions provide the best latency and include this as the preferred regions for each regional deployment.

    Thank you both for your suggestion and comments.

    Ian Bennett commented  · 

    The replica is setup more for DR purposes but there is no option to run the secondary at reduced RUs so that is potentially a lot of wasted resource and money. If I am using something like Power BI Service then I don't get a lot of say in where the application runs from. You are assuming a 3 Tier Architecture but Cosmos is not just being used for apps and websites. Data Analytics applications are often 2 Tier and more taxing on the database.

    Ian Bennett shared this idea  · 
  16. 14 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Azure Cosmos DB » Portal  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett commented  · 

    By "monitor" I mean individual queries and the focus on this suggestion was actually meant to be on the "killing" part. Its not hard to end up with rogue queries chewing up the RUs.

    Ian Bennett shared this idea  · 
  17. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Storage » Storage Explorer  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett shared this idea  · 
  18. 22 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Logic Apps » Connectors  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett commented  · 

    A trigger based on "Number of requests exceeded capacity" metric would be useful too. Logic flow might look something like if number of requests exceeds capacity > n then increase RU throughput by 10% with a maximum of x RUs.

    Ian Bennett shared this idea  · 
  19. 1 vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Azure IoT  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett shared this idea  · 
  20. 1,498 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    57 comments  ·  Azure Cosmos DB » Management  ·  Flag idea as inappropriate…  ·  Admin →
    Ian Bennett commented  · 

    For partitioned collections it would be good if autoscale would work on a per partition basis to keep costs down. RU allocation across every partition can be inefficient as in the following examples.

    1. RU allocation applies to all replicas. Using node.js SDK, it is not possible to direct queries to secondary replicas so that RU goes largely unused.

    2. In some use cases it can be better for performance to only use 1 or 2 partitions at a time for read/writes but over time data is spread across all partitions. In this case the RU for all partitions not being actively used at the time are largely unused.

    Ian Bennett commented  · 

    My suggestions are, in order of preference:

    1. Allow setting of a max RU/s limit and auto scale between lowest possible and up to that limit
    2. Bring back RU/m.
    3. Allow scheduling of RU/s settings from the Portal (I know this can already be done in a convoluted fashion with command line).

    Ian Bennett supported this idea  · 
← Previous 1 3

Feedback and Knowledge Base