[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