Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have an asp .net 4.0 application. I have an mdf file in my app_data folder that i store some data. There is a "User" table with 15 fields and an "Answers" table with about 30 fields. In most of the scenarios in my website, the user retrieves some data from "User" table and writes some data to "Answers" table.
I want to test the performance of my application when about 10000 users uses the system.What will happen if 10000 users login and use the system at the same time and how will the performance is affected ? What is the best practice to test my system performance of asp .net pages in general?
Any help will be appreciated.
Thanks in advanced.
It reads like performance testing/engineering is not your core discipline. I would recommend hiring someone to either run this effort or assist you with it. Performance testing is a specialized development practice with specific requirement sets, tool expertise and analytical methods. It takes quite a while to become effective in the discipline even in the best case conditions.
In short, you begin with your load profile. You progress to definitions of the business process in your load profile. You then select a tool that can exercise the interfaces appropriately. You will need to set a defined initial condition for your testing efforts. You will need to set specific, objective measures to determine system performance related to your requirements. Here's a document which can provide some insight as a benchmark on the level of effort often required, http://www.tpc.org/tpcc/spec/tpcc_current.pdf
Something which disturbs me greatly is your use case of "at the same time," which is a practical impossibility for systems where the user agent is not synchronized to a clock tick. Users can be close, concurrent within a defined window, but true simultaneity is exceedingly rare.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a complex JSON which I need to persist over two POST requests. Currently i'm storing the serialized JSON in tempdata though the second post never succeeds before of Error 400(The size of headers is too long). In this image I viewed the cookies in Chrome Debugger
Am I doing MVC wrong? The data is probably too complex to be stored in tempdata. However for this example this JSON is only 234 line(Unsure if this reflexes cookie size accurately). I know I could increase the size of the cookie but this wouldn't fix the real issues.
Should I be storing the data in a different method?
Basically in my project i'm posting a value to the controller(Many times via POST) which then uses the value to get a certain part of the JSON. Is Session the only alternative?
I'm still a novice to MVC so forgive me if i've made a simple mistake
First, TempData and Session are the same thing. The only difference is the length of persistence: in the former, just until the next request, while in the latter for the life of the session.
Second, session storage has to be configured. If you don't configure it, then something like TempData will attempt to use cookies to persist the data. Otherwise, it will use your session store. Basically, by using any actual session store, you should have no issues with the size of the data.
Third, you have not provided much information about what you're actually doing here, but for the most part, sessions (Session or TempData) are a poor choice for persistence. The data you're trying to store between requests does not sound like it is user-specific, which makes sessions a particular poor choice. Most likely, you want a distributed cache here, though you could potentially get by with an in-memory cache. You should also consider whether you need to persist this data at all. It's far too common to over-optimize by worrying about running the same query against at database, for example, multiple times. Databases are designed to efficiently retrieve large amounts of data, and properly set up, can handle many thousands of simultaneous queries without breaking a sweat. Ironically, sometimes a caching a query doesn't actually save you anything over actually running the query, especially with distributed caching mechanisms.
Simple is better than complex. Start simple. Solve the problem in the most straight-forward way possible. If that involves issuing the same query multiple times, do so. It doesn't matter. Then, once you have a working solution, profile. If it's running slower than you like, or starts to fall down when fielding 1000s of requests, then look into ways to optimize it by caching, etc. Developers waste an enormous amount of time and energy trying to optimize things that aren't actually even problems.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
When developing safety-critical software using some quality standards (like e.g. IEC 61508 or DO 178-C) developers have to care about many things. I know that the verification in each development step is quite time consuming and expensive. Moreover, I know that some reduced programming languages are used.
But I am interested in the concrete difference to a "normal" SW-development process. I mean in the standard V-Model, verification and testing should also be part of each development step. What do I have to consider finding requirements? What do I have to consider in SW design?
It isn't so much as a change in the "V Model" that helps verify critical system, it's what you do at each step of the way.
For example you may prefer to plan your development using waterfall in order to have verification steps and controlled transition periods. This has the benefit of staying in line with any government regulations that may be in place.
While developing it is common to use a limited subset of assemblies (APIs) in order to prevent developers from preforming dangerous operations. This type of restriction can also ensure that developers utilize the APIs correctly, such as cleaning up objects as a requirement.
Once the product has been developed you'll likely have gone through all of the testing phases. It is common in industry to develop test fixtures in order to verify and generate data to prove to the government or customers that your system says what it does.
In general, this topic is very deep. You did mention standards, one more is the ISO 2008 standard. I think what you should keep in mind is that the process doesn't change much (the life cycle model stays generally the same). But what you do at each step of the model will change depending on the project. You can take classes on Project Management... In fact it is a tract and sometimes a full degree program. So there's tons to learn about process and how to manage different projects.
Googling system critical projects and project management will likely generate a trove of knowledge.
Hope that helps shed some like on the subject.
EDIT: Finding requirements, like in a waterfall process, is very time consuming. It will involve understanding the customers needs and goals of course. In general you have to spend lots of time in this area for government reasons and software architecture. It's not really a different technique... Be explicit, understanding the requirements is most critical. The system shall recover from 90 second timeouts within 5 seconds of resetting. <- its like all other requirements in SW engineering... Explicit and testable. Objective not subjective. Think Grammer Nazi level of consideration.
One example of a safety critical systems is lockheeds F-35... The system requirements manuals are huge and the process to make a change requires meetings and quite a bit of paperwork.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to figure out when using user stories is appropriate. Always or not?
For an example, think about a team starting to work on something from scratch, say a movie ticket reservation service. It's easy to come up with user stories for the functionality, like:
"As an end-user I want to be able to browse the movies running in theater X" and so on.
But before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic.
How should these tasks appear in the backlog? Should they be user stories as well? If so, how do they comply with the INVEST mnemonic? They don't alone deliver anything for the end-user, but nevertheless they are needed before any feature can be implemented.
But before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic.
Not really agree with it. Since a story is a feature which takes almost every layer of your architecture implementing the story builds up the architecture same time. Check up Alistair Cockburn's Walking Skeleton definition.
About the question
Most of the stories you may define as "As a user..." as a feature the story may has UI work as well. So to make it clear you may split up the story into subtasks.
Although some work would be hard to present in INVEST user stories. For instance bugs, tech. dept and so on. They still be presented as stories of a special type(Bugs, tech stories). you couldn't show them on Demo however you may mention about.
(...) before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic. (...)
Not exactly. E.g., you don't need to get the entire database designed for implementing functionalities for a sprint, a specific release or whatever given time. What you may need is some common ground.
This is where one of the Agile's beauties lives (vs. waterfall), welcoming change.
Now, answering your question: realize that the role in a user story is not necessary a role of the end customer. Could be your developers, your sysadmins, etc. As such:
AS A server administrator,
I WANT to upgrade our webserver
SO THAT it will handle better the memory consumption
So, you could ask convince your P.O. to add or prioritize in the backlog an user story (or several) for building up some ground for the future development. But, again, when creating such stories remember the Agile value of Responding to change.
P.S.
It's also important to keep the Product Backlog clear and accessible, and provide properly interaction between P.O. and Development Team. This should be guided by the Scrum Master.
This way the team could give better feedback/warn the P.O., in a technical perspective, how one story affect each other and why should story X should be done before story Y.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We are new to Scrum and part way through the first sprint we have realised that one of the team members (a developer) needs to do some investigation into how navigation should work (from a user perspective) in the application.
So at the end of this investigation we should have a proposal or prototype of how something should work. But it wont have been actually coded in the application.
So my question is, how should we deal with something like this in terms of the sprint planning. I don't really see it as being user story, but what is it, and how is it treated in Scrum? Does something need to be added to the planning board for the investigation?
Thanks
Paul.
Try to treat prototyping like any other requirement as much as possible. Think about what you want to achieve, create a user story, define one ore several tasks and estimate them during sprint planning. Think of the development team being the user in this case. Definitely have it on the planning board and track progress in daily Scrum meetings. If you have problems estimating the tasks, define them as "time-boxed", i.e. with the fixed time budget, to prevent "endless" work without results.
Although you got the solution Just wanted to add something here.
Such prototyping/researching works are termed as Spikes in the Agile world.
Here, the team dedicates some members into such spikes only so much as to understand the feasibility of the user story and be in a position to help the entire team estimate for the user story.
SCRUM is rather an organizational process than a development model, like prototype-driven development. It means that different X-driven-development models can be easily incorporated, like TDD or even prototype-driven (PDD).
To incorporate PDD in SCRUM, one can set several milestones that are prototype versions. SCRUM can be used normally considering each prototype as a whole new project. It is good for a complex prototype.
However, if creating a prototype is very easy, and a single person can do it in one or two sprints worth of time, so it might be useful to retain a prototype-specialist, that, much like the application-specialist, monitors the work of the rest of the team to check consistency with the ultimate goal. However, a prototype specialist can iteratively provide new prototypes, guiding the work of the rest of the team in a practical manner, differently from the application specialist.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have released a ASP.net website.
How to document it ?
Is there any tools available in VS2008?
How it can be achieved ? Please help?
Any automatically-generated documentation is useless, in my opinion. Unless you are ready to take your time and describe high-level decisions, structure, code organization and other issues personally, you can safely omit this part.
As it has mentiond good documentation can't be automated. So you can use MS Word. And for any kinds of diagrams I would use MS Visio.
I found this tool, they offer a free trial version. I never used it. Maybe it will help you.
http://www.innovasys.com/products/dx2008/overview.aspx
Quotes from the site:
"Document! X automates the process of creating and maintaining documentation for a wide range of solution elements."
"With Document! X, documentation can be automatically produced throughout design and development without requiring investment of developer resources, providing development teams with an accurate and up to date reference and allowing new developers to jump the learning curve of new components and schemas. Document! X makes producing documentation a natural and productive activity for developers and technical writers alike."
This is a quote from other site about the same tool:
"New features included in Document! X 2008 include compatibility with Microsoft Visual Studio 2008, documentation of ASP.NET Ajax Javascript and new templates to replicate the fresh look and feel of the Microsoft Visual Studio 2008 documentation."
What do you need to document?
The design? You can use sandcastle to generate a code file from the XML comments in your source code. Providing a detailed description of design choices and architecture can't be automated and requires time to document. Provide workflows where necessary to explain processes. You might want to split this document into high level design and detailed design, providing an overview of functionality and then a detailed description of the design. Don't replicate or explain the actual code per se (i.e. "using an integer counter, loop through..."), that's what the source is for.
The application usage? Again, this is something that you will need to spend timing writing. Hopefully you already have a functional specification and use cases for the application and can leverage these to write a user document.