Zope or Python blocking on select()
Hello, Running Zwiki 0.36 on Zope 2.7.4-0 on Python 2.4, glibc-2.3.4-3, kernel 2.4.22-nptl (fedora core 1). Whenever we hit a ZWiki page, there is a delay of 8 seconds before the first page is sent. Subsequent objects for that request are sent in reasonable (i.e. sub-second) times. Every individual page request seems to cause this delay. I have tried all 3 ways of setting the LD_ASSUME_KERNEL variable, tried recompiling Python using the '--with-lib=' option for the different thread libraries, tried Python 2.3.3, and all this still gives the same result - a nasty 8 seconds delay. Has anyone else run into a delay like this? Is anyone using a similar kernel/Python/Zope combination successfully? I have pasted a brief excerpt from strace of my Python process, any advice on what may be happening would be welcome. The 8 second delay occurs after the select call '18:50:38.256285 select(16, [4 5 8 15], [], [4 5 8 15], {30, 0}) = 1 (in [8], left {21, 930000})' Thanks, David 6541 18:50:38.231673 recv(15, "GET /am/DesignIterationStories HTTP/1.1\r\nAccept: image/gif, image/x- xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application /vnd.ms-powerpoint, application/msword, */*\r\nReferer: https://our.server.com/am/FrontPage\r\nAcc ept-Language: en-us\r\nAccept-Encoding: gzip, deflate\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0 ; Windows NT 5.1)\r\nHost: our.server.com:443\r\nConnection: Keep-Alive\r\nCookie: zwiki_displaymo de=\"simple\"; tree-s=\"eJzTyCkw5NLIKTDiClZ3hANXW3WuAmOuRKCECUjWFEnW2cQXJGvGlQiSNkeWMQbLWABlEhP1AO-ZFk w\"\r\nAuthorization: Basic ZHN3aWZ0OjR0aGZsMDBy\r\nX-SSL-cipher: RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 \r\nX-Forwarded-For: 192.168.1.20\r\n\r\n", 4096, 0) = 729 6541 18:50:38.233418 gettimeofday({1107831038, 233651}, NULL) = 0 6541 18:50:38.235096 kill(6545, SIGRTMIN) = 0 6541 18:50:38.235658 kill(6545, SIGRTMIN) = 0 6541 18:50:38.253015 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 6541 18:50:38.253668 rt_sigsuspend([] <unfinished ...> 6541 18:50:38.254468 --- SIGRTMIN (Unknown signal 32) @ 0 (0) --- 6541 18:50:38.254928 <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) 6541 18:50:38.255248 sigreturn() = ? (mask now [RTMIN]) 6541 18:50:38.255882 kill(6545, SIGRTMIN) = 0 6541 18:50:38.256285 select(16, [4 5 8 15], [], [4 5 8 15], {30, 0}) = 1 (in [8], left {21, 930000}) 6541 18:50:46.331142 read(8, "x", 8192) = 1 6541 18:50:46.331775 select(16, [4 5 8 15], [15], [4 5 8 15], {30, 0}) = 1 (out [15], left {30, 0}) 6541 18:50:46.332720 send(15, "HTTP/1.1 200 OK\r\nServer: Zope/(Zope 2.7.4-0, python 2.4.0, linux2) Z Server/1.1\r\nDate: Tue, 08 Feb 2005 02:50:46 GMT\r\nContent-Length: 21296\r\nContent-Type: text/html; charset=utf-8\r\nConnection: close\r\n\r\n<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional/ /EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html xmlns=\"http://www.w3.org/19
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Swift wrote: | Running Zwiki 0.36 on Zope 2.7.4-0 on Python 2.4, glibc-2.3.4-3, kernel | 2.4.22-nptl (fedora core 1). Python 2.3.4 is the recommended, supported version of Python. | Whenever we hit a ZWiki page, there is a delay of 8 seconds before the | first page is sent. Subsequent objects for that request are sent in | reasonable (i.e. sub-second) times. Every individual page request seems | to cause this delay. I have tried all 3 ways of setting the | LD_ASSUME_KERNEL variable, tried recompiling Python using the | '--with-lib=' option for the different thread libraries, tried Python | 2.3.3, and all this still gives the same result - a nasty 8 seconds delay. It looks as though your delay is in communicating with a ZEO server -- the speedup after first load would be explained by the presence of the object in the ZEO client cache. | Has anyone else run into a delay like this? Is anyone using a similar | kernel/Python/Zope combination successfully? I run Zope 2.7.4 with ZEO (on the same machine) on FC1 without seeing such issues, using a Python built for the purpose (I don't reuse /usr/bin/python). I don't see such issues there. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCCLrIGqWXf00rNCgRAphPAKCOgJqHZzBZZH7xdYENY05nU3p/EwCfQ4WH ZqdpeRLmsx/Ugd4n31pePYU= =M1/1 -----END PGP SIGNATURE-----
Hi Tres, Thanks for the reply. I have provided a couple of notes below, and I am copying to the list: Quoting Tres Seaver <tseaver@zope.com>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Swift wrote:
| Running Zwiki 0.36 on Zope 2.7.4-0 on Python 2.4, glibc-2.3.4-3, kernel | 2.4.22-nptl (fedora core 1).
Python 2.3.4 is the recommended, supported version of Python.
Understood - we were running on Python 2.3.3, using Zope 2.7.0 on a 2.4.18 kernel previously. I had hoped to take advantage of bugfixes in threading on Python 2.4. Nevertheless, since I also see this delay using Python 2.3.3 on the new machine, I am pretty certain it is not a problem with Python. I am also pretty certain it is not Zope 2.7.4 per se, as I see the same behavior when using 2.7.3 on the new machine. I really suspect I have left out some critical piece of configuration, but I am lost as to what that may be.
| Whenever we hit a ZWiki page, there is a delay of 8 seconds before the | first page is sent. Subsequent objects for that request are sent in | reasonable (i.e. sub-second) times. Every individual page request seems | to cause this delay. I have tried all 3 ways of setting the | LD_ASSUME_KERNEL variable, tried recompiling Python using the | '--with-lib=' option for the different thread libraries, tried Python | 2.3.3, and all this still gives the same result - a nasty 8 seconds delay.
It looks as though your delay is in communicating with a ZEO server -- the speedup after first load would be explained by the presence of the object in the ZEO client cache.
We are not using a ZEO server, we are still on filestorage. I wish I could use ZEO, but when I first set it up, I think I hit this problem as well, and I went back to filestorage. I am also pretty certain that the pages are not being cached. Every time I click on a ZWiki link, or click the 'FrontPage' link at the top of a ZWiki page, we experience the delay. As I said, every individual page request has this delay, no matter how many times the pages have been loaded previously. Looking into the detailed cache debug info for the instance, I never see a ZWiki page with a count higher than 1.
| Has anyone else run into a delay like this? Is anyone using a similar | kernel/Python/Zope combination successfully?
I run Zope 2.7.4 with ZEO (on the same machine) on FC1 without seeing such issues, using a Python built for the purpose (I don't reuse /usr/bin/python). I don't see such issues there.
Good information, thanks! I was thinking I had setup a really strange and unique configuration :-) I am wondering which version of glibc you have, or if you are using the LD_ASSUME_KERNEL variable in any way? Can you also tell me what your ./configure command line looked like when you compiled Python? I have compiled both 2.4 and 2.3.3 on the FC1 machine, but perhaps I left something critical out of the configuration.
Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCCLrIGqWXf00rNCgRAphPAKCOgJqHZzBZZH7xdYENY05nU3p/EwCfQ4WH ZqdpeRLmsx/Ugd4n31pePYU= =M1/1 -----END PGP SIGNATURE-----
Thanks again, David ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dswift@apmindsf.com wrote: | Hi Tres, | | Thanks for the reply. I have provided a couple of notes below, and I am copying | to the list: <snip> |> We are not using a ZEO server, we are still on filestorage. I wish I could use |> ZEO, but when I first set it up, I think I hit this problem as well, and I went |> back to filestorage. | |> I am also pretty certain that the pages are not being cached. Every time I |> click on a ZWiki link, or click the 'FrontPage' link at the top of a ZWiki |> page, we experience the delay. How about for the ZMI, with no wiki in sight, or even the Zope start page at /? |> I am wondering which version of glibc you have, or if you are using the |> LD_ASSUME_KERNEL variable in any way? Can you also tell me what your |> ./configure command line looked like when you compiled Python? I have compiled |> both 2.4 and 2.3.3 on the FC1 machine, but perhaps I left something critical |> out of the configuration. I don't do anything to touch LD_ASSUME_KERNEL, and my 'configure' is bare-bones simple ('--prefix="/opt/zope" --enable-unicode="ucs2"'). Hmm, if you aren't using ZEO, then I don't know why you would be blocking in 'select' at all -- wait, do you have reverse DNS lookup turned on? Check zope.conf, and try disabling it, e.g. remove any 'dns-server' entry there. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCCO8ZGqWXf00rNCgRAoeWAJ9v1GetWod7iwh5AHA9FgUv7l/gEQCgggte map7kCjdysdtvXxDRAjO4Lw= =8hv7 -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
dswift@apmindsf.com wrote: | Hi Tres, | | Thanks for the reply. I have provided a couple of notes below, and I am copying | to the list:
<snip>
|> We are not using a ZEO server, we are still on filestorage. I wish I could use |> ZEO, but when I first set it up, I think I hit this problem as well, and I went |> back to filestorage. | |> I am also pretty certain that the pages are not being cached. Every time I |> click on a ZWiki link, or click the 'FrontPage' link at the top of a ZWiki |> page, we experience the delay.
How about for the ZMI, with no wiki in sight, or even the Zope start page at /?
The / page, and the /manage page, both seem pretty snappy, responding in a couple of seconds for /manage, and in a second or less for /.
|> I am wondering which version of glibc you have, or if you are using the |> LD_ASSUME_KERNEL variable in any way? Can you also tell me what your |> ./configure command line looked like when you compiled Python? I have compiled |> both 2.4 and 2.3.3 on the FC1 machine, but perhaps I left something critical |> out of the configuration.
I don't do anything to touch LD_ASSUME_KERNEL, and my 'configure' is bare-bones simple ('--prefix="/opt/zope" --enable-unicode="ucs2"').
Cool - my config is (--prefix=/usr/local/zope --with-threads), perhaps I should remove the 'threads' parameter.
Hmm, if you aren't using ZEO, then I don't know why you would be blocking in 'select' at all -- wait, do you have reverse DNS lookup turned on? Check zope.conf, and try disabling it, e.g. remove any 'dns-server' entry there.
No, we are not using reverse DNS. We are using pound to frontend the instance, but I also have a test instance on the same box that I hit directly, to make sure pound doesn't impose a penalty. I am looking through an strace log that I took from startup of zope to my page GETs, and I see it reading a *lot* of data between my page request and the send() of my rendered page. A majority of the read() data does not have anything to do with my page, AFAICT. Is having a 750MB Data.fs file causing me a problem? I have compacted it, using 30 days as my parameter in the ZMI.
Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCCO8ZGqWXf00rNCgRAoeWAJ9v1GetWod7iwh5AHA9FgUv7l/gEQCgggte map7kCjdysdtvXxDRAjO4Lw= =8hv7 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Swift wrote: |> How about for the ZMI, with no wiki in sight, or even the Zope start |> page at /? | | The / page, and the /manage page, both seem pretty snappy, responding in | a couple of seconds for /manage, and in a second or less for /. If this is only ZWiki pages, then I would be asking Simon and the zwiki.org folks if they have some clues. The only ZWiki related log output on my machine (running ZWiki v. 0.32) is: ~ 2005-02-08T11:39:18 BLATHER(-100) ZWiki using no i18n Are you perhaps doing some I18N, or does ZWiki think you are? Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCCPjPGqWXf00rNCgRAl+hAKCfUldqADjWDpOCLhDpM3JkVes7+QCfRnrt k5rqpepMKsxgKFdczBPAsms= =sf9h -----END PGP SIGNATURE-----
Will do - thanks a lot, I appreciate all your help today. Knowing that our config is out there running is a lot of good info :-) BTW, I have the same log message, no i18n here, yet, at least. David Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Swift wrote:
|> How about for the ZMI, with no wiki in sight, or even the Zope start |> page at /? | | The / page, and the /manage page, both seem pretty snappy, responding in | a couple of seconds for /manage, and in a second or less for /.
If this is only ZWiki pages, then I would be asking Simon and the zwiki.org folks if they have some clues. The only ZWiki related log output on my machine (running ZWiki v. 0.32) is:
~ 2005-02-08T11:39:18 BLATHER(-100) ZWiki using no i18n
Are you perhaps doing some I18N, or does ZWiki think you are?
Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCCPjPGqWXf00rNCgRAl+hAKCfUldqADjWDpOCLhDpM3JkVes7+QCfRnrt k5rqpepMKsxgKFdczBPAsms= =sf9h -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Swift wrote: | Will do - thanks a lot, I appreciate all your help today. Knowing that | our config is out there running is a lot of good info :-) One thing to look at might be the object cache size for your main storage (or the one where the wiki is, if that is different). Try bumping up the number of objects there, and see if that helps. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCCQDNGqWXf00rNCgRAsPjAJ9k93s34aKlekyrLToF3xYHOLl9/gCdG77e zpNd1+QgLo0RBvcGjuxcECU= =nqKM -----END PGP SIGNATURE-----
Hi all, Thought I'd post what appears to have solved my problem. I had created '/usr/local/zope/prodProducts' to hold the product code for all my Zqpe instances. I then made 'instance/Products' a symlink to '/usr/local/zope/prodProducts' for my Zope instances. When I looked at the strace of the Python process, it appeared that the ZWiki .py files were being re-compiled for each page. I removed the symlink, and copied the product code to the 'instance/Products' directory, and everything appeared to work then. Page render times are now between 1.6 - 4.4 seconds on a 2.5 Ghz Intel box. Thanks! David Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Swift wrote:
| Will do - thanks a lot, I appreciate all your help today. Knowing that | our config is out there running is a lot of good info :-)
One thing to look at might be the object cache size for your main storage (or the one where the wiki is, if that is different). Try bumping up the number of objects there, and see if that helps.
Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCCQDNGqWXf00rNCgRAsPjAJ9k93s34aKlekyrLToF3xYHOLl9/gCdG77e zpNd1+QgLo0RBvcGjuxcECU= =nqKM -----END PGP SIGNATURE-----
On Feb 8, 2005, at 17:55, Tres Seaver wrote:
|> I am wondering which version of glibc you have, or if you are using the |> LD_ASSUME_KERNEL variable in any way? Can you also tell me what your |> ./configure command line looked like when you compiled Python? I have compiled |> both 2.4 and 2.3.3 on the FC1 machine, but perhaps I left something critical |> out of the configuration.
I don't do anything to touch LD_ASSUME_KERNEL, and my 'configure' is bare-bones simple ('--prefix="/opt/zope" --enable-unicode="ucs2"').
I honestly don't remember where that whole "LD_ASSUME_KERNEL" stuff originated, but it seems to be one of those myths that somehow never die. I have used all kinds of RH/FC releases over the last 5 years and it seems that LD_ASSUME_KERNEL was used for some other purpose, and unfortunately it has reached complete FUD status as far as Python/Zope is concerned now... jens
FYI: LD_ASSUME_KERNEL From http://people.redhat.com/drepper/assumekernel.html This means no LD_ASSUME_KERNEL setting requesting versions earlier than 2.2.5 will work at all. Versions from 2.2.5 to 2.4.0 will use the DSOs in /lib, versions from 2.4.1 to 2.4.19 will use the DSOs in /lib/i686, versions 2.4.20 and younger will use the DSOs in /lib/tls. The specific ABI version requirements on a RHL9, and Fedora Core 1 and 2 system are as follows (NB: this implies IA-32 is the architecture): DSOs in /lib/tls need ABI version 2.4.20. DSOs in /lib/i686 need ABI version 2.4.1. DSOs in /lib need ABI version 2.2.5. For the Red Hat releases this layout was chosen to provide the maximum amount of backward compatibility for broken applications (correctly written applications have no problems anyway). The code in /lib consists of the very early LinuxThreads code which had fixed size threads which could not be placed by the application. The version in /lib/i686 is the LinuxThreads code which does away with this limitation (aka floating stacks). The code in /lib/tls is the new NPTL POSIX thread library. Thomas On Tue, 2005-02-08 at 17:32, Jens Vagelpohl wrote:
On Feb 8, 2005, at 17:55, Tres Seaver wrote:
|> I am wondering which version of glibc you have, or if you are using the |> LD_ASSUME_KERNEL variable in any way? Can you also tell me what your |> ./configure command line looked like when you compiled Python? I have compiled |> both 2.4 and 2.3.3 on the FC1 machine, but perhaps I left something critical |> out of the configuration.
I don't do anything to touch LD_ASSUME_KERNEL, and my 'configure' is bare-bones simple ('--prefix="/opt/zope" --enable-unicode="ucs2"').
I honestly don't remember where that whole "LD_ASSUME_KERNEL" stuff originated, but it seems to be one of those myths that somehow never die. I have used all kinds of RH/FC releases over the last 5 years and it seems that LD_ASSUME_KERNEL was used for some other purpose, and unfortunately it has reached complete FUD status as far as Python/Zope is concerned now...
jens
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Feb 8, 2005, at 5:32 PM, Jens Vagelpohl wrote:
I honestly don't remember where that whole "LD_ASSUME_KERNEL" stuff originated, but it seems to be one of those myths that somehow never die.
There was, at one point, a problem. That point in time has long since passed. A small python program that exhibited the problem is here. <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97637 Red Hat 9 originally shipped with a version of glibc that they called "glibc-2.3.2-11.9.i386.rpm" which exhibited the problem. Later updates to RH9 supplied a fix. The current update to RH9's glibs is available at <ftp://ftp.redhat.com/pub/redhat/linux/updates/9/en/os/i386/glibc -2.3.2-27.9.7.i386.rpm> This, of course, only affects the bugs underlying pthreads implementation. The Python level threading bugs in Python >= 2.2b1 and Python < 2.4 that can cause Zope to hang are not effected by LD_ASSUME_KERNEL.
Hi. I have a list of objects from a folder that I obtained using objectValues and then batched. I wrote a short script to format the results of size so I get nice kB, MB, etc. My ZPT to deal with this formating looks like this: ...tal:define="file_size item/size" tal:content="python:here.getFileSize(file_size)">##.# kB</td> This works fine for getting data from using objectValues. Now, I am modifying my CMF folder_contents template. CMF folder_contents pulls its content together using items python: here.listFolderContents(contentFilter=filter) I am batching on item. First off, I can't get size using item/size without an attribute error as follows: * Module Products.PageTemplates.Expressions, line 198, in __call__ * Module Products.PageTemplates.Expressions, line 201, in __call__ * Module Products.PageTemplates.Expressions, line 189, in _eval * Module Products.PageTemplates.Expressions, line 145, in _eval * Module Products.PageTemplates.Expressions, line 354, in restrictedTraverse AttributeError: size but I can get the size information using item/get_size. Now if I attempt to gather item/get_size in a variable like this: ...tal:define="file_size item/get_size" tal:content="python:here.getFileSize(file_size)">##.# kB</td> it throws the following key error: * Module Products.PageTemplates.TALES, line 221, in evaluate * Module Products.PageTemplates.Expressions, line 198, in __call__ * Module Products.PageTemplates.Expressions, line 201, in __call__ * Module Products.PageTemplates.Expressions, line 189, in _eval * Module Products.PageTemplates.Expressions, line 145, in _eval * Module Products.PageTemplates.Expressions, line 347, in restrictedTraverse * Module OFS.ObjectManager, line 663, in __getitem__ KeyError: 'get_size' My function in not causing any trouble. If I replace the tal:content section with tal:content="file_size", I will get the same error. So two questions: 1) Why I can't put the data in a variable in the same way I had done previously? 2) Is there another way I can get the size of the object here. Why doesn't item/size return the size in this case? Am I not still dealing with a list of objects from the folder? I should say that I am using a condition on the items since there are folders and files in a folder. So if it is a folder it will return a structure statement to put a in my table. So I am only trying to get the size on items other than folders. The full line looks like this: <span tal:condition="not: folderish" tal:define="file_size item/get_size" tal:omit-tag="" tal:content="file_size">##.# kB</span> Regards, David
David Pratt wrote at 2005-2-9 16:28 -0400:
... loop ... ...tal:define="file_size item/size" ... AttributeError: size ... ...tal:define="file_size item/get_size" ... KeyError: 'get_size'
Apparently, you have object with a "size" attribute (lacking "get_size") and (other) objects with a "get_size" attribute (but without "size). You can use: "file_size item/size | item/get_size | nothing" to account for these cases (and the one that you hit an object without both "size" and "get_size"). -- Dieter
David Swift wrote:
Hello,
Running Zwiki 0.36 on Zope 2.7.4-0 on Python 2.4, glibc-2.3.4-3, kernel 2.4.22-nptl (fedora core 1).
Whenever we hit a ZWiki page, there is a delay of 8 seconds before the first page is sent. Subsequent objects for that request are sent in reasonable (i.e. sub-second) times. Every individual page request seems to cause this delay. I have tried all 3 ways of setting the LD_ASSUME_KERNEL variable, tried recompiling Python using the '--with-lib=' option for the different thread libraries, tried Python 2.3.3, and all this still gives the same result - a nasty 8 seconds delay.
Please check this out: <http://zwiki.org/993SetupTrackerAlsoRequiredForGoodLargeWikiPerformanceNow> Michael -- http://zope.org/Members/d2m http://planetzope.org
participants (9)
-
Andrew Langmead -
David Pratt -
David Swift -
Dieter Maurer -
dswift＠apmindsf.com
-
Jens Vagelpohl -
Michael Haubenwallner -
Thomas Bennett -
Tres Seaver