Using actual tip code I noticed there is still a dependency on ClaySharp.dll is it normal

Topics: Customizing Orchard, Installing Orchard, Troubleshooting, Writing modules
Mar 29, 2013 at 4:25 PM
Edited Mar 29, 2013 at 4:26 PM
Cleaning my solution and removing everything not necessary, deleting dependencies.xml, I still get
And projection layout has no reference to it and quite no code ???
No project referencing claysharp ?
Is there some external assembly using it or is it something in my install ?
Mar 29, 2013 at 4:43 PM
Perhaps try cloning a new instance of Orchard and Contrib.ProjectionLayouts and see if you see the same?
Mar 29, 2013 at 4:48 PM
On your side you have no claysharp in your dependencies ?
Mar 29, 2013 at 5:14 PM
Edited Mar 29, 2013 at 5:14 PM
I do have it in installs before the dependency on ClaySharp was removed, but I don't have it in installs after that.
Mar 29, 2013 at 5:35 PM
Strange, I had all rebuilt and using nothing exotic or old. I am short in time but will try a clean install asap.

Envoyé à partir de mon Windows Phone

De : [email removed]
Envoyé : ‎29/‎03/‎2013 17:14
À : [email removed]
Objet : Re: Using actual tip code I noticed there is still a dependancy on ClaySharp.dll is it normal [orchard:438453]

From: sfmskywalker

I do have it in installs before the dependencies on ClaySharp were removed, but I don't have it in installs after that.
Mar 29, 2013 at 11:14 PM
Edited Mar 30, 2013 at 8:26 AM
Ok, after a big clean up, deleting all bin and all obj, I have no more clay..... I think some files has been touched on a crash or a move between storages, and were never rebuilt, so orchard was always loading them. This could explain some slow execution I was experimenting in Azure Web site..... some parts of orchard were always rebuilt....
Mar 30, 2013 at 12:05 AM
On azure websites, don't forget to disable the monitoring. Search in the docs.
Mar 30, 2013 at 8:27 AM
Thanks Sebastien I had checked this point....and my understanding of Orchard is better.
Apr 5, 2013 at 8:41 AM
Edited Apr 5, 2013 at 11:21 AM
I disabled monitoring ( ->HostComponents.config ) but it is alway as slow as it was 3 months ago on my last install on AWS.
The admin part is especially slow.
The orchard code is the today's code with Nwazet commerce + my extension and some very stable core modules as email, contrib.cache, projection layout and indexing.
Everything freshly built with VS 2012 and web_deployed apparently without any problem.
In this session I decided to not use SQL Azure but a local compact SLQ Server.
Using a reserved mode with 3,5 G memory.
Displaying a page with a 10 items projection for slideshow take nearly 2 minutes !!!!!!
Same thing to access the login page.
When all this is running ideally locally its especially frustrating.

All this is for sure compiling everything on each new request.

I must be missing something ????
Apr 5, 2013 at 8:46 AM
Profile it.
Apr 5, 2013 at 9:31 AM
Edited Apr 5, 2013 at 4:51 PM
Today at 10:28 AM

Using Chrome

1,5 minute to GET the main 6,5 K of Html
all the css and javascript are under 200 ms, but a contact widget ajax-loaded 15s

The Orchard log file is empty
Apr 5, 2013 at 1:28 PM
Edited Apr 5, 2013 at 1:34 PM
I just realized that AWeb Sites has recovered and presented, as a new VM an old one I deleteded 15 days ago with all the old Orchard install still here.
But I was having deleted it....

and looking in some bin folders from modules I found some not nedeed assemblies: ClaySharp.dll and NHibernate.SqlAzure.dll
I had a look on the dependencies xml file in App_Data and found all these unecessary assemblies referenced as dependencies

I checked my source project and again removed any of these assemblies - > ClaySharp.dll and NHibernate.SqlAzure.dll

Then I clean do another web deploy using the option 'Remove additonal files at destination'

I deleted the dependecies folder in App_Data

after successful deploy, I checked that the ClaySharp.dll and NHibernate.SqlAzure.dll were no more in the bin folders where I found them previously.

Then I restarted the Azure VM.

I launch the home page, the depencies get filled and there I found again the mention of these assemblies...but they are no more in the folder where they are found by the dependency builder ?

The disk management of AWS is a very strange thing ?
Apr 5, 2013 at 2:07 PM
Try to profile it using the miniprofiler orchard module.
Apr 5, 2013 at 4:58 PM
From a fast review I had on it, this is a very code-intrusive tool dedicated to contentitems and Nhibernate SQL transactions.

Rather than directly diving into this level of detail I would prefer to understand why Orchard is generating bad dependencies files.

When I go using FTP to the folder where should reside some on the referenced assemblies I don't find them.

