hoepfully this helps.
With my mutli-threaded, single process deployment, not behind any proxies
deployment, I can handle 1000 concurrent users using 'siege' and at the same
time use the application quickly in both chrome and firefox. I haven't run
siege for more than 5 minutes at a time, but the process doesn't get above
35 MB of RAM usage, then after siege goes away, drops back down to like 28
MB. It handled 648.5 req/s from siege. The process is still running ..
hasn't locked up yet. http://barcamp.supa.ws (you can log in with 'admin'
'admin' and play around if you like.
I wonder if the proxies in front of the deployment are the things causing
the trouble ? What do you have in front ? ha-proxy ?
Kind Regards,
Matthew Sherborne
On Wed, Sep 21, 2011 at 7:51 AM, Wim Dumon <[email protected]> wrote:
> The proper solution is not to use recursive event loops. You can avoid
> them even when you use modal dialogs, and it's only a little more
> programming work. It will eliminate this 'exhausted thread pool'
> problem completely. Recursive event loops don't really scale with
> concurrent sessions.
>
> Is there someting special in your system that guarantees that you
> shouldn't have concurrent users? (e.g. it only makes sense to have one
> session?) If that is the case, we should maybe provide an API that
> allows to kill existing session... but I'm not sure if that's a good
> idea.
>
> BR,
> Wim.
>
> 2011/9/19 Gaetano Mendola <[email protected]>:
> > Koen,
> > the most annoying aspect is that when the sessions are all taken then
> > the first modal dialog
> > deadlocks the entire application, is there a way to detect that
> > sessions are over and then
> > give an error or at least make force all ajax connections to be check?
> >
> >
> > On Mon, Sep 19, 2011 at 2:54 PM, Antonio Mancina <[email protected]>
> wrote:
> >> Hey Koen,
> >>
> >> >> [...]
> >>>> shown on screen: as soon as the user closes the tab, the
> >>>> wt server detects this event and properly deallocates the
> >>>> session without waiting for the timeout to expire.
> >>>
> >>> You actually see a difference in the same browser with a dialog open
> >>> or not for the session to be released? Then that is a bug.
> >>
> >> yes, that is definitely the case! Hope you have the chance to
> >> reproduce and fix it.
> >>
> >>>> 3) Also, would it be possible to detect thread pool exhaustion at
> >>>> code-level, avoiding the user being stuck waiting for a timeout
> >>>> to happen?
> >>>
> >>> Actually, there is no reason to lock a thread while showing modal
> >>> dialogs. You can also show a modal dialog by using show(), and binding
> >>> listeners to its accept(), reject() or done() methods. The behavior is
> >>> the same, but it is a bit less convenient to implement.
> >>
> >> Yes, agreed. Just a matter of convenience, indeed.
> >>
> >>> Regards,
> >>> koen
> >>
> >> Thanks for your explanations.
> >>
> >> Bye,
> >> Antonio
> >>
> >>
> ------------------------------------------------------------------------------
> >> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> >> Learn about the latest advances in developing for the
> >> BlackBerry® mobile platform with sessions, labs & more.
> >> See new tools and technologies. Register for BlackBerry® DevCon
> today!
> >> http://p.sf.net/sfu/rim-devcon-copy1
> >> _______________________________________________
> >> witty-interest mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/witty-interest
> >>
> >
> >
> >
> > --
> > cpp-today.blogspot.com
> >
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > witty-interest mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/witty-interest
> >
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> witty-interest mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
