I'd welcome you both on get involved and help out. Dieter, I know you're mroe than capable of helping make these problems go away. zope-web@zope.org is the place to pitch in :-) cheers, Chris Jake wrote:

It only happened the first time I visited it. The second, third time it was as speedy as ever. I have to say though, on percieved average, it seems slower than other sites.

Jake

-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

Dieter Maurer wrote:

...

I'd welcome you both on get involved and help out. Dieter, I know you're mroe than capable of helping make these problems go away.

I probably will have to sign some legal document. This scarce me away a bit...

Be brave, it's not that scary ;-) The crap lying around in zope.org/manage is much more scary.. That said, you don't need to sign anything to help on on zope-web...

But, I already provided "ZopeProfiler" -- an excellent tool to analyse why Zope applications are slow.

Cool, although I think there are some more obvious things to be fixed first...

I also can provide a "ZEO.ServerStub.StorageServer" instrumentation to analyse number, size and time of ZEO load operations.

This is above my understanding threshold I'd afraid :-S

This information helped us to identify useless relevance ranking information as the main cause for extremely slow text searches.

When you say "relevance ranking information", are you referring to some artifact of some TextIndex implementation or something else?

This information is also extremely helpful to detect (and fix) bad persistency design (too large persistent objects).

Well, if you've run it over any Plone sites adn found anything useful, it'll probably apply to zope.org too...

I may be able to release "ztop" as open source (not sure, though -- it was developped in employees time; must ask my employer). "ztop" is a "top" (very useful Unix command to analyse the load of a computer) for Zope. It collects and displays statistical information about processed requests (number, medium, minimal, maximal, median execution times, request rate) and detailed information about the longest running requests. It is an excellent tool to identify the longest running requests ("requestprofiler" may serve a similar purpose).

This sounds like it would be extremely useful right now, since I have a hunch that a number of stoopid and very resource consuming pages are lurking on zope.org right now. This sounds like it would help to identify those and fix them, right? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

Simon Michael wrote at 2004-9-3 07:50 -0700:

Dieter, I'd be grateful for any of those additional tools you can share.

<http://www.dieter.handshake.de/pyprojects/zope> for "ManagableIndex", "IncrementalSearch" and "AdvancedQuery". The instrumented "ZEO/ServerStub.py" is attached. Logging ZEO communication is controlled by the environment variable "ZEO_LOG_CLIENT". The resulting log records can easily be extracted with "grep" and statistically processed with a Python script. "ztop" is much more difficult. Because the big-M logfile (now called "logger trace") has a poor time resolution and lacks essential information (the query string), "ztop" requires a custom extension of "ZPublisher.BaseRequest". Our extension uses a custom module to support rotated logfiles. Thus, changes to use "ztop" would be quite high -- in addition to the open source question. Maybe, I will reimplement "ztop" based on an enhanced big-M logfile. -- Dieter