Actually it depends. See http://stackoverflow.com/questions/256188/how-much-memory-does-a-thread-consume-when-first-created
Cheers John On May 6, 6:20 pm, Ayende Rahien <[email protected]> wrote: > Spinning a new thread per reuqest > > On Thu, May 6, 2010 at 11:10 AM, Ken Egozi <[email protected]> wrote: > > Ayende - you can't say "That" without stating what "that" means :) > > > On Thu, May 6, 2010 at 9:57 AM, Ayende Rahien <[email protected]> wrote: > > >> That means that each request consumes at least 1MB of memory, and it > >> introduce a lot of contention. > > >> On Thu, May 6, 2010 at 9:24 AM, Ken Egozi <[email protected]> wrote: > > >>> well, my suggestion was to avoid spawning a new thread for each request. > >>> option 4 is much easier to handle, has less potential multi-threading > >>> issues, is more robust and consume less resources. > > >>> On Wed, May 5, 2010 at 10:22 PM, jake <[email protected]> wrote: > > >>>> Thanks for the input everyone, I'll probably go with Egozi's > >>>> suggestion and try using multiple threads, I don't know if I need a > >>>> queue yet since the number of requests is relatively low, I might have > >>>> to when the actions starts picking up. Hopefully I won't kill my site > >>>> by spawning too many threads. > > >>>> Thanks, > >>>> Jake > > >>>> On May 4, 5:18 am, Jason Meckley <[email protected]> wrote: > >>>> > any time I need offline processing I use a windows service with a > >>>> > service bus communicating between the web and service. I favor > >>>> > Rhino.ServiceBus, but I hear NServiceBus and MassTransit have the same > >>>> > feature set. > > >>>> > On May 4, 2:07 am, Ken Egozi <[email protected]> wrote: > > >>>> > > I'd store the job in some form of a persistent queue (msmq, ESENT, > >>>> RDBMS, > >>>> > > filesystem, whatever), have SOMETHING (see below) process that > >>>> offline, and > >>>> > > move to "Done" queue. Then have another page serve the "Done" stuff > >>>> to the > >>>> > > users. > > >>>> > > as for the offline processor - you have three main options: > >>>> > > 1. spawn a thread for each "process" request - this could be > >>>> dangerous from > >>>> > > stability standpoint (threads can be aborted by the environment) and > >>>> will > >>>> > > probably create too many threads anyway > >>>> > > 2. If you have access to the machine and can setup a scheduled task > >>>> that > >>>> > > process the queue - that's cool > >>>> > > 3. Expose an endpoint in the web app, that will get pinged every X > >>>> seconds > >>>> > > from a scheduled task at a computer you CAN control, initiating > >>>> "process up > >>>> > > to Y items from the queue" on every call. > >>>> > > 4. setup a single worker thread spawned on App_Start, that will > >>>> wait for a > >>>> > > ManualResetEvent or something from the queue operation to kick in. > > >>>> > > I'd avoid 1. > >>>> > > 4. is pretty straightforward and self maintaining if you do the > >>>> > > multithreading part well enough. Get someone who knows his way there > >>>> for > >>>> > > code review as it could turn to nasty stuff easily. > >>>> > > 2. is the most scalable option, but you need to make sure the > >>>> scheduled task > >>>> > > (or windows service, whatever) do not get stuck, gets restarted if > >>>> it's > >>>> > > blown away or something, etc. > >>>> > > 3. is pretty easy, but is does require some other machine to ping > >>>> the app, > >>>> > > and you're back the need to make sure this runs even when you're on > >>>> vacation > >>>> > > or something. > > >>>> > > On Tue, May 4, 2010 at 5:50 AM, John Simons < > >>>> [email protected]>wrote: > > >>>> > > > Jake, > > >>>> > > > This is the way I previously dealt with this kind of situation: > >>>> > > > - On the controller action method *spawn* another thread and do > >>>> the report > >>>> > > > generation there (see note about this) or if you have the > >>>> resources, do it > >>>> > > > out of iis process. > >>>> > > > - Tell the user that the report is being generated (wait 10min > >>>> blah blah > >>>> > > > ...) and maybe provice a url to the user to retrieve the report or > >>>> email the > >>>> > > > user the url once report has been created. > >>>> > > > - If the report is not user specific, provide a page with a list > >>>> of > >>>> > > > generated reports. > > >>>> > > > Regarding *spawn* another thread in iis process, be aware that > >>>> when an iis > >>>> > > > app pool refresh occurs, spawn threads are aborted and it could > >>>> leave your > >>>> > > > report generation in an unknown state hence the reason to do it > >>>> out of iis > >>>> > > > process. > > >>>> > > > Let me know if you need more details. > > >>>> > > > Cheers > >>>> > > > John > > >>>> > > > ------------------------------ > >>>> > > > *From:* jake <[email protected]> > >>>> > > > *To:* Castle Project Users <[email protected] > > >>>> > > > *Sent:* Tue, 4 May, 2010 10:20:17 AM > >>>> > > > *Subject:* Job processing with monorail > > >>>> > > > I have a page that generates a PDF report and serves it in the > >>>> > > > response. Overtime, the report has gotten more and more complex > >>>> to > >>>> > > > the point that it sometimes takes a while to generate. I'd like > >>>> to > >>>> > > > create a job processing class that I can use so that when users > >>>> kick > >>>> > > > off the process I can just tell them to check back in 5 mins when > >>>> it's > >>>> > > > ready. It's inevitable that the report will start timing out > >>>> because > >>>> > > > of the amount of content the customer wants. What would be the > >>>> best > >>>> > > > way to tackle this, using Monorail of course? I'd like to keep > >>>> all > >>>> > > > the code in the web app if I could. > > >>>> > > > Thanks, > >>>> > > > Jake > > >>>> > > > -- > >>>> > > > You received this message because you are subscribed to the Google > >>>> Groups > >>>> > > > "Castle Project Users" group. > >>>> > > > To post to this group, send email to > >>>> [email protected] > >>>> > > > . > >>>> > > > To unsubscribe from this group, send email to > >>>> castle-project-users+ > >>>> > > > [email protected]. > >>>> > > > For more options, visit this group at > >>>> > > >http://groups.google.com/group/castle-project-users?hl=en. > > >>>> > > > -- > >>>> > > > You received this message because you are subscribed to the Google > >>>> Groups > >>>> > > > "Castle Project Users" group. > >>>> > > > To post to this group, send email to > >>>> [email protected] > >>>> > > > . > >>>> > > > To unsubscribe from this group, send email to > >>>> > > > [email protected]<castle-project-users%[email protected]><castle-project-users%2Bun > >>>> [email protected]> > >>>> > > > . > >>>> > > > For more options, visit this group at > >>>> > > >http://groups.google.com/group/castle-project-users?hl=en. > > >>>> > > -- > >>>> > > Ken Egozi. > >>>>http://www.kenegozi.com/bloghttp://www.delver.comhttp://www.musicglue...כנס > >>>> הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם > > >>>> > > -- > >>>> > > You received this message because you are subscribed to the Google > >>>> Groups "Castle Project Users" group. > >>>> > > To post to this group, send email to > >>>> [email protected]. > >>>> > > To unsubscribe from this group, send email to > >>>> [email protected]<castle-project-users%[email protected]> > >>>> . > >>>> > > For more options, visit this group athttp:// > >>>> groups.google.com/group/castle-project-users?hl=en. > > >>>> > -- > >>>> > You received this message because you are subscribed to the Google > >>>> Groups "Castle Project Users" group. > >>>> > To post to this group, send email to > >>>> [email protected]. > >>>> > To unsubscribe from this group, send email to > >>>> [email protected]<castle-project-users%[email protected]> > >>>> . > >>>> > For more options, visit this group athttp:// > >>>> groups.google.com/group/castle-project-users?hl=en. > > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "Castle Project Users" group. > >>>> To post to this group, send email to > >>>> [email protected]. > >>>> To unsubscribe from this group, send email to > >>>> [email protected]<castle-project-users%[email protected]> > >>>> . > >>>> For more options, visit this group at > >>>>http://groups.google.com/group/castle-project-users?hl=en. > > >>> -- > >>> Ken Egozi. > > >>>http://www.kenegozi.com/blog > >>>http://www.delver.com > >>>http://www.musicglue.com > >>>http://www.castleproject.org > >>>http://www.idcc.co.il- הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם > > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "Castle Project Users" group. > >>> To post to this group, send email to > >>> [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]<castle-project-users%[email protected]> > >>> . > >>> For more options, visit this group at > >>>http://groups.google.com/group/castle-project-users?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Castle Project Users" group. > >> To post to this group, send email to > >> [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<castle-project-users%[email protected]> > >> . > > >> For more options, visit this group at > >>http://groups.google.com/group/castle-project-users?hl=en. > > > -- > > Ken Egozi. > >http://www.kenegozi.com/blog > >http://www.delver.com > >http://www.musicglue.com > >http://www.castleproject.org > >http://www.idcc.co.il- הכנס הקהילתי הראשון > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
