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
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 u
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, bu
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 temp_folder
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 al
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
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 da
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
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
scala
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 thre
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
> 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 request
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 serv
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 th
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
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 u
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
r
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.)
A
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
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 i
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 o
*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 l
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
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 conn
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:
> > 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 does
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:
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
28 matches
Mail list logo