On Thursday 12 February 2004 00:57, you wrote:
One of the optimization we're thinking of is storing results of ZCatalog
searches (e.g., number of replies to postings) in volatile variables so
we don't have to run the catalog search at all. We'd like to use memory
space shared between threads
Bjorn Stabell wrote:
Okay, I'd better explain our situation in more detail, then.
The point is, our template is very dynamic, and our application (a BBS)
is very dynamic as well. We have done one round of optimization
(basically making things as cacheable as possible) and after testing the
Toby wrote:
One of the optimization we're thinking of is storing results of
ZCatalog searches (e.g., number of replies to postings) in volatile
variables so we don't have to run the catalog search at all. We'd
like to use memory space shared between threads for this.
Using ZEO
using the _v_ variables won't work for this since different threads
won't agree on who was latest. Its definitely a bad idea to do queries
for these three data points. What about putting them in the
temp_folder then you can still use ZEO with a bunch of clients that
will all share the same
Zope should have something like ASP's Response.IsClientConnected method,
which would allow app code to manually abort the processing of a request
in strategic places if the connection has already been closed. I
mentioned this a while back, but never did do anything about it.
On Wed, 2004-02-11
Erik:
using the _v_ variables won't work for this since different threads
won't agree on who was latest. Its definitely a bad idea to
do queries
for these three data points. What about putting them in the
temp_folder then you can still use ZEO with a bunch of clients that
will all
Bjorn Stabell wrote:
(..)For ZEO, my understanding is that we would still have to store the
values in the ZODB, though.
You are able to store *and* share data over ZEO Clients in a
TemporaryStorage by making the ZSS serve this TemporaryStorage to its
ZCs. You could mount this storage as
Jan-Wijbrand wrote:
[...]
You are able to store *and* share data over ZEO Clients in a
TemporaryStorage by making the ZSS serve this
TemporaryStorage to its ZCs. You could mount this storage as
temp_folder I guess, but any other mount point would work too.
Col :)
Not sure, but
On Thu, 2004-02-12 at 07:19, Bjorn Stabell wrote:
Toby wrote:
One of the optimization we're thinking of is storing results of
ZCatalog searches (e.g., number of replies to postings) in volatile
variables so we don't have to run the catalog search at all. We'd
like to use memory
On Thu, 2004-02-12 at 10:06, Jan-Wijbrand Kolman wrote:
Bjorn Stabell wrote:
(..)For ZEO, my understanding is that we would still have to store the
values in the ZODB, though.
You are able to store *and* share data over ZEO Clients in a
TemporaryStorage by making the ZSS serve this
Hi,
We've run into an interesting problem when load-testing a Zope site
behind Apache, a problem that we've also encountered in real life.
Basically, when the load gets high, Zope has a huge backload of work
(several minutes of requests), making the average latency for each
request many minutes.
Bjorn Stabell wrote:
It appears the way to control it would for Apache or Zope to return 503
Service Unavailable when the load is too high, but we haven't found a
good way to do this; Zope doesn't appear to have any mechanism for it,
and Apache's ProxyPass doesn't either. I guess load balancers
Bjorn Stabell wrote:
Basically, when the load gets high, Zope has a huge backload of work
(several minutes of requests), making the average latency for each
request many minutes. What are effective ways to do this kind of
overload management so that the backlog of work doesn't get that big?
Bjorn Stabell wrote:
Basically, when the load gets high, Zope has a huge
backload of work
(several minutes of requests), making the average latency for each
request many minutes. What are effective ways to do this kind of
overload management so that the backlog of work doesn't get
On Wednesday 11 February 2004 09:16, Jamie Heilman wrote:
Bjorn Stabell wrote:
Basically, when the load gets high, Zope has a huge backload of work
(several minutes of requests), making the average latency for each
request many minutes. What are effective ways to do this kind of
Bjorn Stabell wrote:
You'll always reach the bottleneck sooner or later, and in 99% of the
cases it'll be Zope. It's not exactly a racing horse.
Tell me about it, in a former life I was the guy with the pager.
With KeepAlive on, wouldn't everything in one session sent over one
TCP
Toby Dickenson wrote:
Zope's ZServer manages a queue of requests that have been recieved over http,
but not dispatched to the publisher. This is handled in
PubCore/ZRendezvous.py. I suspect this queue will be holding your backlog.
You might get some benefit from capping the length of
*Scratches head*. Isn't it possible to just timestamp every request in a
list of running requests, and in the beginning of each request check how
long the currently processing requests have been running, and if that sum is
above a specified time, fail?
OK, you get the problem that images may not
Toby wrote:
[...]
Zope's ZServer manages a queue of requests that have been
recieved over http,
but not dispatched to the publisher. This is handled in
PubCore/ZRendezvous.py. I suspect this queue will be holding
your backlog.
You might get some benefit from capping the length of that
Toby wrote:
Hmm, yes. ZRendezvous doesnt have any choice but to queue up
the request.
Handling the request at that point could cause problems
because the support
for pipelined http requests might cause another recursive call to
ZRendezvous.handle, and deadlock. You need to handle it
On Wed, 11 Feb 2004 20:25:14 +0800
Bjorn Stabell [EMAIL PROTECTED] wrote:
Toby wrote:
[...]
Zope's ZServer manages a queue of requests that have been
recieved over http,
but not dispatched to the publisher. This is handled in
PubCore/ZRendezvous.py. I suspect this queue will be
This very much depends on your application and requirements (and your
definition of nicely :-)), but I'd argue that it rarely make sense to
handle this at the TCP Connection level (just to think about browsers
opening multiple connections, HTTP/1.0 or /1.1 compliant browsers,
proxies etc.)
As
Bjorn Stabell wrote:
Hi,
We've run into an interesting problem when load-testing a Zope site
behind Apache, a problem that we've also encountered in real life.
Basically, when the load gets high, Zope has a huge backload of work
(several minutes of requests), making the average latency for each
Lennart Regebro wrote:
OK, you get the problem that images may not load even if the main page does,
but is that really worse for the end user than not getting anything?
As I've been saying, if you do that, they will reload repeatedly
making the problem worse. If the images are fluf, and the
On Wed, 2004-02-11 at 13:09, Jamie Heilman wrote:
Lennart Regebro wrote:
OK, you get the problem that images may not load even if the main page does,
but is that really worse for the end user than not getting anything?
As I've been saying, if you do that, they will reload repeatedly
On Thursday 12 February 2004 01:23, Casey Duncan wrote:
What kinds of requests are these? Do they all require a dynamic output?
If not, then you should put better caching in front of Zope, or at a
minimum tweak you caching headers so that some could be served as 304s
for instance.
If they
Richard Jones wrote:
On Thursday 12 February 2004 01:23, Casey Duncan wrote:
What kinds of requests are these? Do they all require a dynamic
output? If not, then you should put better caching in front of Zope,
or at a minimum tweak you caching headers so that some
could be served as
Bjorn wrote:
I wonder if Zope also processes requests that have been closed from
the client end? I know Zope will continue processing a request even
if it times out at least (so you can do long-running requests, like
packing, through the web). Many (all?) of these 300 requests would
Jamie writes:
Lennart Regebro wrote:
OK, you get the problem that images may not load even if
the main page
does, but is that really worse for the end user than not getting
anything?
As I've been saying, if you do that, they will reload
repeatedly making the problem worse. If the
29 matches
Mail list logo
