Cool thanks alot i will look into it too .
Try nginx or cherokee as http server then scgi. We using that type of
configuration in production with at least 180K json requests a
day and very complex business logic with high concurrency.
scgi is not much tunable but is really simple: on a machine li
I really hate apache i will never use it.
So if i am going to change underlying web engine i want something that
support long polling with concurrency , how about tornado web ? would it be
good
On Thu, Sep 29, 2011 at 4:59 AM, Michele Comitini <
michele.comit...@gmail.com> wrote:
> I wrote:
> >
I wrote:
> uwsgi uses many different models. Using uwsgi a mix of event +
> prefork could give a big boost, but if you care about performance
> avoid apache.
>
I should have been:
uwsgi uses many different models. Using uwsgi a mix of event +
prefork could give a big boost -->and<-- if you care
Ok so your machine really behaves concurrently it could be that you
stumbled in some threading problem, probably at db driver level,
I am quite confident about rocket, so the next questions are ;-)
do you use a database?
which database?
mod_wsgi is not so bad it is difficult to tune IMHO and doe
Server machine is 32 cores 64 GB RAM :)
WSGI limitation is bad at concurrency right? I am thinking to move to more
Concurrent setup. Coz version 1 of this software gonna use Qooxdoo for UI
and there will be a lot more concurrency.
What are the advantages of uwsgi can use uevent right?
On Thu, Se
Can you try with a setup without rocket? I.e. scgi or uwsgi or fastcgi.
Is the server machine multicore?
mic
Il giorno 28/set/2011 18:48, "Phyo Arkar" ha
scritto:
> Happened once again
>
> THis time 1st json request went ok and another request failed like it
> did before.
>
> On 9/28/11, Phyo A
Happened once again
THis time 1st json request went ok and another request failed like it
did before.
On 9/28/11, Phyo Arkar wrote:
> Yeah i love screen coz i can search back easily and interactively debug
> infos.
>
> Yes its doing concurrent , the problem happen again yesterday but just
> for
Yeah i love screen coz i can search back easily and interactively debug infos.
Yes its doing concurrent , the problem happen again yesterday but just
for once , and gone away again.
Theres 2 Grid (jqGrid) in one page , they request 2 json response from
that controller but from different function
No way is not bad practice IMHO screen is a great tool.
So we can exclude the problem of stdout buffer full.
Seems something low level.
Is the client doing concurrent queries?
mic
2011/9/27 Phyo Arkar :
> Web2py is ran inside screen. coz my app is not production-stable yet
> and want to debug
Web2py is ran inside screen. coz my app is not production-stable yet
and want to debug. I print out some debug messages and can track back
inside screen (i know i know , its bad practice :D)
may be coz of that?
On 9/27/11, Michele Comitini wrote:
> I would begin to remove possible environmental
I would begin to remove possible environmental causes... ;)
Other questions:
4) Do you run web2py.py attached to a tty?
5) Do you redirect standard output from web2py or leave it on the tty?
The questions are because I see some print statements that could hang
IO on a thread if the web2py process
It cannot be reproduced ..
On 9/27/11, Phyo Arkar wrote:
> its not the same warning notices , client recieves 0 byte and timed
> out at brower side looking at firebug.
>
> On 9/27/11, Massimo Di Pierro wrote:
>> Other than the error, do you see wrong behavior from the browser?
>> I do not not be
1) It was clear HTTP
2) The Json Response is 0 byte and client was timed out (It happened
to both me and my Client from US , not Latency Issue)
3) No nothing.
On 9/27/11, Michele Comitini wrote:
> Hi Phyo
> Broken pipe... seems that the other end has died and the server tried
> to write to a dead
its not the same warning notices , client recieves 0 byte and timed
out at brower side looking at firebug.
On 9/27/11, Massimo Di Pierro wrote:
> Other than the error, do you see wrong behavior from the browser?
> I do not not believe that there is anything wrong as we ship the
> "official" rocke
it is Stable not trunk
On 9/27/11, Phyo Arkar wrote:
> Thanks Michele
>
> The problem comes up randomly . Yes on the client end the json data do
> not recieved (0 byte) and stopped due to request timedout.
>
> And it happened to both testers for that period of time (until web2py
> was restarted),
Thanks Michele
The problem comes up randomly . Yes on the client end the json data do
not recieved (0 byte) and stopped due to request timedout.
And it happened to both testers for that period of time (until web2py
was restarted), I am testing from myanmar and my Client is from NA so
thats not la
Hi Phyo
Broken pipe... seems that the other end has died and the server tried
to write to a dead socket.
Questions:
1) is it a clear HTTP session i.e. without SSL/TLS?
2) what do you see on the client i.e. does it wait forever for the
server to answer?
3) did you change anything on the client or th
On Sep 26, 2011, at 1:42 PM, Massimo Di Pierro wrote:
> It is not but it may be raised at the same point.
> It is important to determine which rocket version did not cause the
> error so we can look at differences.
The added line only logs SSLError, FWIW.
>
> On Sep 26, 3:34 pm, Jonathan Lundel
On Sep 26, 2011, at 1:30 PM, Massimo Di Pierro wrote:
> Other than the error, do you see wrong behavior from the browser?
> I do not not believe that there is anything wrong as we ship the
> "official" rocket. We are just printing an exception that before was
> being ignored.
I don't think this i
19 matches
Mail list logo
