Re: Anyone know why the ISAPI redirector works how it does?
OK, I've done a bit more digging. From what I've read about ISAPI it seems that thread exhaustion can be a problem both for filters /and/ extensions[1]. The advice on this page /is/ to avoid filters, but I assume that's just because filters will be invoked for every request -- unfortunately that's unavoidable for the Tomcat connector because we need to see every request in case Tomcat can handle it. So, currently we have a filter that delegates to an extension, both in the same DLL. If extensions execute in a different thread pool from filters it's possible that this helps performance, but it's not clear from the MS documentation that this is the case. What MS do specifically say is that, in cases where a filter or extension may block for any length of time the blocking part should run in a seperate thread so that IIS doesn't get thread starved -- this makes sense, and suggests that the correct performance oriented architecture for the IIS connector should be a filter (with an optimized 'straight throw' path) which delegates Tomcat requests not to an ISAPI extension but to a worker thread taken from a pool that is internal to the connector. This is more complex than what I had in mind, but I'm prepared to give it a try. Before I do, does anyone have any empirical evidence about what works best with IIS? [1] http://msdn.microsoft.com/library/default.asp? \ url=/library/en-us/iisref/html/psdk/asp/perf4vsj.asp Ignacio J. Ortega wrote: So, +1 for trying a different approach without breaking what's already there? My swahili is at times hard to understand :)) Yes i'm +1 on trying what you are proposing in another place on jtc tree and leaving iis as it is now.. I'm really courious about what you find .. every bit of performance is welcomed ever .. so if there is a bit waiting for tomcat lets catch it ..:)) i recall that i'd found the same architecture in other ISAPI modules like resin... Saludos , Ignacio J. Ortega -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
I don't have any problem with the experiment, and couldn't stop the *experiment* even if I wanted to. By all means, scratch the itch. I am curious though, what it takes to cause the thread starvation in a normal environment (what ever that is). Adding the complexity of a thread pool will slow down processing by some amount in the non-starved case. For the case where thread starvation is occurring, it stands to reason that we have *lots* of requests and lots more requests and threads than processors to throwing more threads probably won't improve the throughput for Tomcat requests. It might improve the throughput for the static pages served by IIS directly since those requests won't be stuck behind potentially long running servlet requests, but then only if those long running threads are blocked on I/O. Basically, throwing threads at a problem usually doesn't do much for performance. Still, I'd be interested to see how this experiment effects performance. Marc Saegesser -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 24, 2001 7:11 AM To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? OK, I've done a bit more digging. From what I've read about ISAPI it seems that thread exhaustion can be a problem both for filters /and/ extensions[1]. The advice on this page /is/ to avoid filters, but I assume that's just because filters will be invoked for every request -- unfortunately that's unavoidable for the Tomcat connector because we need to see every request in case Tomcat can handle it. So, currently we have a filter that delegates to an extension, both in the same DLL. If extensions execute in a different thread pool from filters it's possible that this helps performance, but it's not clear from the MS documentation that this is the case. What MS do specifically say is that, in cases where a filter or extension may block for any length of time the blocking part should run in a seperate thread so that IIS doesn't get thread starved -- this makes sense, and suggests that the correct performance oriented architecture for the IIS connector should be a filter (with an optimized 'straight throw' path) which delegates Tomcat requests not to an ISAPI extension but to a worker thread taken from a pool that is internal to the connector. This is more complex than what I had in mind, but I'm prepared to give it a try. Before I do, does anyone have any empirical evidence about what works best with IIS? [1] http://msdn.microsoft.com/library/default.asp? \ url=/library/en-us/iisref/html/psdk/asp/perf4vsj.asp Ignacio J. Ortega wrote: So, +1 for trying a different approach without breaking what's already there? My swahili is at times hard to understand :)) Yes i'm +1 on trying what you are proposing in another place on jtc tree and leaving iis as it is now.. I'm really courious about what you find .. every bit of performance is welcomed ever .. so if there is a bit waiting for tomcat lets catch it ..:)) i recall that i'd found the same architecture in other ISAPI modules like resin... Saludos , Ignacio J. Ortega -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
Marc Saegesser wrote: I don't have any problem with the experiment, and couldn't stop the *experiment* even if I wanted to. By all means, scratch the itch. I am curious though, what it takes to cause the thread starvation in a normal environment (what ever that is). Adding the complexity of a thread pool will slow down processing by some amount in the non-starved case. For the case where thread starvation is occurring, it stands to reason that we have *lots* of requests and lots more requests and threads than processors to throwing more threads probably won't improve the throughput for Tomcat requests. It might improve the throughput for the static pages served by IIS directly since those requests won't be stuck behind potentially long running servlet requests, but then only if those long running threads are blocked on I/O. Basically, throwing threads at a problem usually doesn't do much for performance. Still, I'd be interested to see how this experiment effects performance. Yeah, well I'm not entirely convinced myself. I'm guessing, from what I've read on the MS site, that IIS actually runs with quite a small, fixed size, pool of threads and relies on its ability to serve static content very quickly to ensure that this is adequate. As soon as you start executing (relatively) slow requests in threads from this pool you end up with most of the threads blocked. That's my reading anyway -- I might do some experiments to find out how many distinct threads IIS is using before I do anything else. I am prepared to believe that if IIS is tightly optimized for static content and runs with a thread pool that is only just large enough for its normal needs that this might be the case, though, like you, I'm a little sceptical. Marc Saegesser -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 24, 2001 7:11 AM To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? OK, I've done a bit more digging. From what I've read about ISAPI it seems that thread exhaustion can be a problem both for filters /and/ extensions[1]. The advice on this page /is/ to avoid filters, but I assume that's just because filters will be invoked for every request -- unfortunately that's unavoidable for the Tomcat connector because we need to see every request in case Tomcat can handle it. So, currently we have a filter that delegates to an extension, both in the same DLL. If extensions execute in a different thread pool from filters it's possible that this helps performance, but it's not clear from the MS documentation that this is the case. What MS do specifically say is that, in cases where a filter or extension may block for any length of time the blocking part should run in a seperate thread so that IIS doesn't get thread starved -- this makes sense, and suggests that the correct performance oriented architecture for the IIS connector should be a filter (with an optimized 'straight throw' path) which delegates Tomcat requests not to an ISAPI extension but to a worker thread taken from a pool that is internal to the connector. This is more complex than what I had in mind, but I'm prepared to give it a try. Before I do, does anyone have any empirical evidence about what works best with IIS? [1] http://msdn.microsoft.com/library/default.asp? \ url=/library/en-us/iisref/html/psdk/asp/perf4vsj.asp Ignacio J. Ortega wrote: So, +1 for trying a different approach without breaking what's already there? My swahili is at times hard to understand :)) Yes i'm +1 on trying what you are proposing in another place on jtc tree and leaving iis as it is now.. I'm really courious about what you find .. every bit of performance is welcomed ever .. so if there is a bit waiting for tomcat lets catch it ..:)) i recall that i'd found the same architecture in other ISAPI modules like resin... Saludos , Ignacio J. Ortega -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
(sorry to follow myself up, but I've just found some more evidence about this) Andy Armstrong wrote: [snip] Yeah, well I'm not entirely convinced myself. I'm guessing, from what I've read on the MS site, that IIS actually runs with quite a small, fixed size, pool of threads and relies on its ability to serve static content very quickly to ensure that this is adequate. As soon as you start executing (relatively) slow requests in threads from this pool you end up with most of the threads blocked. That's my reading anyway -- I might do some experiments to find out how many distinct threads IIS is using before I do anything else. I am prepared to believe that if IIS is tightly optimized for static content and runs with a thread pool that is only just large enough for its normal needs that this might be the case, though, like you, I'm a little sceptical. Hmm. Well, surprisingly, according to this page[1] the default thread pool size for IIS is 10 times the number of processors and the server doesn't do anything adaptive with this number though it can be changed in the registry. This number does seem surprisingly low -- I can see how, in cases where the server was handling a lot of traffic of which some was being delegated to Tomcat there could be starvation. [1] http://www.google.com/search?q=cache:2jnr72XWvVU: \ msdn.microsoft.com/componentresources/html/articles \ /ta/ta_030.asp+iis+thread+pool+sizehl=en -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
Again, threads don't improve performance, in fact they degrade performance and on some platforms (namely, Windows) they can degrade performance very quickly. Context switching between threads on Win32 is *really, really* expensive (several hundred instructions in kernel space). Without processors to back up the threads you can just end up wasting cycles switching between threads and not accomplishing real work. -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 24, 2001 9:18 AM To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? (sorry to follow myself up, but I've just found some more evidence about this) Andy Armstrong wrote: [snip] Yeah, well I'm not entirely convinced myself. I'm guessing, from what I've read on the MS site, that IIS actually runs with quite a small, fixed size, pool of threads and relies on its ability to serve static content very quickly to ensure that this is adequate. As soon as you start executing (relatively) slow requests in threads from this pool you end up with most of the threads blocked. That's my reading anyway -- I might do some experiments to find out how many distinct threads IIS is using before I do anything else. I am prepared to believe that if IIS is tightly optimized for static content and runs with a thread pool that is only just large enough for its normal needs that this might be the case, though, like you, I'm a little sceptical. Hmm. Well, surprisingly, according to this page[1] the default thread pool size for IIS is 10 times the number of processors and the server doesn't do anything adaptive with this number though it can be changed in the registry. This number does seem surprisingly low -- I can see how, in cases where the server was handling a lot of traffic of which some was being delegated to Tomcat there could be starvation. [1] http://www.google.com/search?q=cache:2jnr72XWvVU: \ msdn.microsoft.com/componentresources/html/articles \ /ta/ta_030.asp+iis+thread+pool+sizehl=en -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
Marc Saegesser wrote: Again, threads don't improve performance, in fact they degrade performance and on some platforms (namely, Windows) they can degrade performance very quickly. Context switching between threads on Win32 is *really, really* expensive (several hundred instructions in kernel space). Without processors to back up the threads you can just end up wasting cycles switching between threads and not accomplishing real work. Yes, understood. What surprised me was that it wouldn't dynamically throw new threads in the pool in the specific case where lots of threads where blocked which is what I assume happens quite a lot in a typical webserver -- Tomcat interaction. Extra threads are only compute intensive when they get scheduled -- if most of them are sleeping then they're relatively cheap. Of course it turns out, as I read more, than IIS /can/ dynamically throw new threads in the pool in that eventuality. I think the only way to bottom this out is for me to write some code to test it, but I do understand that more threads != more speed in the general case. I'm still unconvinced though that the current filter + extension connector architecture is likely to be any better than a filter only implementation on the basis of what I've read about the internals of IIS. Time to stop talking and start experimenting I think ;-) -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
Hi, I'm a new, late starter on this thread... My understanding is that IIS runs about 15 threads and for filters it runs it on one of the threads, and for extension procs it uses the model defined in the application setup of the virtual directory (Low [iis thread], Medium [pool thread], High [isolated, app specific threads]). From what I can see of the Tomcat code, because it has the Filter and Extension call backs in the same DLL it will always default to Low (ie. as a filter). My understanding is that the best way to do the IIS/Tomcat integration is tricky - but worth it. You would: o Have a separate filter to do the absolute minimum to check whether the URI is for a Servlet - this would run on the IIS thread and then direct it to the Exension Proc. o Have a separate DLL implementing the extension proc and have it run in the High protection model. o In the extension proc you would implement the asynch call back model where in simple terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own pool of threads to process the request by releasing the IIS thread and holding a ref to a callback sig function so that when Tomcat has finished it sigs back to IIS that it is complete and IIS then takes over again. This is the way ASP works and makes sure you never get the dreaded Server Busy response back to the client because the scarce IIS threads are exhausted. Apart from that, I haven't thought about it ;-) I'm happy to help... Cheers...Pete -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Sunday,24 June 2001 11:17 To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? Marc Saegesser wrote: I don't have any problem with the experiment, and couldn't stop the *experiment* even if I wanted to. By all means, scratch the itch. I am curious though, what it takes to cause the thread starvation in a normal environment (what ever that is). Adding the complexity of a thread pool will slow down processing by some amount in the non-starved case. For the case where thread starvation is occurring, it stands to reason that we have *lots* of requests and lots more requests and threads than processors to throwing more threads probably won't improve the throughput for Tomcat requests. It might improve the throughput for the static pages served by IIS directly since those requests won't be stuck behind potentially long running servlet requests, but then only if those long running threads are blocked on I/O. Basically, throwing threads at a problem usually doesn't do much for performance. Still, I'd be interested to see how this experiment effects performance. Yeah, well I'm not entirely convinced myself. I'm guessing, from what I've read on the MS site, that IIS actually runs with quite a small, fixed size, pool of threads and relies on its ability to serve static content very quickly to ensure that this is adequate. As soon as you start executing (relatively) slow requests in threads from this pool you end up with most of the threads blocked. That's my reading anyway -- I might do some experiments to find out how many distinct threads IIS is using before I do anything else. I am prepared to believe that if IIS is tightly optimized for static content and runs with a thread pool that is only just large enough for its normal needs that this might be the case, though, like you, I'm a little sceptical. Marc Saegesser -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 24, 2001 7:11 AM To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? OK, I've done a bit more digging. From what I've read about ISAPI it seems that thread exhaustion can be a problem both for filters /and/ extensions[1]. The advice on this page /is/ to avoid filters, but I assume that's just because filters will be invoked for every request -- unfortunately that's unavoidable for the Tomcat connector because we need to see every request in case Tomcat can handle it. So, currently we have a filter that delegates to an extension, both in the same DLL. If extensions execute in a different thread pool from filters it's possible that this helps performance, but it's not clear from the MS documentation that this is the case. What MS do specifically say is that, in cases where a filter or extension may block for any length of time the blocking part should run in a seperate thread so that IIS doesn't get thread starved -- this makes sense, and suggests that the correct performance oriented architecture for the IIS connector should be a filter (with an optimized 'straight throw' path) which delegates Tomcat requests not to an ISAPI extension but to a worker thread taken from a pool that is internal to the connector. This is more complex than what I had in mind, but I'm prepared to give
Re: Anyone know why the ISAPI redirector works how it does?
[EMAIL PROTECTED] wrote: Hi, I'm a new, late starter on this thread... My understanding is that IIS runs about 15 threads and for filters it runs it on one of the threads, and for extension procs it uses the model defined in the application setup of the virtual directory (Low [iis thread], Medium [pool thread], High [isolated, app specific threads]). From what I can see of the Tomcat code, because it has the Filter and Extension call backs in the same DLL it will always default to Low (ie. as a filter). My understanding is that the best way to do the IIS/Tomcat integration is tricky - but worth it. You would: o Have a separate filter to do the absolute minimum to check whether the URI is for a Servlet - this would run on the IIS thread and then direct it to the Exension Proc. o Have a separate DLL implementing the extension proc and have it run in the High protection model. o In the extension proc you would implement the asynch call back model where in simple terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own pool of threads to process the request by releasing the IIS thread and holding a ref to a callback sig function so that when Tomcat has finished it sigs back to IIS that it is complete and IIS then takes over again. This is the way ASP works and makes sure you never get the dreaded Server Busy response back to the client because the scarce IIS threads are exhausted. Apart from that, I haven't thought about it ;-) Not much ;-) I'm surprised that it can choose which thread to use for filters -- is it not the case that filters are just called in the context of whichever thread is handling a particular request? I seem to be committed now to finding out empirically what's going on inside IIS and which approach will yield the best performance, both for requests delegated to Tomcat and for everything else the server's doing. I'll be sure to try the approach you suggest -- it certainly sounds reasonable. -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
You're right - it can't for filters - hence why it defaults to Low. A word of advice, if you are doing this on Win2K you also get into some hairy security issues and what is happenning under IUSR, IWAM etc. accounts. Keep it in mind if you start to see some strange behaviour in you tests. Cheers...Pete -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Monday,25 June 2001 8:04 To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? [EMAIL PROTECTED] wrote: Hi, I'm a new, late starter on this thread... My understanding is that IIS runs about 15 threads and for filters it runs it on one of the threads, and for extension procs it uses the model defined in the application setup of the virtual directory (Low [iis thread], Medium [pool thread], High [isolated, app specific threads]). From what I can see of the Tomcat code, because it has the Filter and Extension call backs in the same DLL it will always default to Low (ie. as a filter). My understanding is that the best way to do the IIS/Tomcat integration is tricky - but worth it. You would: o Have a separate filter to do the absolute minimum to check whether the URI is for a Servlet - this would run on the IIS thread and then direct it to the Exension Proc. o Have a separate DLL implementing the extension proc and have it run in the High protection model. o In the extension proc you would implement the asynch call back model where in simple terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own pool of threads to process the request by releasing the IIS thread and holding a ref to a callback sig function so that when Tomcat has finished it sigs back to IIS that it is complete and IIS then takes over again. This is the way ASP works and makes sure you never get the dreaded Server Busy response back to the client because the scarce IIS threads are exhausted. Apart from that, I haven't thought about it ;-) Not much ;-) I'm surprised that it can choose which thread to use for filters -- is it not the case that filters are just called in the context of whichever thread is handling a particular request? I seem to be committed now to finding out empirically what's going on inside IIS and which approach will yield the best performance, both for requests delegated to Tomcat and for everything else the server's doing. I'll be sure to try the approach you suggest -- it certainly sounds reasonable. -- Andy Armstrong, Tagish -- This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy the message or disclose its contents to anyone.
RE: Anyone know why the ISAPI redirector works how it does?
Hola a todos, Peter: It seems from your messages that the actual architecture of the isapi plugin is another form of the only filter solution ? A easy way to solve it can be to simply separate the filter part from the extension part of the isapi plugin without adding the thread pool? could let us to run the extension in medium mode?...no need in a first step to create the internal thread pool.. later we can add this capacity .. What do you think ? , this can be a middle ground attack to the problem?? Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: lunes 25 de junio de 2001 0:26 Para: [EMAIL PROTECTED] Asunto: RE: Anyone know why the ISAPI redirector works how it does? You're right - it can't for filters - hence why it defaults to Low. A word of advice, if you are doing this on Win2K you also get into some hairy security issues and what is happenning under IUSR, IWAM etc. accounts. Keep it in mind if you start to see some strange behaviour in you tests. Cheers...Pete -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Monday,25 June 2001 8:04 To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? [EMAIL PROTECTED] wrote: Hi, I'm a new, late starter on this thread... My understanding is that IIS runs about 15 threads and for filters it runs it on one of the threads, and for extension procs it uses the model defined in the application setup of the virtual directory (Low [iis thread], Medium [pool thread], High [isolated, app specific threads]). From what I can see of the Tomcat code, because it has the Filter and Extension call backs in the same DLL it will always default to Low (ie. as a filter). My understanding is that the best way to do the IIS/Tomcat integration is tricky - but worth it. You would: o Have a separate filter to do the absolute minimum to check whether the URI is for a Servlet - this would run on the IIS thread and then direct it to the Exension Proc. o Have a separate DLL implementing the extension proc and have it run in the High protection model. o In the extension proc you would implement the asynch call back model where in simple terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own pool of threads to process the request by releasing the IIS thread and holding a ref to a callback sig function so that when Tomcat has finished it sigs back to IIS that it is complete and IIS then takes over again. This is the way ASP works and makes sure you never get the dreaded Server Busy response back to the client because the scarce IIS threads are exhausted. Apart from that, I haven't thought about it ;-) Not much ;-) I'm surprised that it can choose which thread to use for filters -- is it not the case that filters are just called in the context of whichever thread is handling a particular request? I seem to be committed now to finding out empirically what's going on inside IIS and which approach will yield the best performance, both for requests delegated to Tomcat and for everything else the server's doing. I'll be sure to try the approach you suggest -- it certainly sounds reasonable. -- Andy Armstrong, Tagish -- This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy the message or disclose its contents to anyone.
RE: Anyone know why the ISAPI redirector works how it does?
That would work in the first instance. I also have some metabase management code to set this up properly for an auto installer - let me know if you want it. Cheers...Pete -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] Sent: Monday,25 June 2001 8:53 To: '[EMAIL PROTECTED]' Subject: RE: Anyone know why the ISAPI redirector works how it does? Hola a todos, Peter: It seems from your messages that the actual architecture of the isapi plugin is another form of the only filter solution ? A easy way to solve it can be to simply separate the filter part from the extension part of the isapi plugin without adding the thread pool? could let us to run the extension in medium mode?...no need in a first step to create the internal thread pool.. later we can add this capacity .. What do you think ? , this can be a middle ground attack to the problem?? Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: lunes 25 de junio de 2001 0:26 Para: [EMAIL PROTECTED] Asunto: RE: Anyone know why the ISAPI redirector works how it does? You're right - it can't for filters - hence why it defaults to Low. A word of advice, if you are doing this on Win2K you also get into some hairy security issues and what is happenning under IUSR, IWAM etc. accounts. Keep it in mind if you start to see some strange behaviour in you tests. Cheers...Pete -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Monday,25 June 2001 8:04 To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? [EMAIL PROTECTED] wrote: Hi, I'm a new, late starter on this thread... My understanding is that IIS runs about 15 threads and for filters it runs it on one of the threads, and for extension procs it uses the model defined in the application setup of the virtual directory (Low [iis thread], Medium [pool thread], High [isolated, app specific threads]). From what I can see of the Tomcat code, because it has the Filter and Extension call backs in the same DLL it will always default to Low (ie. as a filter). My understanding is that the best way to do the IIS/Tomcat integration is tricky - but worth it. You would: o Have a separate filter to do the absolute minimum to check whether the URI is for a Servlet - this would run on the IIS thread and then direct it to the Exension Proc. o Have a separate DLL implementing the extension proc and have it run in the High protection model. o In the extension proc you would implement the asynch call back model where in simple terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own pool of threads to process the request by releasing the IIS thread and holding a ref to a callback sig function so that when Tomcat has finished it sigs back to IIS that it is complete and IIS then takes over again. This is the way ASP works and makes sure you never get the dreaded Server Busy response back to the client because the scarce IIS threads are exhausted. Apart from that, I haven't thought about it ;-) Not much ;-) I'm surprised that it can choose which thread to use for filters -- is it not the case that filters are just called in the context of whichever thread is handling a particular request? I seem to be committed now to finding out empirically what's going on inside IIS and which approach will yield the best performance, both for requests delegated to Tomcat and for everything else the server's doing. I'll be sure to try the approach you suggest -- it certainly sounds reasonable. -- Andy Armstrong, Tagish -- This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy the message or disclose its contents to anyone. -- This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy the message or disclose its contents to anyone.
Re: Anyone know why the ISAPI redirector works how it does?
Thanks Pete -- I'll watch for that. I've already had some experience of this sort of thing. Not nice. [EMAIL PROTECTED] wrote: You're right - it can't for filters - hence why it defaults to Low. A word of advice, if you are doing this on Win2K you also get into some hairy security issues and what is happenning under IUSR, IWAM etc. accounts. Keep it in mind if you start to see some strange behaviour in you tests. Cheers...Pete -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Monday,25 June 2001 8:04 To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? [EMAIL PROTECTED] wrote: Hi, I'm a new, late starter on this thread... My understanding is that IIS runs about 15 threads and for filters it runs it on one of the threads, and for extension procs it uses the model defined in the application setup of the virtual directory (Low [iis thread], Medium [pool thread], High [isolated, app specific threads]). From what I can see of the Tomcat code, because it has the Filter and Extension call backs in the same DLL it will always default to Low (ie. as a filter). My understanding is that the best way to do the IIS/Tomcat integration is tricky - but worth it. You would: o Have a separate filter to do the absolute minimum to check whether the URI is for a Servlet - this would run on the IIS thread and then direct it to the Exension Proc. o Have a separate DLL implementing the extension proc and have it run in the High protection model. o In the extension proc you would implement the asynch call back model where in simple terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own pool of threads to process the request by releasing the IIS thread and holding a ref to a callback sig function so that when Tomcat has finished it sigs back to IIS that it is complete and IIS then takes over again. This is the way ASP works and makes sure you never get the dreaded Server Busy response back to the client because the scarce IIS threads are exhausted. Apart from that, I haven't thought about it ;-) Not much ;-) I'm surprised that it can choose which thread to use for filters -- is it not the case that filters are just called in the context of whichever thread is handling a particular request? I seem to be committed now to finding out empirically what's going on inside IIS and which approach will yield the best performance, both for requests delegated to Tomcat and for everything else the server's doing. I'll be sure to try the approach you suggest -- it certainly sounds reasonable. -- Andy Armstrong, Tagish -- This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy the message or disclose its contents to anyone. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
[EMAIL PROTECTED] wrote: That would work in the first instance. I also have some metabase management code to set this up properly for an auto installer - let me know if you want it. Cheers...Pete I'm sure that'll be useful -- the setup could usefully be more automated. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
well, i've never even looked at the iis connector, and i am by no means an isapi expert, but what you describe does sound odd... i was under the impression that the isapi filter was doing all of the work. didn't know there was an extension involved as well. perhaps you can, instead of mucking with the existing iis connector, just create a new one that uses only HttpFilterProc. that'd be cool with me :) Andy Armstrong wrote: I've been looking at the source of the ISAPI redirector (initially to get it to build again -- it seems to have broken), and wondering why it works the way it does. It provides both an HttpFilterProc and an HttpExtensionProc. The HttpFilterProc looks for incoming requests that are elligable to be handled by Tomcat and, if it finds one, it rewrites the request so that it will be passed to the HttpExtensionProc for processing. From a cursory glance at the ISAPI documentation it seems that this could all be handled in HttpFilterProc. Does anyone know what I'm missing? If there isn't a clear reason why it's implemented like this I might try and build a new ISAPI filter that works the same way as the Domino DSAPI filter. It should make request handling slightly faster, simplify the code and might make it possible to have some source in common between the Domino and IIS redirectors. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
kevin seguin wrote: well, i've never even looked at the iis connector, and i am by no means an isapi expert, but what you describe does sound odd... i was under the impression that the isapi filter was doing all of the work. didn't know there was an extension involved as well. It's not a big deal -- just two entry points into the same DLL, so you wouldn't notice from outside, but it does seem a bit odd. perhaps you can, instead of mucking with the existing iis connector, just create a new one that uses only HttpFilterProc. that'd be cool with me :) I'll give it a go. It might be next week unless I go to the office and grab a box to make into an IIS server for home. Still, what else are weekends for. -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
I think this was done this way because every request on a IIS server pass the entire Filter Chain, so a request that takes longer to be served simply occupies the server thread more than necesssary , I'm -1 for this change ... Saludos , Ignacio J. Ortega -Mensaje original- De: Andy Armstrong [mailto:[EMAIL PROTECTED]] Enviado el: sábado 23 de junio de 2001 20:02 Para: Tomcat Dev Cc: Gal Shachor Asunto: Anyone know why the ISAPI redirector works how it does? I've been looking at the source of the ISAPI redirector (initially to get it to build again -- it seems to have broken), and wondering why it works the way it does. It provides both an HttpFilterProc and an HttpExtensionProc. The HttpFilterProc looks for incoming requests that are elligable to be handled by Tomcat and, if it finds one, it rewrites the request so that it will be passed to the HttpExtensionProc for processing. From a cursory glance at the ISAPI documentation it seems that this could all be handled in HttpFilterProc. Does anyone know what I'm missing? If there isn't a clear reason why it's implemented like this I might try and build a new ISAPI filter that works the same way as the Domino DSAPI filter. It should make request handling slightly faster, simplify the code and might make it possible to have some source in common between the Domino and IIS redirectors. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
Yes, but at the moment every IIS request gets passed to the filter chain /and/ to the extension. What I'm proposing /must/ be faster. Please explain your objection. Ignacio J. Ortega wrote: I think this was done this way because every request on a IIS server pass the entire Filter Chain, so a request that takes longer to be served simply occupies the server thread more than necesssary , I'm -1 for this change ... Saludos , Ignacio J. Ortega -Mensaje original- De: Andy Armstrong [mailto:[EMAIL PROTECTED]] Enviado el: sábado 23 de junio de 2001 20:02 Para: Tomcat Dev Cc: Gal Shachor Asunto: Anyone know why the ISAPI redirector works how it does? I've been looking at the source of the ISAPI redirector (initially to get it to build again -- it seems to have broken), and wondering why it works the way it does. It provides both an HttpFilterProc and an HttpExtensionProc. The HttpFilterProc looks for incoming requests that are elligable to be handled by Tomcat and, if it finds one, it rewrites the request so that it will be passed to the HttpExtensionProc for processing. From a cursory glance at the ISAPI documentation it seems that this could all be handled in HttpFilterProc. Does anyone know what I'm missing? If there isn't a clear reason why it's implemented like this I might try and build a new ISAPI filter that works the same way as the Domino DSAPI filter. It should make request handling slightly faster, simplify the code and might make it possible to have some source in common between the Domino and IIS redirectors. -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
AFAIK only the request that need to be served by the Extension , that is request that match the config present in UWM.P file are routed to the extension , that runs in other priority thread, if you serve the Tomcat request directly from the filter therad you are blocking the filter thread in Tomcat.., and i repeat *ALL* the request served by an IIS server are passed to ALL the filters..not only the Tomcat one.. so if the ISAPI extension were working like you are proposing you are blocking the main server thread waiting for tomcat to serve the request, many unrelated request will be slowed appreciably and the overall capacity of the server will be greatly impacted... I think there are good reasons to keep things as they are now...i dont found a good reason , apart from code complexity , to do what you are proposing ..but i'm not a ISAPI expert...I could be wrong.. i'm only repeating to you the reasons Gal said to my many time ago.. you can consult archives about May past year .. (i'm doing so now i wil try to document it ) But i'm open to test and help in what you are proposing .. i'm not trying to block you from doing so .. i'm only trying to left the old code as it is, you can do what you are proposing in another directory in jtc and call it with a funny name ( IISTHAR ? :), and we can test and use it as an alternative .. if everything works as you expect .. good .. if not we still have that good old code ... users need a escape way from developers. :) Saludos , Ignacio J. Ortega -Mensaje original- De: Andy Armstrong [mailto:[EMAIL PROTECTED]] Enviado el: domingo 24 de junio de 2001 1:18 Para: [EMAIL PROTECTED] Asunto: Re: Anyone know why the ISAPI redirector works how it does? Yes, but at the moment every IIS request gets passed to the filter chain /and/ to the extension. What I'm proposing /must/ be faster. Please explain your objection. Ignacio J. Ortega wrote: I think this was done this way because every request on a IIS server pass the entire Filter Chain, so a request that takes longer to be served simply occupies the server thread more than necesssary , I'm -1 for this change ... Saludos , Ignacio J. Ortega -Mensaje original- De: Andy Armstrong [mailto:[EMAIL PROTECTED]] Enviado el: sábado 23 de junio de 2001 20:02 Para: Tomcat Dev Cc: Gal Shachor Asunto: Anyone know why the ISAPI redirector works how it does? I've been looking at the source of the ISAPI redirector (initially to get it to build again -- it seems to have broken), and wondering why it works the way it does. It provides both an HttpFilterProc and an HttpExtensionProc. The HttpFilterProc looks for incoming requests that are elligable to be handled by Tomcat and, if it finds one, it rewrites the request so that it will be passed to the HttpExtensionProc for processing. From a cursory glance at the ISAPI documentation it seems that this could all be handled in HttpFilterProc. Does anyone know what I'm missing? If there isn't a clear reason why it's implemented like this I might try and build a new ISAPI filter that works the same way as the Domino DSAPI filter. It should make request handling slightly faster, simplify the code and might make it possible to have some source in common between the Domino and IIS redirectors. -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
Ignacio J. Ortega wrote: AFAIK only the request that need to be served by the Extension , that is request that match the config present in UWM.P file are routed to the extension , that runs in other priority thread, if you serve the Tomcat request directly from the filter therad you are blocking the filter thread in Tomcat.., and i repeat *ALL* the request served by an IIS server are passed to ALL the filters..not only the Tomcat one.. so if the ISAPI extension were working like you are proposing you are blocking the main server thread waiting for tomcat to serve the request, many unrelated request will be slowed appreciably and the overall capacity of the server will be greatly impacted... Thanks Ignacio; I understand what you're saying now. If all the filters run in the same thread that implies that IIS handles all its requests in a single thread, which seems unlikely, but of course I could be wrong. I think there are good reasons to keep things as they are now...i dont found a good reason , apart from code complexity , to do what you are proposing ..but i'm not a ISAPI expert...I could be wrong.. i'm only repeating to you the reasons Gal said to my many time ago.. you can consult archives about May past year .. (i'm doing so now i wil try to document it ) I'd be interested in anything you can find. I don't expect it to involve too much work, so I'm going to build it and do some performance testing to find out if there are any problems. From what you're saying the performance problem to look for would be lots of Tomcat requests having an adverse affect on the performance for non-Tomcat IIS requests. But i'm open to test and help in what you are proposing .. i'm not trying to block you from doing so .. i'm only trying to left the old code as it is, you can do what you are proposing in another directory in jtc and call it with a funny name ( IISTHAR ? :), and we can test and use it as an alternative .. if everything works as you expect .. good .. if not we still have that good old code ... users need a escape way from developers. :) I'm putting it in a directory called 'isapi' and leaving 'iis' intact. In any case I have some more work to do on the existing IIS redirector to make it work properly with the latest jk code, but that's a separate issue, and I won't do anything too scary to the current IIS code. -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
Hola Andy: Thanks Ignacio; I understand what you're saying now. If all the filters run in the same thread that implies that IIS handles all its requests in a single thread, which seems unlikely, but of course I could be wrong. What i'm trying to say is not that, is evident that IIS does not serve all the request from the same thread .. only that every filter is called in ALL the IIS request.. ergo if you start to block server threads in tomcat requests you are pushing innecesarily the IIS server... at least the thread pool that is used to serve requests.. I'd be interested in anything you can find. I don't expect it to involve too much work, so I'm going to build it and do some performance testing to find out if there are any problems. From what you're saying the performance problem to look for would be lots of Tomcat requests having an adverse affect on the performance for non-Tomcat IIS requests. This is the bad behaviour the filter+Extension mix is trying to avoid.. I'm putting it in a directory called 'isapi' and leaving 'iis' intact. In any case I have some more work to do on the existing IIS redirector to make it work properly with the latest jk code, but that's a separate issue, and I won't do anything too scary to the current IIS code. Thanks, this is was my -1 was intended for.. -- Andy Armstrong, Tagish Saludos , Ignacio J. Ortega
Re: Anyone know why the ISAPI redirector works how it does?
Ignacio J. Ortega wrote: Hola Andy: Thanks Ignacio; I understand what you're saying now. If all the filters run in the same thread that implies that IIS handles all its requests in a single thread, which seems unlikely, but of course I could be wrong. What i'm trying to say is not that, is evident that IIS does not serve all the request from the same thread .. only that every filter is called in ALL the IIS request.. ergo if you start to block server threads in tomcat requests you are pushing innecesarily the IIS server... at least the thread pool that is used to serve requests.. I would have thought that IIS's threading model was designed to handle that. There must be other cases where an in-process request can stall for a significant period of time; can it really be the case that this causes problems for the server as a whole? In any case I suspect I am about to find out ;-) I'd be interested in anything you can find. I don't expect it to involve too much work, so I'm going to build it and do some performance testing to find out if there are any problems. From what you're saying the performance problem to look for would be lots of Tomcat requests having an adverse affect on the performance for non-Tomcat IIS requests. This is the bad behaviour the filter+Extension mix is trying to avoid.. I understand that. What I'm saying is that if I can detect any performance degradation for non-Tomcat requests I will have failed. I'm putting it in a directory called 'isapi' and leaving 'iis' intact. In any case I have some more work to do on the existing IIS redirector to make it work properly with the latest jk code, but that's a separate issue, and I won't do anything too scary to the current IIS code. Thanks, this is was my -1 was intended for.. So, +1 for trying a different approach without breaking what's already there? -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
So, +1 for trying a different approach without breaking what's already there? My swahili is at times hard to understand :)) Yes i'm +1 on trying what you are proposing in another place on jtc tree and leaving iis as it is now.. I'm really courious about what you find .. every bit of performance is welcomed ever .. so if there is a bit waiting for tomcat lets catch it ..:)) i recall that i'd found the same architecture in other ISAPI modules like resin... Saludos , Ignacio J. Ortega -- Andy Armstrong, Tagish
