(I'm on lispworks/win32)
Aside from questions of the wisdom of controlling this. . .
From my observations, I've seen Hunchentoot limit the number of worker
threads within a session (deliberately put "sleep"s into ajax request handlers, then stacked them up). It seemed to limit per-session, another session caused the creation of new threads.
I could not find it in the documentation - but is there a way to control the number of workers available for handling requests in total, or per-session?
Thanks, Matt
On Wed, Nov 12, 2008 at 17:08, Matthew Lamari matt.lamari@gmail.com wrote:
From my observations, I've seen Hunchentoot limit the number of worker threads within a session (deliberately put "sleep"s into ajax request handlers, then stacked them up). It seemed to limit per-session, another session caused the creation of new threads.
I could not find it in the documentation - but is there a way to control the number of workers available for handling requests in total, or per-session?
No, Hunchentoot currently provides for no control over the number of threads that it creates. In multi threaded mode, a new thread is created for each incoming connection. There may be limits in Lispworks and/or Windows that create the apparent limitation that you observe, but they are not under Hunchentoots control.
-Hans
2008/11/13 Hans Hübner hans@huebner.org:
On Wed, Nov 12, 2008 at 17:08, Matthew Lamari matt.lamari@gmail.com wrote:
From my observations, I've seen Hunchentoot limit the number of worker threads within a session (deliberately put "sleep"s into ajax request handlers, then stacked them up). It seemed to limit per-session, another session caused the creation of new threads.
I could not find it in the documentation - but is there a way to control the number of workers available for handling requests in total, or per-session?
No, Hunchentoot currently provides for no control over the number of threads that it creates. In multi threaded mode, a new thread is created for each incoming connection. There may be limits in Lispworks and/or Windows that create the apparent limitation that you observe, but they are not under Hunchentoots control.
Isn't Lispworks limited to one Lisp thread operating at a time? Rob
On Thu, Nov 13, 2008 at 07:55, Robert Synnott rsynnott@gmail.com wrote:
Isn't Lispworks limited to one Lisp thread operating at a time?
Could be, but Hunchentoot also does not control how many inactive threads it creates. Erm. ?
-Hans
On Thu, Nov 13, 2008 at 7:39 AM, Hans Hübner hans@huebner.org wrote:
On Thu, Nov 13, 2008 at 07:55, Robert Synnott rsynnott@gmail.com wrote:
Isn't Lispworks limited to one Lisp thread operating at a time?
Could be, but Hunchentoot also does not control how many inactive threads it creates. Erm. ?
-Hans
Thanks - your answer has helped me understand what is going on - what I am observing is a legitimate artifact of the number of connections that the browser creates, not a characteristic of hunchentoot (which is satisfying all requests as they are made) - and in my canned example, the browser, not hunchentoot, is controlling the action.
On 2008-11-13 06:50:51, Hans Hübner wrote:
No, Hunchentoot currently provides for no control over the number of threads that it creates. In multi threaded mode, a new thread is created for each incoming connection. There may be limits in Lispworks and/or Windows that create the apparent limitation that you observe, but they are not under Hunchentoots control.
As posted here 2005: SBCL can be crashed because of this.
http://common-lisp.net/pipermail/tbnl-devel/2005-August/002577.html
On Thu, Nov 13, 2008 at 08:51, Stefan Scholl stesch@no-spoon.de wrote:
On 2008-11-13 06:50:51, Hans Hübner wrote:
No, Hunchentoot currently provides for no control over the number of threads that it creates. In multi threaded mode, a new thread is created for each incoming connection. There may be limits in Lispworks and/or Windows that create the apparent limitation that you observe, but they are not under Hunchentoots control.
As posted here 2005: SBCL can be crashed because of this.
http://common-lisp.net/pipermail/tbnl-devel/2005-August/002577.html
I recommend running Hunchentoot in single threaded mode behind a caching proxy for that reason.
-Hans
2008/11/13 Stefan Scholl stesch@no-spoon.de:
On 2008-11-13 06:50:51, Hans Hübner wrote:
No, Hunchentoot currently provides for no control over the number of threads that it creates. In multi threaded mode, a new thread is created for each incoming connection. There may be limits in Lispworks and/or Windows that create the apparent limitation that you observe, but they are not under Hunchentoots control.
As posted here 2005: SBCL can be crashed because of this.
http://common-lisp.net/pipermail/tbnl-devel/2005-August/002577.html
I deal with this by first only allowing a certain number of requests to get to the webapp at a time, and second actually throwing away requests as soon as they come in if they hit a higher number. (This no longer happens due to a better webapp; at most I generally have about 10 requests on each of three servers). It's not ideal, and a better solution would probably involve request queueing in a proxy.
Running more than one instance per machine and load balancing across them can actually work, as well; it doesn't seem to get overwhelmed as easily.
Rob
2008/11/13 Robert Synnott rsynnott@gmail.com:
2008/11/13 Stefan Scholl stesch@no-spoon.de:
On 2008-11-13 06:50:51, Hans Hübner wrote:
No, Hunchentoot currently provides for no control over the number of threads that it creates. In multi threaded mode, a new thread is created for each incoming connection. There may be limits in Lispworks and/or Windows that create the apparent limitation that you observe, but they are not under Hunchentoots control.
As posted here 2005: SBCL can be crashed because of this.
http://common-lisp.net/pipermail/tbnl-devel/2005-August/002577.html
I deal with this by first only allowing a certain number of requests to get to the webapp at a time, and second actually throwing away requests as soon as they come in if they hit a higher number. (This no longer happens due to a better webapp; at most I generally have about 10 requests on each of three servers). It's not ideal, and a better solution would probably involve request queueing in a proxy.
Running more than one instance per machine and load balancing across them can actually work, as well; it doesn't seem to get overwhelmed as easily.
Rob
Also, if your webapp is largely processor-bound (no external database etc.), running single-threaded hunchentoot might actually be a viable option. Rob
hello,
as i understand it most browsers only allow two connections at one time per domain, which limit the transfer (and do not make use of higher internet connection speeds when exists) a solution would be, if i remember it correctly is to fake many sub domains with wildcard dns and then configure your apache aliases to handle it
regards
Ala'a (cmo-0)
On Thu, Nov 13, 2008 at 2:08 AM, Matthew Lamari matt.lamari@gmail.com wrote:
(I'm on lispworks/win32)
Aside from questions of the wisdom of controlling this. . .
From my observations, I've seen Hunchentoot limit the number of worker threads within a session (deliberately put "sleep"s into ajax request handlers, then stacked them up). It seemed to limit per-session, another session caused the creation of new threads.
I could not find it in the documentation - but is there a way to control the number of workers available for handling requests in total, or per-session?
Thanks, Matt
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
You can try JMeter to test your webapp
http://jakarta.apache.org/jmeter
On Thu, Nov 13, 2008 at 4:51 PM, Abu Abdullah Al Jumaee amalawi@gmail.com wrote:
hello,
as i understand it most browsers only allow two connections at one time per domain, which limit the transfer (and do not make use of higher internet connection speeds when exists) a solution would be, if i remember it correctly is to fake many sub domains with wildcard dns and then configure your apache aliases to handle it
regards
Ala'a (cmo-0)
On Thu, Nov 13, 2008 at 2:08 AM, Matthew Lamari matt.lamari@gmail.com wrote:
(I'm on lispworks/win32)
Aside from questions of the wisdom of controlling this. . .
From my observations, I've seen Hunchentoot limit the number of worker threads within a session (deliberately put "sleep"s into ajax request handlers, then stacked them up). It seemed to limit per-session, another session caused the creation of new threads.
I could not find it in the documentation - but is there a way to control the number of workers available for handling requests in total, or per-session?
Thanks, Matt
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- It does not matter how fast your code is, if it does not work!
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
and there is also the simple tools like httperf and openload
regards
Ala'a (cmo-0)
On Thu, Nov 13, 2008 at 2:08 AM, Matthew Lamari matt.lamari@gmail.com wrote:
(I'm on lispworks/win32)
Aside from questions of the wisdom of controlling this. . .
From my observations, I've seen Hunchentoot limit the number of worker threads within a session (deliberately put "sleep"s into ajax request handlers, then stacked them up). It seemed to limit per-session, another session caused the creation of new threads.
I could not find it in the documentation - but is there a way to control the number of workers available for handling requests in total, or per-session?
Thanks, Matt
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-
Abu Abdullah Al Jumaee -
Andrea Chiumenti -
Hans Hübner -
Matthew Lamari -
Robert Synnott -
Stefan Scholl