(In 2-Level Paging)
If so: Does every process have multiple Page Tables?
If not: How is it ensured that a process doesn't point to a Page Directory Entry from a different process?
Well, I found the answer:
It depends on the implementation. But in most cases every process does have its own Page Directory.
Also, a Page Directory can reference up to 1024 Page Tables. (But usually doesn't need that many)
And one Page Table can have up to 1024 entries.
Related
On the side of each page on my site I list the other Pages in that Section. I also mark if the User visited or completed each page. Every time a page loads, Rails has to check the database to see if the User visited or completed each page in the Section, which makes displaying a page take longer. Is there a way I can speed this up?
Example: user visits page 2 and the sidebar loads. He then visits page 3 and the sidebar loads again, but likely with a different mark next to Page 2.
Page 2
------
- ✓ page 1 | Main Content
- > page 2 | The quick brown fox...
- page 3 |
...
There are a few areas you could improve performance, both in database lookup and in rendering.
For rendering, you should look at fragment cacheing the sidebar for visited links, although your scenario is a bit out of the ordinary in terms of keeping track of visited links in your app.
For each link in the side bar you could save a fragment that represents visited and unvisited, then the outer container could represent any permutation of visited and unvisited since it doesn't really matter which user it is when you display it. You will end up with a lot of various side bars for each of those scenarios.
For the database you could look at something like identity_cache and hold the list of users page visits in the cache to avoid unneeded lookups, invalidating when they hit a new page.
This is as good as I can get for such a broad question in relation to Rails and speed ups in general, which seems to be what the question is asking. There are numerous other platforms specific speedups that you can get by playing with different caching back-ends and servers as well.
I assume you are keeping track of the pages they have visited and/or completed in a database table because this data needs to remain stateful.
If so, first off, make sure your table is properly indexed on the columns it needs to look up.
Then, cache the results in a sessions variable, so that you can retrieve it from there and only go to the database when necessary (e.g. something changes the state or a certain period of time lapses)
I'd like to hold a collection of uploaded files for a user (where there might be multiple requests for each file, or even multiple requests per-file for chunking), but I'm struggling to find the appropriate scope. Once they're done, another request will say so, and the collection will dump its data to physical files and a DB entry and empty itself.
Ben here: http://buildstarted.com/2011/07/17/asp-net-mvc-3-file-uploads-using-the-fileapi/ uses a static collection, but that would be inappropriate for multiple users.
You need to store the files somewhere semi-permanent. Session could be reset along with the app domain, so you can't rely on it 100%.
Just have a separate file/db location or flag which lets you know the whole set of files is not completed.
I'm building a web app for bookmark storage with a directory system.
I've already got these collections set up:
Path(s)
---> Directories (embedded documents)
---> Links (embedded documents)
User(s)
So performance wise, should I:
- add the user id to the created path
- embed the whole Paths collection into the specific user
I want to pick option 2, but yeah, I dunno...
EDIT:
I was also thinking about making the whole interface ajaxified. So, that means I'll load the directories and links from a specific path (from the logged in user) through ajax. That way, it's faster and I don't have to touch the user collection. Maybe that changes things?
Like I've said in the comments, 1 huge collection in the whole database seems kinda strange. Right?
Well the main purpose of the mongoDB is to support redundant data.I will recommend second option is better because In your scenario what I feel that if you embed path collection into the specific user then by using only single query you can get all data about user as well as related to path collection as well.
And if you follow first option then you have to fire two separates queries to get all data which will increase your work somewhat.
As mongodb brings data into the RAM so after getting data from one collection you can store it into cursor and from that cursor data you can fetch data from another collection. So if we see performance wise I dont think it will affect a lot.
RE: the edit. If you are going to store everything in a single doc and use embedded docs, then when you make your queries make sure you just select the data you need, otherwise you will load the whole doc including the embedded docs.
I use a homebrewn CMS in my site. The texts in it are used by inserting an html-helper into the view:
<%=Html.CmsEntry("About.Title")%>
The entries of the CMS are stored in SQLServer. I need a way to scan all views in my project and see if all tokens are already in the database.
Is there a way to do this? I already enter an entry into the DB at runtime, when a token is not found, but I need a way to do this without visiting each page. Maybe via reflection?
One way to do this is to create a page (controller action) that scans through the files looking for "Html.CmsEntry" and parses out the page names, and then queries the database.
If you have access to the database from your dev machine, you could possible do this in a console app, and set it as a build action, so whenever you compile, it runs.
Failing that, you could try relying on a spider (GoogleBot, or otherwise) to hit all your pages, and trigger your existing logging code.
Alternatively, you could store all your page names as constants or enum values. If you used enum values, you could easily spin through them (using Enum.GetValues) and check they're in the database.
All that said, if the pages are stored in your database, can't you do away with all the static pages that call them, and generate everything dynamically from the content already in the database?
We are going to port a legacy windows app to a large web application for a vertical market. Looking at MVC. Each implementation may have 50 to 5000 users. Looking at putting navigation in Master Page. The application will contain 200 to 300 menu items, resulting in over 500 views. We want to display a trimmed navigation menu for each user based on their application permissions. A user may see only 20 items, or all available.
Most posts I have seen suggest passing navigation items to Master Page through viewdata, established in a base controller class. I understand this.
Each of the potentially 10's to 1000's of users will have a different set of permissions.
Does anyone have any solutions that will avoid hitting the database to get the users menu items on every controller request that inherits from the base controller?
Is there a caching scheme that will work for each user?
Should the navigation be handled in a frame (not my choice)?
Is this just a price we will pay for this approach to navigation?
Thanks for any input!
You could start by caching linq queries which would be a nice way to tackle this at the DB tier.
Doing this in MVC using an action filter wouldn't be too hard either.
I implemented something like this in PHP a year ago but the general idea is the same. Firstly, you'll need to assign each menu configuration a unique id. This way when user A and user X request the same menu configuration, it resolves to the same cache file.
The first time a menu needs to be loaded for the user, it is loaded from the database and passed to the user. Simultaneously, it is saved to a cache file with the unique id in its name. On subsequent requests the action filter can load the data from the cache file if it exists and bypass the database.
Some ideas:
1.) You could have your nav bar html come from a Html.RenderAction (MVC Futures) and use the Output cache on that.
2.) You could generate the html for the nav bar per user then save that to the DB and regenerate if their user permissions change. So all you would need to do is pull the html from the DB against each users record.