In his test, with turobogears wiki20 demo, he found tg would hung up
while concurrent > 3
(either run directly or behind mod_python). I
Though the infomation is limit, did anyone meet the same problem?
His test system:
debian3.1, python2.4.1, apache2.0.54, mod_python3.2.10,
turbogears1.0b1, django0.95
Here is the origin post
http://groups.google.com/group/python-cn/browse_thread/thread/dd13409b272b832f/dcd4b087e8337a7a?lnk=arm#dcd4b087e8337a7a
Can anyone comment?
Thanks,
Stuart
'am not entirely sure, but I think it may have to do with CP supporting
only HTTP 1.0... Wonder if proxying/load-balancing it with lighty,
nginx or
apache (HTTP 1.1) will give an "illusion" of "improved performance"
/venkat
Curious to know as details as possible on what this posts means to me,
and what are the suggestions. While I started my journey three months
back, had thought for Django as well, but chose Turbogears due to some
technical superiority.
thanks
sanjay
Anyone got more details on the tests? The discussion thread looked like
gibberish to me :-)
I'd be happy to devote time to replicating the tests. Anyone want to
join me in a distributed effort?
Thanks,
Stuart
CP2 does indeed have a partial support of HTTP/1.1 only. CP3 is HTTP/1.1
compliant and its architecture makes it performing much much better than
its predecessor. But that'll be for TG1.1.
For now I guess using Apache/lighttpd as a frontend for static data can
already increase the performances.
- Sylvain
That was me, and I never had a resolution. To this day TG still hangs on
that application.
I've never done any high traffic sites with TG because I get the
distinct impression that I would lose my job if I did. Obviously I can't
afford that.
-Rob
Could you be more specific about what was happening? A quick search of
the group turns up this message, which I think is what you are talking
about:
http://groups.google.com/group/turbogears/msg/4b8fea2ad728b7e4
I know that there is a two server connections per client limit that
most browsers follow, but that is in HTTP 1.1 and not a suggestion for
the server side. (RFC 2616, sec 8.1.4)
"Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with any
server or proxy."
but CP2 is HTTP 1.0, and is a server anyways. It may have been designed
around this assumption due to modern browsers enforcing this limit.
-Adam
FrozenBear have developed Diggdot.com and other sites that prove that
you can scale TurboGears sites to high traffic. Opirus and rPath
Linux are also using TurboGears in production with good success.
If there's a relocatable test which causes TurboGears to fail under
such a low load, I'm sure it can and will be fixed quickly.
Unfortunately I'm tied up for the next little bit, but if you guys can
produce a failing test, we'll be able to move from there to a fix.
And if failing tests aren't reproducible, it's likely to be an issue
with the original tester's setup. And given that I've seen higher
load than this, and I know people who have quite a bit higher load, I
think it's possible that the test is either unrealistic in some way,
or that there's a configuration problem on the server being tested.
--Mark Ramm
Could it be the same issue as http://www.cherrypy.org/ticket/550?
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org