We have this page in SharePoint that list all the sites, the person who manages that site, their contact info, and the last modified date.
Currently, we are using a custom webpart that crawls through the sites and reads through the metadata, and then it displays all these in a list.
Opening this page takes about 10+ seconds.
We're looking at ways to cut this time to less than 3 seconds.
I'm thinking about some sort of timer job that caches the page, say every half hour, and when the page is requested, simply display the cached version. The data in the page itself doesn't change that often so caching isn't really a big issue. Is this idea feasible? I'm fairly new in SharePoint so what would be the steps to implement this?
Or if there are any other options/suggestions on how to reduce the load time, I'm all ears.
here are some approaches that might work for you.
Extend your existing Webpart with a cache. So the first User who visit the Site will wait as long as with the existing Solution. But he will fill the cache, so every other call of the Site will be much faster
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.webpart.partcachewrite(v=office.15).aspx
Create a Timer-Job that fill up da extra SharePoint- List with the fields you need. So you render your Webpart using this data. To fetch the needed data from the List will be much faster than iterating some SPWeb or SPSite Objects.
A lot of data already can be fetched from the Search-Service, and you can extend the Attributes the search engine will crawl. Once the search attributes are extended you can create a search driven Webpart
http://technet.microsoft.com/de-de/library/jj679900(v=office.15).aspx
Each of this Solutions should work at SP 2007/10/13
If you need a quick-win than mybee Solution 1 is the best for you.
Regards
Related
I posted this question on Stack Exchange here: (https://sharepoint.stackexchange.com/questions/249418/filtering-sharepoint-list-by-another-sharepoint-list), but just realized I should have posted it to Stack Overflow instead. Hope it's not bad form to cross-post (I'll add a link to this post in the other post).
I've been searching the forums and doing research online with no luck- apologies if this has been answered before.
I have a list with several thousand items in it. I often receive bulk update requests where I need to update several hundred of these items at a time (let's say for this example that we're using a field called "Case ID").
Here's what I've tried:
Searching cases individually, or up to three at a time in datasheet view; this is not time effective
Exporting the list and manually manipulating the data in Excel, then pasting in (and writing over) the data in the column that needs to be updated; this approach is not user friendly, is not necessarily time effective, and has potential side effects (causing errors for users currently modifying items that I am changing in bulk)
Lastly- I know I can create custom views that isolate this data; the problem is that the lists of cases I need to modify generally do not have enough commonalities to isolate them using the view filter logic
So- my guess is that I need two lists, likely connected with a web part. The first list would exist solely for the purpose of querying the second list. I would enter the Case IDs I wanted to filter by in the first list, and the second list would filter to show only the Case IDs in the first list. All items would be deleted from the first list between queries.
I'm not married to this approach- it's just my best guess. I'm open to creative and alternative approached, but the final process needs to be user friendly (business partners will be using it).
Does anyone know how I can accomplish this? I've tried to get something implemented several times over the past few years and have never been successful; posting here is my last resort before I throw in the towel.
I have SP 2013, and have SharePoint Designer; please let me know if I need to add any other information.
Thanks in advance for the support,
Chad
I'd suggest to create a JSOM application that will do all updates. It can query only items for update and do item-by-item update.
I am developing Leave Management System in SharePoint 2013. Employees can apply for leaves and Manager can either approve or reject it.
I have accomplished this by creating a new list - "Leaves" and starting a workflow when a new item gets added. Workflow sends an email to Manager and creates a task item for him to be able to approve or reject it.
However, I would like to know if this approach is preferable in real time scenario. Suppose for organization of 500 employees, can a single list hold so many records for all employees. What are possible ways here to utilize the features in SharePoint and also create a scalable application.
Also, I am also planning to develop a new Add-in in SharePoint 2013 since for applying new leave, we need to display additional information such as available leaves and do some custom validations which are not provided by default SharePoint list. I will be adding the new item to the SharePoint list from the custom developed page so that the workflow still is intact and I am still utilizing out-of-box SharePoint features. Is this the way to go for enterprise level application or there are any other alternatives. Please suggest.
SharePoint Lists are capable of holding that much data. I don't see a problem if you use a single list to hold leave request of 500 employees.
Assume a worst case scenario that all of the 500 employee apply 25 leaves individually in a year, then the item count would be (500*25= 12500) which is not bad.
You will need to take care of the List Threshold error, because data is greater than 5000. For this you can create views which always bring out results less than 5000.
Now lets say you have plan for 5 years, so each year you will add 12500 items which at the end of 5 years will be 12500*5 = 62500 items
Here you can think of 2 options
You can create a list for each year, i.e. Leaves2016, Leaves2017 etc.
In a single list create folders of year, and inside them add all leave datas.
Note: The only major thing you need to take care of List view threshold problem. Which can be tackled with intelligently designing
views
For your second question.
I agree that the OOB SharePoint List form will not cater your requirements. So creating a custom page an add in or something else is a way to go. As far as your data is getting inserted into a list and eventually activating a workflow there is no harm in it.
In my new project, I have used a lot of Content Query Webparts (CQWP) and then I found that the site was becoming slower and slower when visited with the increasing number of CQWPs.The question I want to ask is:
Does a CQWP take a lot of server resources that make the site slow for visitors?
If I want to query the lists and customize the style of output then can I do it without a CQWP?
Take a look at this link may be you have to use custom XSLT with function to filter the output of CQWP.
http://blog.mastykarz.nl/extending-content-query-web-part-xslt-custom-functions/
For your first question
My answer is : It depends on the several things not only on the number of CQWP on the page.
Let me explain :
The CQWP has so many things to do like fetching data from the List which may be Sharepoint list or custom list ,the resource utilization depends on the logic applied to fetch the data from the list , by saying this I mean the amount of data to be fetched and the Logic complexity to get that data also make sense for the server resource utilization..
For example, If you have class which perform complex logic to get the data like comaprision , if else condition and ForEach Loops and the amount of data avaliable in list is large then it is obvious that it will take more resources from the server.
I hope you get my point
For Second question
My Answer is : You can use CQWp or DVWP(Data View Web Part), but be sure when to use which one.
To get more Idea about both of this take a look at this link
http://www.sharepointblog.co.uk/2012/06/data-view-web-part-vs-content-query-web-part/
In the SharePoint publishing site I will have some banners that are Web Parts and can have any HTML content inside them. I have requirement to count clicks on that banners. Banners will have some links to external sites.
I am not sure where to store counters for individual banners. Custom List is the first thing that came to my mind but I am not sure how will it behave in concurrent access. Can I lock list (list item) and do the counter increment ? What will happen for other list access if it is in lock state ? Will it fail or just wait ?
Are there any alternatives to storing counters somewhere else ?
There are lots of places, here are the two most popular:
Property Bag (most likely on the Web) which is a number you increment
Inside a list
Of these, I have successfully done it with a list on our blogging solution, you can see it here: http://community.zevenseas.com/blogs, where I'm tracking views for each post. I took this approach because I like to see more than a number, eg. referrer, ip, etc.
Things to keep in mind:
You need to keep a close eye on the number of items you are storing. SharePoint doesn't like lots of items in a list. To manage them put them in folders, a folder for each banner, and then subfolders for each month.
I would keep a list with each of the banners (just their name or more) in it, then create a second list to store the views. In the list where you store the views have a lookup back to the list storing the banners. On the original banner list you can then create a new column which "Counts" the number of Views related to each banner item.
Again, be very careful about the number of items you are expecting, but this works pretty nicely for us.
Don't forget a small database will allow you to store page hits against whatever you want. You can then call a stored proc and that database "just takes care of it". You don't have to worry about access and concurrency (because you used a transaction riiiight!).
A SharePoint list is easy because they are there out of the box, but consider that they have a lot of overhead for adding values and even reading from. They are also editable by a site administrator, which may be find, depending on the number of administrators you have. A list is easier to provision than a new database, so in the end you do need to consider the two options carefully.
Just because SharePoint has a hammer does not mean everything is a nail :)
I need to create feature which will iterate through all subsites of site collection and add some sample content to each of them (sample content=new pages,images,documents,possibly some lists). There is solution that uses recursion to loop through sites (it can be found here).
So i'm asking:
Did any of you implemented something similar, maybe in different way?
What was the performance of such iteration?
I can't really say how many subsites can be present in site collection, since this feature should be used in more projects. But i guess the number of subsites shouldn't excess 100 or such.
That is a very common method of performing looping of sites and web parts.
Speed with 100 sub-sites will not be a problem. It is really quick, if you do alot of processing that can slow it down.
The one thing to watch is the disposal of items if you leave the open or don't close you can suck all the memory from the WFE, especially if alot of users reload the page at the same time.
See http://www.sharepointnutsandbolts.com/2008/06/disposing-sharepoint-objects-what-they.html and http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx for examples they also have the disposal tool at http://blogs.msdn.com/sharepoint/archive/2008/11/12/announcing-spdisposecheck-tool-for-sharepoint-developers.aspx
You can look at the answer I gave to this question. I think I've used the correct dispose patterns for that piece of code.
If you need to do a read-only loop through a big structure, here's a cool, yet a bit untraditional, way of doing it:
http://hristopavlov.wordpress.com/2008/10/20/a-very-fast-method-to-get-the-site-collections-web-structure/