Menu
▾
▴
insomnia-httpd-devel
|
From: Alexander M. <al...@gm...> - 2003-05-14 16:03:53
|
The current way of handling internal redirects is done by throwing a RedirectedException, which reinitialises the handler enumeration again and iterates through all once more. I do not think this is the ideal way of doing it, so does anyone have suggestion about improving it? This applies to the prototype code at http://insomnia-httpd.sourceforge.net/insomnia.zip. Thanks, Alexander -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! |
|
From: <mpc...@li...> - 2003-05-14 16:49:35
|
Not got much time to look now but maybe multiple passes over the modules might be a good solution. modules needing to cause an internal redirect could modify the url during an earlier phase. say the "Request Manipulation" phase. (Modules could register an interest= in what phases they are interested in) If the modules needing to do redirects could register interest in being called during the request manipulation phase then no performance hit woul= d be taken for modules not needing to do internal redirects. The advantage with this phase approach where you don't do everything in one handle method - is that you wouldn't need to re-iterate the modules if the last module needs to do a redirect because the real handling get's= done a later phase. Later, Matt. >-- Original Message -- >From: Alexander Mueller <alexm> >To: ins...@li... >Subject: [insomnia-httpd-devel] Internal Redirects >Reply-To: ins...@li... >Date: Wed, 14 May 2003 18:03:42 +0200 (MEST) > >The current way of handling internal redirects is done by throwing a >RedirectedException, which reinitialises the handler enumeration again and >iterates >through all once more. I do not think this is the ideal way of doing it,= >so >does anyone have suggestion about improving it? > >This applies to the prototype code at >http://insomnia-httpd.sourceforge.net/insomnia.zip. > >Thanks, >Alexander > >-- >+++ GMX - Mail, Messaging & more http://www.gmx.net +++ >Bitte l=E4cheln! Fotogalerie online mit GMX ohne eigene Homepage! > > > >------------------------------------------------------- >Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >The only event dedicated to issues related to Linux enterprise solutions= >www.enterpriselinuxforum.com > >_______________________________________________ >insomnia-httpd-devel mailing list >ins...@li... >https://lists.sourceforge.net/lists/listinfo/insomnia-httpd-devel |
|
From: Alexander M. <al...@gm...> - 2003-05-14 23:36:12
|
> Not got much time to look now but maybe multiple passes over the modules > might be a good solution. modules needing to cause an internal redirect > could modify the url during an earlier phase. > say the "Request Manipulation" phase. (Modules could register an interest > in what phases they are interested in) > If the modules needing to do redirects could register interest in being > called during the request manipulation phase then no performance hit would > be taken for modules not needing to do internal redirects. > The advantage with this phase approach where you don't do everything in > one handle method - is that you wouldn't need to re-iterate the modules > if the last module needs to do a redirect because the real handling get's > done a later phase. > Later, > Matt. First of all, there is a new package of the prototype code at http://insomnia-httpd.sourceforge.net/insomnia.zip as I forgot to add the two module files :(. Thanks for notifying me Dana. Concerning this issue, having multiple phases sounds like a good idea, we just would need to define how many phases we need to have and in which point in the request process they should hook into. This might even solve the problem I mentioned earlier about the order upon we call the individual handlers (eg: GZIP has to run as absolute last one - unless there is some post-zip handler). Alexander |
|
From: Matthew C. <mpc...@li...> - 2003-05-22 12:32:31
|
I've been looking at insomnia today as I was working a bit on the range responses. Has anyone considered the Java 1.4 NIO library? Under heavy load a single threaded multiplexing Non-Blocking Server should perform significantly faster than one that is context switching between Threads like Apache. Also the memory overhead and thread startup costs could be massively reduced. Matt. |
|
From: Alexander M. <al...@gm...> - 2003-05-22 15:37:57
|
> I've been looking at insomnia today as I was working a bit on the range > responses. > > Has anyone considered the Java 1.4 NIO library? Under heavy load a > single threaded multiplexing Non-Blocking Server should perform > significantly faster than one that is context switching between Threads > like Apache. > > Also the memory overhead and thread startup costs could be massively > reduced. > > Matt. Hello Matthew, I did not work with NIO yet, so I cannot say much about it. However I wonder how a single threaded non-blocking version should work as we would need to cycle constantly through all open connections to see whether there is any data and after receiving a full (and cached) request we would need to generate the output. However what would we do with external applications holding the connection open? Did I missunderstand anything? Thanks, Alexander -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! |
|
From: <mpc...@li...> - 2003-05-22 17:17:00
|
If an external applications hold the connection open the non-blocking IO library will return immediately with 0 bytes on a read() therefore the si= ngle thread is free to continue processing other requests. >-- Original Message -- >From: Alexander Mueller <al...@gm...> >To: ins...@li... >Subject: Re: [insomnia-httpd-devel] Performance >Reply-To: ins...@li... >Date: Thu, 22 May 2003 17:37:46 +0200 (MEST) > > >> I've been looking at insomnia today as I was working a bit on the rang= e > responses. > > Has anyone considered the Java 1.4 NIO library? Under heavy load a > single threaded multiplexing Non-Blocking Server should perform > significantly fas >er than one that is context switching between Threads > like Apache. > > Also the memory overhead and thread startup costs could be massively > reduced. > > Matt. Hello Matthew, I did not work with NIO yet, so I cannot say much about it > However I wonder how a single threaded non-blocking version should work as we would need to cycle constantly through all open connections to see whether there is any= data and after receiving a full (and cached) request we would need to generate= th > output. However what would we do with external applications holding the= connection open? Did I missunderstand anything? Thanks, Alexander -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l=E4cheln! Fotogalerie online mit GMX >hne eigene Homepage! ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Che >k out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ insomnia-httpd-devel mailing list ins...@li... https://lists.sourceforge.net/lis >s/listinfo/insomnia-httpd-devel |
|
From: Alexander M. <al...@gm...> - 2003-05-22 18:18:52
|
> If an external applications hold the connection open the non-blocking IO > library will return immediately with 0 bytes on a read() therefore the single > thread is free to continue processing other requests. You mean if there isnt any data to send we just iterate through the loop again and check in the next round whether there is data waiting? This would work, however it seems it would be rather difficult to understand such a code as it would need many lists to keep track of active connections with their associations to running applications. We would need to split every outgoing data (regular files and CGI data) into small pieces which would need to be transferred individually in order to prevent that blocking. Does anyone have comments to that? Alexander |
|
From: Mike Li <mik...@ya...> - 2003-05-22 23:35:54
|
NIO is easier to work on for simple application, but is more complicated for large application, which is also a reason that most of HTTP servers, like Apache, still uses multi-thread context switching model. In a complicated server, like HTTP server, multi-thread is always necessary. However, NIO can be used to minimize the number of threads and to reduce the overhead of thread context switching. The use of threads in NIO server may be in a different way, for example, thread may be designed to based on per task, not per request. Another benefit from using NIO is that the context swiching can be done at application level, not TCP/IP stack level. In application level, you can always have more control to reduct the overhead of thread context switching. It sounds great so far, but how to design a thread model to fit all you need is harder. If you have any idea about NIO and multi-thread, please post here. Mike. >>If an external applications hold the connection open the non-blocking IO >>library will return immediately with 0 bytes on a read() therefore the single >>thread is free to continue processing other requests. >> >> > > >You mean if there isnt any data to send we just iterate through the >loop again and check in the next round whether there is data waiting? >This would work, however it seems it would be rather difficult to >understand such a code as it would need many lists to keep track of >active connections with their associations to running applications. We >would need to split every outgoing data (regular files and CGI data) >into small pieces which would need to be transferred individually in >order to prevent that blocking. > >Does anyone have comments to that? > >Alexander > > > >------------------------------------------------------- >This SF.net email is sponsored by: ObjectStore. >If flattening out C++ or Java code to make your application fit in a >relational database is painful, don't do it! Check out ObjectStore. >Now part of Progress Software. http://www.objectstore.net/sourceforge >_______________________________________________ >insomnia-httpd-devel mailing list >ins...@li... >https://lists.sourceforge.net/lists/listinfo/insomnia-httpd-devel >. > > > |
|
From: Matthew C. <mpc...@li...> - 2003-05-23 15:26:39
|
These issues are all true. I don't propose jumping to a NIO solution. Just something worth keeping in mind as a potential performance improvement at a later date. Mike Li wrote: > > NIO is easier to work on for simple application, but is more complicated > for large application, which is also a reason that most of HTTP servers, > like Apache, still uses multi-thread context switching model. In a > complicated server, like HTTP server, multi-thread is always necessary. > However, NIO can be used to minimize the number of threads and to reduce > the overhead of thread context switching. The use of threads in NIO > server may be in a different way, for example, thread may be designed to > based on per task, not per request. Another benefit from using NIO is > that the context swiching can be done at application level, not TCP/IP > stack level. In application level, you can always have more control to > reduct the overhead of thread context switching. It sounds great so far, > but how to design a thread model to fit all you need is harder. If you > have any idea about NIO and multi-thread, please post here. > > > Mike. > >>> If an external applications hold the connection open the non-blocking IO >>> library will return immediately with 0 bytes on a read() therefore >>> the single >>> thread is free to continue processing other requests. >>> >> >> >> >> You mean if there isnt any data to send we just iterate through the >> loop again and check in the next round whether there is data waiting? >> This would work, however it seems it would be rather difficult to >> understand such a code as it would need many lists to keep track of >> active connections with their associations to running applications. We >> would need to split every outgoing data (regular files and CGI data) >> into small pieces which would need to be transferred individually in >> order to prevent that blocking. >> >> Does anyone have comments to that? >> >> Alexander >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: ObjectStore. >> If flattening out C++ or Java code to make your application fit in a >> relational database is painful, don't do it! Check out ObjectStore. >> Now part of Progress Software. http://www.objectstore.net/sourceforge >> _______________________________________________ >> insomnia-httpd-devel mailing list >> ins...@li... >> https://lists.sourceforge.net/lists/listinfo/insomnia-httpd-devel >> . >> >> >> > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > insomnia-httpd-devel mailing list > ins...@li... > https://lists.sourceforge.net/lists/listinfo/insomnia-httpd-devel > |
|
From: Roman M. <rom...@re...> - 2003-05-22 19:49:26
|
> Does anyone have comments to that? yes i have ... you guys rock :-) great work you are doing there - hope i can participate more soon! keep the good work going roman |
|
From: Matthew C. <mpc...@li...> - 2003-05-23 15:51:22
|
It's not as bad as all that. Each connection is encapsulated into a "nio.Channel" object. You can attempt to write the entire response as we do now write() doesn't block in non-blocking mode so that isn't a problem (though if the write failes to write the whole content in one go you would need to remember how far the write got). However if your worried about one client with a large bandwidth connection hogging all your cpu time this may be possible that's why I expect most NIO solution still employ multiple threads just not in the order of magnitude you need in a high load apache system (one per client) Matt. > > You mean if there isnt any data to send we just iterate through the > loop again and check in the next round whether there is data waiting? > This would work, however it seems it would be rather difficult to > understand such a code as it would need many lists to keep track of > active connections with their associations to running applications. We > would need to split every outgoing data (regular files and CGI data) > into small pieces which would need to be transferred individually in > order to prevent that blocking. > > Does anyone have comments to that? > > Alexander > > |
|
From: <mpc...@li...> - 2003-05-22 18:07:13
|
Example non-blocking server is available here: http://developer.java.sun.com/developer/technicalArticles/releases/nio/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X