I suspect an Azure bug and as I am a little short in time, I will start a new VM, not using AWS.
Apr 5, 2013 at 5:38 PM
I will do a try with log4net tracing as explained by Bertrand/Sebastien just before switching to Azure VM.
Apr 5, 2013 at 8:32 PM
Edited Apr 5, 2013 at 8:41 PM
Totally disapointed, the log4net Nhibernate trace show a massive amount of SQL calls just to display the Home page, it confirms teh 1,5 minute generation time for the page :(
The compute time seems very long, I attached the logs for 1 page generation later.

Next I do a try tracing the NHibernate cache, it look working, but why all these calls are so long if their result is in cache....syscache seems very slow.

Next I tried to improve caching through increasing delay in Contrib.cache and discovered it doesn't work at all, unable to cache any page, especially this long loading and building home page which is totally static but using a bootstrap carousel implemented thorugh a projection.

So I resign and reinstall all this on a VM, there is some problem in my configuration of Orchard versus Azure Web Sites.

Log too long to be inserted here near 500 db call for one page !!!
Apr 5, 2013 at 9:55 PM
Edited Apr 5, 2013 at 10:02 PM
I stopped the server 1 hour then restarted it and the cache start working....there is for sure a pb with storage, the running environnement is not necessarly the one you see connected with ftp and recently published.

Loading time shut down from 1,5 minute to 4s seconds with cache, the warmup start options must be set and consumme regularly compute avoid the 1,5 minute.

.... thanks to the great Azure Architect
Apr 6, 2013 at 1:32 AM
500 calls for a page is not normal, and cache should definitely work. We have lots of Orchard sites on Azure, and they show nothing of the sort. You need to analyze those profiles to understand what in your particular configuration is causing this.
Apr 6, 2013 at 7:48 AM
Edited Apr 6, 2013 at 7:49 AM
Yes that is also my understanding, but what is clear is that the analysis is beyond the scope of Log4net: trace points are missing (generally too few in Orchard on my opinion, that's cultural) to dive further.
Using a better tool, may be miniprofiler necessitates an effort of learning and installing.

A partial explanation is the usage of an ajax call loading a contact widget, but it can't explain the 500+, I will look at my code.

But the number of calls for one page is only a part of my problem, I still don't understand what has been happening with the HDD of the Azure VM, Orchard was collecting assemblies not present on the disk I was looking at with the FTP access. Seems there was a version delay, my web deploy was pushing something but Orchard was using an older version, some older miror disk not updated in time by the web-deploy.
I would appreciate learning more on the way MS AWS manages disk allocation.
Apr 6, 2013 at 8:19 PM
Edited Apr 6, 2013 at 8:20 PM
As a complement, it is clear that the side effect of having a table by part and to create content items by assembling parts is a possible multiplication of db reads .
Apr 6, 2013 at 10:47 PM
Frankly the effort for learning and installing miniprofiler is minimal. Knowing how to profile should be part of the toolbox of any developer, so you're doing yourself a favor. If miniprofiler is not enough, you can also try deeper tools such as those from JetBrains. They are quite easy to use as well.

Of course having a table per part results in more db calls. You have to choose if you want to use a CMS or a monolithic application. Frankly, both choices are legitimate, depending on what you are trying to achieve. But what you can't do is choose flexibility and then complain that there is a price to pay. Fortunately, caching alleviates most of that price, if used properly.
Apr 7, 2013 at 12:16 AM
It's clear that the last CMS project I had to work on was totally diiferent, everything was buit to have a minimal number of transactions with DB with minimal payload and using intensively store procedures, exclusively SQL Server.
We were using one trace statement for 4 code lines (depending code), first using Log4net then replacing it by something faster and more efficient related to the number of trace point. Nothing was dynamic as in Orchard.

Back to this 500 calls, problem is not profiling but understanding why 500, log4net bring an intresting trace but not very easy to read due to NHibernate parameters naming. As soon as I get time I will give a try on it and certainly miniprofiler :)

Have you any idea on the level of DB call generated by the main Orchard modules ( autoroute, CommonParts, Fields, ArchiveLater,projections, taxonomies, localization,Menus, widgets, layers ) ?
Apr 7, 2013 at 12:42 AM
Yes, you are only going to understand why you are getting 500 calls by profiling. Number of DB calls entirely depends on what you are doing. It can be as low as zero, and as high as tens of thousands, if you have a badly designed module that causes select N+1 problems, which is most likely what you're seeing here. Miniprofiler is pretty good at spotting those as it gives you the number of times a given query was done, which is a good smell of a select N+1 problem.
Apr 7, 2013 at 2:47 AM
500 seems high, I haven't seen anything in core cause that many db hits. I caused an N+1 situation that had a similar amount of db hits (630) in my app a while back, and I found and eliminated the problem by using the miniprofiler module. It's very easy to use. You just enable it and it adds some UI elements on the client side, telling you what queries are running, and how many times, how long they took, etc.

Yes, due to the way Orchard is designed it can have a lot of database calls, but so far it hasn't been a problem. My apps run pretty fast, with sub 500ms response times for some pretty complex pages. In one special case I had to write custom caching for certain data. That was also easy using the caching API's within Orchard. If you know how to write web apps you can fix any issues that might remain after you enable the NHibernate caching module and the Contrib.Cache module.
Apr 8, 2013 at 5:54 PM
500 requests. What are those requests ? There must be some pattern occurring, what tables are the most hit, with what kind of query ?
If you give us an example maybe it can ring a bell and we could explain where they are coming from.