[Mono-aspnet-list] Very slow website compilation

APS dev.malst at apsystems.it
Mon Oct 5 09:19:37 EDT 2009


Hi,

I tried your patch adding some other message and 
I found that the problem is inside 
private_file_needs_copying where there's a check 
on field st_mode of stat structure.
The problem is that in my installation the source 
file have not the same access rights of the 
shadow copy so mono copies the files everytime.
I can change access rights to source files but I 
think it's wrong to check the access mode because 
it's not a value that helps to understand if a 
file is up-to-date, size and mtime should be enough. Do you agree?
Another thing. I saw on the same function that at 
the first run after apache restart mono doesn't 
find the assembly in cache directoryì and it makes a copy.
This is because every time the service is stopped 
the user-temp-aspnet directory is cleaned. But in 
this way everytime we restart apache we need to 
wait the same loading time of the first time 
after site installation. Temporary files could be 
kept in cache directory in order to avoid 
reloading, this should dramatically increase mono asp.net loading time.
I think MS.NET act like this cause the second run 
after site installation is quicker than the first, in mono is everytime equal.

As for private_file_needs_copying I think it 
could be modified like this, hope this helps:

static gboolean
private_file_needs_copying (const char *src, struct stat *sbuf_src, char *dest)
{
         struct stat sbuf_dest;

         if (stat (src, sbuf_src) == -1 || stat (dest, &sbuf_dest) == -1)
                 return TRUE;
         if (sbuf_src->st_size == sbuf_dest.st_size &&
             sbuf_src->st_mtime == sbuf_dest.st_mtime)
                 return FALSE;
         return TRUE;
}


At 13.30 02/10/2009, Robert Jordan wrote:
>Hi,
>
>APS wrote:
>>and so on, for the thousands of files placed inside the bin directory.
>>It seems to me that there's some problem cause 
>>all the files seems missing even if they are 
>>there and it always redo the copying.
>>Most of the loading time is spent in this 
>>multiple shadow copying, as I have many 
>>assemblies inside bin directory this cause an 
>>heavy disk usage and many minutes of wait.
>
>The log message might be misleading: it is even emitted when
>the assembly was not actually shadow-copied due to mtime
>equality.
>
>Try the attached patch to see if the copy operations are
>actually skipped (grep for "up-to-date" in your logs).
>
>Robert
>
>--
>Il messaggio e' stato analizzato alla ricerca di virus o
>contenuti pericolosi da MailScanner, ed e'
>risultato non infetto.
>
>
>
>Index: metadata/appdomain.c
>===================================================================
>--- metadata/appdomain.c        (revision 142262)
>+++ metadata/appdomain.c        (working copy)
>@@ -1431,8 +1431,10 @@
>                 mono_raise_exception (exc);
>         }
>
>-       if (!private_file_needs_copying (filename, &src_sbuf, shadow))
>+       if (!private_file_needs_copying (filename, &src_sbuf, shadow)) {
>+               mono_trace (G_LOG_LEVEL_INFO, 
>MONO_TRACE_ASSEMBLY, "Shadow copy %s of %s is 
>up-to-date.\n", shadow, filename);
>                 return (char*) shadow;
>+       }
>
>         orig = g_utf8_to_utf16 (filename, 
> strlen (filename), NULL, NULL, NULL);
>         dest = g_utf8_to_utf16 (shadow, strlen (shadow), NULL, NULL, NULL);
>
>_______________________________________________
>Mono-aspnet-list mailing list
>Mono-aspnet-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-aspnet-list/attachments/20091005/d8bc840f/attachment.html 


More information about the Mono-aspnet-list mailing list