locked
What are the limitations of version 2 of the lightswitch? RRS feed

  • Question

  • What are the limitations of version 2 of the lightswitch
     1 Number of tables that can import.
     2 Number of screens that can have.
     3 Number of users can simultaneously access the web application

    Friday, April 13, 2012 4:41 PM

Answers

  • Hey Marden,

    The limitations on a LightSwitch V2 Beta project would likely be somewhat constrained by your machine specifications.

    That aside, I can provide some basic numbers for what you would likely see as an upper limit with a LightSwitch V2 project:

    1) Number of tables - in the upper hundreds

    2) Number of screens - in the upper hundreds

    3) Number of users accessing your application - obviously depends a lot on your Server setup that is hosting your application, but there shouldn't be a problem with LightSwitch supporting over 200 simultaneous typical user requests.

    Some extra number:

    1) Number of queries - in the upper hundreds

    2) The number of properties on an instrinic entity will max out at 1024, which is a SQL Server limitation


    R. Matt Sampson

    • Proposed as answer by J Lamb Friday, April 13, 2012 8:37 PM
    • Marked as answer by Marden LR Friday, April 13, 2012 11:55 PM
    Friday, April 13, 2012 8:00 PM

All replies

  • Hey Marden,

    The limitations on a LightSwitch V2 Beta project would likely be somewhat constrained by your machine specifications.

    That aside, I can provide some basic numbers for what you would likely see as an upper limit with a LightSwitch V2 project:

    1) Number of tables - in the upper hundreds

    2) Number of screens - in the upper hundreds

    3) Number of users accessing your application - obviously depends a lot on your Server setup that is hosting your application, but there shouldn't be a problem with LightSwitch supporting over 200 simultaneous typical user requests.

    Some extra number:

    1) Number of queries - in the upper hundreds

    2) The number of properties on an instrinic entity will max out at 1024, which is a SQL Server limitation


    R. Matt Sampson

    • Proposed as answer by J Lamb Friday, April 13, 2012 8:37 PM
    • Marked as answer by Marden LR Friday, April 13, 2012 11:55 PM
    Friday, April 13, 2012 8:00 PM
  • Hi Matt,

    thanks for clarifying my doubts

    Friday, April 13, 2012 11:55 PM
  • Hey Marden,

    The limitations on a LightSwitch V2 Beta project would likely be somewhat constrained by your machine specifications.

    That aside, I can provide some basic numbers for what you would likely see as an upper limit with a LightSwitch V2 project:

    1) Number of tables - in the upper hundreds

    2) Number of screens - in the upper hundreds

    3) Number of users accessing your application - obviously depends a lot on your Server setup that is hosting your application, but there shouldn't be a problem with LightSwitch supporting over 200 simultaneous typical user requests.

    Some extra number:

    1) Number of queries - in the upper hundreds

    2) The number of properties on an instrinic entity will max out at 1024, which is a SQL Server limitation


    R. Matt Sampson

    Hi Matt,

    I would like to ask about the limitations. As LS can run on Azure, and we can increase as much instances as we like, how the number of users accessing the LS application may occur?

    Regards,

    Tony Nguyen

    Saturday, July 21, 2012 3:23 PM
  • Hey Tony,

    There really is nothing different with respect to Azure.  My above numbers would still apply.

    For Azure, a LightSwitch application will host the "Server" components on Azure.  The "Client" application will run in the browser, or on the desktop.  The "Server" in Azure would handle all the requests that the client sends to it. 

    -R. Matt Sampson


    R. Matt Sampson

    Monday, July 23, 2012 2:54 PM
  • Hi Matt,

    thanks for clarifying my doubts

    Do excuse the question, but why use the word "doubts"...?  I'm intrigued as to what you have in mind for your LightSwitch solution that would appear to render these numbers "too small".

    Care to comment, please?

    Tuesday, July 24, 2012 8:27 PM
  • I think you'll find it's just a "language thing".

    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

    Wednesday, July 25, 2012 5:24 AM
  • Do excuse the question, but why use the word "doubts"...?  I'm intrigued as to what you have in mind for your LightSwitch solution that would appear to render these numbers "too small".

    Care to comment, please?

    sorry for my english. I am Brazilian and I am not fluent in your language.
    I was thanking him for responding to my question.
    but in relation to lightswitch ...

    Build applications according to customer's need, without having to create things that he will not use. I always create the database first. optimize the database for the lightswitch able to map perfect. views to create reports. and to visualize these views create wcf services. this way I have no problem with the primary keys. and always have the same information in my report.

    Wednesday, July 25, 2012 10:47 AM
  • No worries, I'm English and I have troubles with American English after 21 years in the States.

    Thanks for the summary.  I'd encountered the VIEW PK issue and, lacking any clue as to how to go about WCF RIA Service creation, abandoned that part of the planned app.

    With LightSwitch-2 differing extensively from v1, I'm reembarking on LightSwitch in hopes I can find an EASY way to access the slew of Stored Procedures we have that hide rows of no interest to a list, for example.  WCF's look like one way to go, I just wish they were easier to understand and develop!  Half the terminology in Books Online is techno-babble.  Kudos to you for having succeeded with the POCO Service!

    Wednesday, July 25, 2012 4:26 PM
  • Have a look at the article that the LS team's Eric Erhardt wrote a while back. It gives a very good introduction to writing RIA Services for LightSwitch, as well as a few other neat tricks, like reusing the data model athat LightSwitch has already created.

    How Do I: Display a Chart Built On Aggregated Data

    It really isn't as hard as you might think, once you write your first one. I've written a bunch of RIA services now, where I would have used Views in SQL/WPF etc.


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

    Thursday, July 26, 2012 12:45 AM
  • LS server is a IIS app, so would seem to be similar to any other IIS app as far as limits.  Number of users does not (to me) seem to be the question. It is number of requests or requests per second/minute.  But now you enter grey area of what the machine(s) can handle, how many front ends, sql db machine perf, etc.  I don't think hard limits will apply to most people in general.  It will be sizing the server equipment to handle request load.
    In terms of perf, there is a lot we can and should pay attention too with LS.  For example, if you have a default List or grid that opens each time with 45 records (or more) pulling from the server every time for 500+ users, you probably want to look at that again.  For example, have a search grid available, but not opened by default and maybe does not return anything by default until you enter search data.  Have an "Add Record" screen instead of adding records from a List screen which would need to be populated first.  There is a lot of wasted queries and processing that can be avoided with an eye toward perf, but still keep a good user experience. In fact, the more perf we can save (which is factored by users), the better the user experience can be because compute will not be wasted on unneeded requests. 
    Thursday, July 26, 2012 2:38 AM
  • Hey Tony,

    There really is nothing different with respect to Azure.  My above numbers would still apply.

    For Azure, a LightSwitch application will host the "Server" components on Azure.  The "Client" application will run in the browser, or on the desktop.  The "Server" in Azure would handle all the requests that the client sends to it. 

    -R. Matt Sampson


    R. Matt Sampson


    Hi Matt,

    I try to work my head around but still can not understand your reply.

    The cloud concept means the app can scale up to handle a larger number of requests. So can we assume that one instance will manage 200 simultaneous typical user requests and 10 instance will manage 10 x 200 ones.

    Regards,

    Tony
    Thursday, July 26, 2012 10:36 AM
  • Hi Yann,

    I'm plodding my way through Eric's article.  Having the C# skills of a novice, it takes me some time to work through many of the other examples, including http://blogs.msdn.com/b/eric_erhardt/archive/2012/04/19/updating-records-in-lightswitch-using-stored-procedures.aspx, which has me lost as there appears to be just one update method for a table; clearly useless to me.

    I'm hoping that Microsoft's documentation and tutorials will pick up (immensely) so they become intelligible for the alleged intended audience of "Power Users", most of whom I doubt have the depth of C# or VB skills to call upon that are required to unravel to a cloneable state that which has been posted in blogs, BOL and these Forums.

    We have hundreds of well-written, business requirement supporting SPs and don't want at all to have to re-craft any logic from them into any LightSwitch code, hence the need for Services.  The column names are frequently different from the underlying tables, so a data model built by pulling tables into LS isn't much use, which appears to require a more complicated approach of, for want of better wording, "fake entities" and coding to intercept the LS pipeline for CUD operations.  Why?  Because we have Salesforce (which we're looking to dump), a home-brew old .Net app that pulls from Salesforce and partially updates our configuration tables for a new customer site, about 20 tables, and we have a bunch of new tables that need a UI.  Mix this with zero on-site .Net/Web UI developers and we're hoping that LS can give us a usable front-end for what is already robust, plus the new facets, all rollled into a multi-flavor UI that we need in a browser or in an HTML5 client for configuration while and engineer is in the field.

    As I come to new things I can't find examples for, I'll open new Forum Posts in hopes they'll benefit others if answers can be garnered.

    Thanks again, Yann, I appreciated your help on my my initial LS-1 project...

    Thursday, July 26, 2012 4:45 PM
  • You're welcome, of course!

    Why do you say "just one update method for a table; clearly useless to me"? That's all LS needs to be able to update a table (if you're creating an entity using a RIA service). If you need to trigger a different way of updating, using your existing stored procedures, then Eric's second article is what you need to use.

    And yes, please do keep asking (separate post) questions as required. That's how I started. Then when I had knowledge I could share, that's what I did.


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

    Friday, July 27, 2012 4:36 AM
  • You're welcome, of course!

    Why do you say "just one update method for a table; clearly useless to me"? That's all LS needs to be able to update a table (if you're creating an entity using a RIA service). If you need to trigger a different way of updating, using your existing stored procedures, then Eric's second article is what you need to use.

    And yes, please do keep asking (separate post) questions as required. That's how I started. Then when I had knowledge I could share, that's what I did.


    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

    Friday, July 27, 2012 4:36 AM
  • I'm following Eric's second article because of the limitations of the first method.  For example. if I'm following good business process analysis, I'll discover many and various actions that can be performed on an entity type.  In an environment where reuse of Stored Procedures is either desired or mandated, obviously:

    1. Creation must occur - the C of CRUD is covered.
    2. In many businesses, a well-defined data archival/deletion policy may not exist, so Deletion is thereby optional.  If policy is defined, the D of CRUD is covered.
    3. Listing in various ways is typical, at least in my 35 years of experience it has been, so there will be many Reads - R covered.
    4. Updates are where the simplistic CRUD model falls flat on its duff.  Simple entity types can be accommodated with a single Update stored procedure that takes in all fields, updates them and done.  However, as in Eric's good example, what if you have a completely valid business process like changing a customer's marital status?  Should one use the "hammer" approach, reading all columns, sending back all columns and having the almighty Update SP determine what changes to apply?  Not if you have Stored Procedures that support the granular business logic, ensuring data-integrity while they apply the focused updates.

    In my case, a Site has 19 attributes, an ID and 2 "who" columns for auditing.  When a Site is launched, all I need is the ID and the Launch Date.  Likewise, when a Site is terminated, I simply need its ID as the business is OK with "now" as the effective date.  But, what if my over-eager User launched the wrong site?  I need an un-launch SP that only needs the ID.  Similarly, when a Site is inadvertently terminated, I need to reinstate it, so an SP with just the ID as its parameter will suffice.

    Take these four "commands" and apply them to a simple LightSwitch application, and Eric's second example is clearly the model I need to emulate.  The UI will have only 1 or 2 buttons per site, launch/un-launch and optionally terminate/un-terminate.  Knowing the current state of each Site when it is pulled from the database, I can very easily use computed columns to manage these artifacts, hiding the launch button when the site is terminated and hiding the terminate button when the site isn't launched but showing both when the site is launched but not terminated.

    I hope this brief description sheds light on my "...clearly useless to me" comment re the first approach.

    Perhaps, Yann, if this doesn't make sense, you'd head me off at the pass before I commit too much time to a futile endeavor.

    Best regards,

    Stephen

    Friday, July 27, 2012 4:50 PM
  • For me as a developer, the biggest limitation of LS is the number of developers that can safely work on same project. Unfortunatelly due to the using of single LSML file for all screens and not offering a solution for dividing the client application in modules this number is only one, which limits the usage of LS to relativelly small applications only.
    Saturday, July 28, 2012 12:28 PM
  • Well this has changed from one lsmls file in V1, to 3 lsml files in V2, so that will help a little. I don't know if MS will ever make LS specifically multiple-developer friendly though. Let's just hope that I'm wrong. :-)

    Yann - LightSwitch Central - Click here for FREE Themes, Controls, Types and Commands
     
    If you find a reply helpful, please click "Vote as Helpful", if a reply answers your question, please click "Mark as Answer"
     
    By doing this you'll help people find answers faster.

    Monday, July 30, 2012 3:06 PM