Hi,

I am running DNN 4.5.3 with Repository 3.15. I have a repository with 500 entries. Each entry is simply a url to an MP3 recording on an FTP server. However, each entry has 4 custom attributes and a category. Some of the custom attributes have 20-50 available values.

I do not know why but the performance of the Repository is awful, even though I am on an expensive, high-level plan with Webhost4Life. I don't know if it's the number of entries in the Repository (unlikely), or possibly the number of custom attributes and their values. Often the main listing takes up to 1 minute to appear and the same for filtering on the attributes. Sometimes it just times out. All other pages on the site come up instantly.

Is there anything I can do to fix this other than modifying the Repository code? I am a .NET developer but only use C# so working with VB.NET will be a little cumbersome. Also I don't have much free time. However I'm willing to give it a go if it's my last resort.

If I go with modifying the code, what would be the simplest way to cache the Repository so that it does not have to go back to the database on every hit? I envision caching the entire Repository as a DataSet in the web cache. Then writing a singleton class that acts as the gatekeeper ("cache manager") to this cached DataSet. Instead of the page controls going off to the datalayer on every single hit, they would instead go through the cache manager. The cache manager would get the DataSet from the cache, do any sorting or filtering and return the values to the calling page control as an ArrayList (the page controls seem to be expecting an ArrayList back).

Any uploads or edits of any kind would also have to go through the cache manager so that the cached DataSet could be invalidated. Then the next request through the cache manager would cause the Repository to be refreshed from the database.

If anyone can point me to where in the code the best place to implement all this would be, or give me any other ideas, I would REALLY appreciate it.

Many thanks,

Simon.

Hi Simon,

I think that caching is much more simple than you believe with the standard DNN module pattern: all the data access is performed by the code through a CBO controller. I successfully tested caching this way:

• Whenever performing a "read" action, check if the cache has already it available, if not, perform the db access, return the data and store it in the cache.
• Whenever performing a "write" action, perform the db access and purge the cache.

You may end up with something like:

Imports System.Data
Imports DotNetNuke.Common.Utilities
Imports DotNetNuke.Services.Cache.FileBasedCachingProvider

Public Class ObjectController

    Private CachingProvider As New FBCachingProvider

    Public Function AddObject(ByVal myObject As ObjectInfo) As Integer
        With myObject
            Return DataProvider.Instance().AddObject(...)
        End With
        PurgeCache()
    End Function

    Public Function ListObjects(ByVal objectID As Integer) As List(Of ObjectInfo)
        Dim List As List(Of ObjectInfo) = CachingProvider.GetPersistentCacheItem("ListObjects", GetType(List(Of ObjectInfo)))
        If List Is Nothing Then
            List = CBO.FillCollection(Of ObjectInfo)(DataProvider.Instance().ListObjects(objectID))
            CachingProvider.Insert("ListObjects", List, True)
        End If
        Return List
    End Function

    Private Sub PurgeCache()
        CachingProvider.RemovePersistentCacheItem("ListObjects")
    End Sub

End Class

This is just my 2 cents...

Best regards,
Dario Rossa