Hi, I installed Zope 2.5.1b2 + CMF1.2 + Plone 0.9.9PR5 Restart zope: 90 seconds. Log into /manage: 7 (!) minutes. Next pages in /manage: 5-20 seconds Site itself: 5-10 seconds During all these attempts, z2.py is in the top of `top`. I tried to add RAM cache manager, but only Members/index_html shows as cacheable when I try to associate. All this on a Pentium 233, 128MB, no swapping. Hardly any other activity on this machine. Is there a way to profile this? I know nothing about python, but am a proficient sysadmin, C, perl, PHP programmer. Thanks, Ron Arts
I installed Zope 2.5.1b2 + CMF1.2 + Plone 0.9.9PR5 <snip> All this on a Pentium 233, 128MB, no swapping. Hardly any other activity on this machine.
If you have a large Data.fs with a lot of products, it is normal to see a long startup time. But if this was a fresh Zope, then I would not expect the startup on your hardware to take more than 15 seconds at the most. There are two possibilities: 1) Your system has a bottleneck you aren't aware of, processes blocking, running out of file descriptors, etc. 2) Python or Zope has some bug w.r.t your system. Here are some questions for you: What is your load average? CPU utilization? Disk activity? Perhaps you could post a 'vmstat 2 10' the system idling vs. starting up zope vs. viewing a page in started up Zope? What OS are you running? IIRC there have been problems with threads on solaris. Did you compile python, zope from source? What version of python are you using? What flags did you compile it with?
During all these attempts, z2.py is in the top of `top`.
I tried to add RAM cache manager, but only Members/index_html shows as cacheable when I try to associate.
This may help, but (a) you have a big problem regardless, and (b) you currently can't associate filsystem-based scripts (i.e. those used in the CMF) with cache managers (something I hope to remedy soon). seb
I installed Zope 2.5.1b2 + CMF1.2 + Plone 0.9.9PR5 <snip> All this on a Pentium 233, 128MB, no swapping. Hardly any other activity on this machine.
If you have a large Data.fs with a lot of products, it is normal to see a long startup time. But if this was a fresh Zope, then I would not expect the startup on your hardware to take more than 15 seconds at the most.
There are two possibilities:
1) Your system has a bottleneck you aren't aware of, processes blocking, running out of file descriptors, etc. 2) Python or Zope has some bug w.r.t your system.
3) You have used a cvs CMF version too long ;-) My guess is that 7 minutes on a P233 to login is normal, if you are using Plone that uses PageTemplates, and CMF1.2 that does not have support for delayed cooking. There is a HUGE difference in startup time/first access time when using CMF cvs with delayed PageTemplates cooking support. /Magnus
On Thu, 2002-03-14 at 12:40, Magnus Heino wrote:
3) You have used a cvs CMF version too long ;-) My guess is that 7 minutes on a P233 to login is normal, if you are using Plone that uses PageTemplates, and CMF1.2 that does not have support for delayed cooking.
There is a HUGE difference in startup time/first access time when using CMF cvs with delayed PageTemplates cooking support.
Oh yeah ;-) However, this still doesn't explain up to 10 second times for viewing management pages after startup..? seb
seb bacon wrote:
If you have a large Data.fs with a lot of products, it is normal to see a long startup time. But if this was a fresh Zope, then I would not expect the startup on your hardware to take more than 15 seconds at the most.
There are two possibilities:
1) Your system has a bottleneck you aren't aware of, processes blocking, running out of file descriptors, etc. 2) Python or Zope has some bug w.r.t your system.
Here are some questions for you:
What is your load average? CPU utilization? Disk activity? Perhaps you could post a 'vmstat 2 10' the system idling vs. starting up zope vs. viewing a page in started up Zope?
System idle: [root@n010080 /root]# vmstat 2 10 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 4772 3208 5888 32576 0 0 6 3 27 49 95 4 1 0 0 0 4772 3208 5888 32576 0 0 0 0 188 52 2 4 94 0 0 0 4772 3208 5888 32576 0 0 0 0 218 89 7 16 77 0 0 0 4772 3208 5888 32576 0 0 0 0 177 52 1 4 94 0 0 0 4772 3208 5888 32576 0 0 0 0 187 59 3 3 94 0 0 0 4772 3208 5888 32576 0 0 0 0 210 92 8 14 78 0 0 0 4772 3208 5888 32576 0 0 0 0 197 57 2 3 94 1 0 0 4772 3212 5888 32576 0 0 0 0 225 98 7 17 77 0 0 0 4772 3208 5888 32576 0 0 0 0 194 79 1 6 93 0 0 0 4772 3208 5888 32576 0 0 0 0 200 51 2 4 94 Zope start [root@n010080 /root]# vmstat 2 10 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 4772 16088 5380 32320 0 0 6 3 27 49 95 4 1 1 0 0 4772 15524 5380 32320 0 0 0 7 223 53 80 20 0 1 0 1 4772 13800 5800 32320 0 0 0 171 1337 110 73 27 0 2 0 0 4772 12776 5800 32320 0 0 0 7 470 71 83 17 0 1 0 0 4772 12308 5800 32320 0 0 5 1 194 64 91 9 0 1 0 0 4772 11640 5800 32320 0 0 0 0 179 56 90 10 0 1 0 0 4772 11004 5800 32320 0 0 2 0 203 58 87 13 0 1 0 0 4772 10420 5800 32320 0 0 0 0 192 50 89 11 0 1 0 0 4772 10308 5800 32320 0 0 0 1 162 53 95 5 0 1 0 0 4772 9580 5800 32320 0 0 0 0 173 49 92 8 0 Viewing a page: [root@n010080 /root]# vmstat 2 10 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 4772 2452 6372 32408 0 0 6 3 28 49 95 4 1 1 0 0 4772 2428 6372 32416 0 0 1 0 200 57 93 7 0 1 0 0 4772 2412 6372 32428 0 0 0 2 203 60 94 6 0 1 0 0 4772 2392 6372 32432 0 0 0 0 193 51 91 9 0 2 0 0 4772 2328 6372 32448 0 0 1 0 221 84 91 6 3 1 0 1 4772 2216 6372 32468 0 0 0 2 224 77 89 11 0 2 0 3 4772 2156 6372 32524 0 0 6 0 245 73 86 11 3 1 0 2 4772 2140 6372 32544 0 0 1 0 180 58 92 8 0 1 0 0 4772 3108 6132 32336 0 0 4 0 239 62 80 18 2 1 0 0 4772 3072 6132 32360 0 0 2 32 464 81 78 20 2
What OS are you running? IIRC there have been problems with threads on solaris.
Linux 2.2.20 kernel.
Did you compile python, zope from source? What version of python are you using? What flags did you compile it with?
I used the RPM that is on www.zope.org, recreated that using the newest Zope version (only thing I needed to change was add some products to the spec file). The Zope RPM is running fine withouth CMF and plone. If I add CMF it gets a lot slower, but when I add plone it really sucks. Magnus said:
3) You have used a cvs CMF version too long ;-) My guess is that 7 minutes on a P233 to login is normal, if you are using Plone that uses PageTemplates, and CMF1.2 that does not have support for delayed cooking.
There is a HUGE difference in startup time/first access time when using CMF cvs with delayed PageTemplates cooking support.
So if I want to use plone I need to use latest CMF CVS-version? I did not know that, the docs said CMF 1.2 was OK, so I took it. I generally prefer not to use CVS versions. Ron Arts -- Netland Internet Services bedrijfsmatige internetoplossingen http://www.netland.nl Kruislaan 419 1098 VA Amsterdam info: 020-5628282 servicedesk: 020-5628280 fax: 020-5628281
Ron, just to make sure, you do have DMA enabled on your hard drives, right? hdparm should tell you that status. If you don't, then you'll suffer greatly when you need to do I/O because all of the bytes are running through the CPU. -- Matt Kromer Zope Corporation http://www.zope.com/
On Thu, 14 Mar 2002 11:57:41 -0500, "Matthew T. Kromer" <matt@zope.com> wrote:
Ron, just to make sure, you do have DMA enabled on your hard drives, right? hdparm should tell you that status. If you don't, then you'll suffer greatly when you need to do I/O because all of the bytes are running through the CPU.
What bytes? The biggest 'bi' (blocks read from disk) is 6, thats 25k/second The biggest 'bo' (blocks written to disk) is 171, and the second biggest 32. thats 684k/second or 128k/second. Never mind DMA; I could be writing those bytes by hand with pencil and paper and it wouldnt make zope as slow as he is reporting. Toby Dickenson tdickenson@geminidataloggers.com
True. Although hdparm -tT showed a threefold improvement, my zope startup and access times hardly changed. I'm currently reinstalling and doing more tests, more in half an hour or so. Ron Arts Toby Dickenson wrote:
On Thu, 14 Mar 2002 11:57:41 -0500, "Matthew T. Kromer" <matt@zope.com> wrote:
Ron, just to make sure, you do have DMA enabled on your hard drives, right? hdparm should tell you that status. If you don't, then you'll suffer greatly when you need to do I/O because all of the bytes are running through the CPU.
What bytes?
The biggest 'bi' (blocks read from disk) is 6, thats 25k/second
The biggest 'bo' (blocks written to disk) is 171, and the second biggest 32. thats 684k/second or 128k/second.
Never mind DMA; I could be writing those bytes by hand with pencil and paper and it wouldnt make zope as slow as he is reporting.
Toby Dickenson tdickenson@geminidataloggers.com
Matthew T. Kromer wrote:
Ron, just to make sure, you do have DMA enabled on your hard drives, right? hdparm should tell you that status. If you don't, then you'll suffer greatly when you need to do I/O because all of the bytes are running through the CPU.
Some more data points, we have the same problem on a dev server, linux 2.2.13 The funny thing is, this happened after rebooting the server when we installed a scsi drive, before everything was ok. The scsi drive does make some problems, and it might not be related directly to zope - I suspect the drive, but anyway, perhaps it's something else. Ron, what OS are you running? If linux, could you repeat the steps I did for comparision?
dmesg (fruitless, because dmesg is filled up with scsi-errors) hdparm -t /dev/<of all disk devices>
/dev/hda: Timing buffered disk reads: 32 MB in 2.65 seconds =12.08 MB/sec
hdparm -T /dev/<of all disk devices>
/dev/hda: Timing buffer-cache reads: 64 MB in 0.61 seconds =104.92 MB/sec
time start (use -D option and press ctrl-C as soon as you see it has started up)
------ 2002-03-14T16:45:18 INFO(0) ZServer HTTP server started at Thu Mar 14 17:45:18 2002 Hostname: baal.compuvision Port: 10080 Traceback (innermost last): File "/home/zope/Zope-2.3.3-src/z2.py", line 772, in ? asyncore.loop() File "/home/zope/Zope-2.3.3-src/ZServer/medusa/asyncore.py", line 146, in loop poll_fun (timeout, map) File "/home/zope/Zope-2.3.3-src/ZServer/medusa/asyncore.py", line 70, in poll try: r,w,e = select.select (r,w,e, timeout) KeyboardInterrupt Traceback (innermost last): File "/home/zope/Zope-2.3.3-src/z2.py", line 548, in ? zdaemon.run(sys.argv, os.path.join(CLIENT_HOME, Zpid)) File "/home/zope/Zope-2.3.3-src/lib/python/zdaemon.py", line 209, in run p,s = os.waitpid(pid, 0) KeyboardInterrupt real 0m20.928s user 0m13.160s sys 0m0.790s You see, this is quite long. No special products installed.
3) You have used a cvs CMF version too long ;-) My guess is that 7 minutes on a P233 to login is normal, if you are using Plone that uses PageTemplates, and CMF1.2 that does not have support for delayed cooking.
There is a HUGE difference in startup time/first access time when using CMF cvs with delayed PageTemplates cooking support.
So if I want to use plone I need to use latest CMF CVS-version? I did not know that, the docs said CMF 1.2 was OK, so I took it. I generally prefer not to use CVS versions.
No, Plone will work just fine with CMF1.2. In the upcoming 1.3 however, the cooking of page templates, with plone makes heavy use of, is delayed from startup time to the time when they are accessed the first time. This results in much faster startup times. /Magnus
Ron Arts wrote:
What is your load average? CPU utilization? Disk activity? Perhaps you could post a 'vmstat 2 10' the system idling vs. starting up zope vs. viewing a page in started up Zope?
<snip stats> So that seems pretty clear: Zope is running your processor into the ground :(
I used the RPM that is on www.zope.org, recreated that using the newest Zope version (only thing I needed to change was add some products to the spec file). The Zope RPM is running fine withouth CMF and plone.
If I add CMF it gets a lot slower, but when I add plone it really sucks.
CMF uses ZPT, even without plone. There is anecdotal evidence that ZPT may be up to 2 times slower than DTML, plus as has already been pointed out, older versions 'cook' all of the ZPT on startup. More RAM should help your system cope better. When viewing pages there were up to 3 processes swapped out. Otherwise, upgrade to the latest versions of Zope and CMF. The CMF cvs HEAD is very stable, though obviously no-one will offer you guarantees. On the other hand, ZC will be releasing a 1.3 version soon, which won't be very different from the HEAD as it is currently, so you could safely use it for development, then upgrade to the release version. I think you're probably going to need some new kit, though :-( ...but basically, it seems you have hit on a minimum recommended system. It also demonstrates that ZPT is in need of some serious optimisation, IMO. seb
On Thu, 14 Mar 2002 17:24:43 +0000, seb bacon <seb@jamkit.com> wrote:
...but basically, it seems you have hit on a minimum recommended system.
The previously reported system was a Pentium 233, 128MB, a practically empty database, and not running much else. Thats quite a bit larger than the smallest system I deal with.... I run several 'desktop' zopes, where a typical low end system is a Pentium 200, 32MB (true a few years ago; most have since been upgraded), Windows 98, with a moderately full database, and running other desktop stuff including a browser. It does work reasonably well.
It also demonstrates that ZPT is in need of some serious optimisation.
maybe. Ive not run ZPT on a small system. Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
On Thu, 14 Mar 2002 17:24:43 +0000, seb bacon <seb@jamkit.com> wrote:
...but basically, it seems you have hit on a minimum recommended system.
The previously reported system was a Pentium 233, 128MB, a practically empty database, and not running much else. Thats quite a bit larger than the smallest system I deal with....
I run several 'desktop' zopes, where a typical low end system is a Pentium 200, 32MB (true a few years ago; most have since been upgraded), Windows 98, with a moderately full database, and running other desktop stuff including a browser. It does work reasonably well.
Yes, me too. I meant: "minimum recommended system for a Zope + CMF + ZPT setup". seb
On Thu, 14 Mar 2002 17:47:56 +0000, seb bacon <seb@jamkit.com> wrote:
Toby Dickenson wrote:
I run several 'desktop' zopes, where a typical low end system is a Pentium 200, 32MB (true a few years ago; most have since been upgraded), Windows 98, with a moderately full database, and running other desktop stuff including a browser. It does work reasonably well.
Yes, me too. I meant: "minimum recommended system for a Zope + CMF + ZPT setup".
OK, so that _might_ suggest that Zope is lean and mean, while CMF+ZPT is a slow bloater. Ron, what happens to your performance if you remove CMF+ZPT ? Toby Dickenson tdickenson@geminidataloggers.com
seb bacon wrote:
<snip stats>
So that seems pretty clear: Zope is running your processor into the ground:(
CMF uses ZPT, even without plone. There is anecdotal evidence that ZPT may be up to 2 times slower than DTML, plus as has already been pointed out, older versions 'cook' all of the ZPT on startup.
More RAM should help your system cope better. When viewing pages there were up to 3 processes swapped out.
Otherwise, upgrade to the latest versions of Zope and CMF. The CMF cvs HEAD is very stable, though obviously no-one will offer you guarantees. On the other hand, ZC will be releasing a 1.3 version soon, which won't be very different from the HEAD as it is currently, so you could safely use it for development, then upgrade to the release version.
I think you're probably going to need some new kit, though :-(
OK, I re-installed. Zope-2.5.1b1, CMF (latest from CVS), Plone (0.9.9PR5) I first installed everything before starting zope. There is a gotcha. Both CMF and Plone contain a DCWorkflow product. Tried to run diffs on the directories but got loads of differences. I took the one from CMFPlone. Then I created a CMF site (as per the Plone installation). This took 119 seconds. Then I tried to install plone. Got this error: Error Type: TypeError Error Value: manage_addTypeInformation() takes at least 2 non-keyword arguments (1 given) Tried the DCWorkflow from CMF, and retried installing Plone with the External method 'install' But I could not get into the /manage screen any more. I saw two python threads running at 35% CPU, but after a while they went to 0% and that was it. Could not even get into the Zope main screen. Switched to the DCWorkflow of CMFPlone again. Restart Zope. Nothing. I'm locked out of the management screen. Ron Ron Arts
Ron Arts wrote:
OK, I re-installed. Zope-2.5.1b1, CMF (latest from CVS), Plone (0.9.9PR5) I first installed everything before starting zope.
<snip failures> I haven't installed plone so I can't help there. I'd be interested in the statistics for a Zope without the CMF for comparison. The other thing you could do, which might help verify that it's ZPT degrading the performance, is to go to the skins tool, and make a non-zpt skin by (1) deleting zpt_generic, zpt_control, and zpt_content from the 'contents', and (2) going to 'properties' and replacing references to 'zpt_content' with 'content', etc. seb
On Friday, March 15, 2002, at 04:46 AM, seb bacon wrote:
Ron Arts wrote:
OK, I re-installed. Zope-2.5.1b1, CMF (latest from CVS), Plone (0.9.9PR5) I first installed everything before starting zope.
<snip failures>
I haven't installed plone so I can't help there. I'd be interested in the statistics for a Zope without the CMF for comparison. The other thing you could do, which might help verify that it's ZPT degrading the performance, is to go to the skins tool, and make a non-zpt skin by (1) deleting zpt_generic, zpt_control, and zpt_content from the 'contents', and (2) going to 'properties' and replacing references to 'zpt_content' with 'content', etc.
seb
Yes, please remove any unnecessary skins; if you feel up to it, collapse all your skins into a single directory. It causes a lot of extra overhead to go look up attributes (objects) in skin directories. On a faster machine it isn't as much an issue; but on a slower machine you spend a vast amount of time in getattr() lookups.
On 14 Mar 2002 at 17:24, seb bacon wrote:
So that seems pretty clear: Zope is running your processor into the ground :(
<snipage> FWIW, I tried Plone on my poor old Debian unstable box. Its a P200, 64MB, lots of other stuff running, hdparm not optimized**, Debian Zope package (2.5.0) & CMF (1.2), latest Plone. Time to restart Zope: ~50 seconds Time to first management screen: ~4 minutes Time to first Plone screen: ~30 seconds Most everything is reasonably quick after that, although I didn't check too much out. HTH! Chris ** supposed to be getting a PPro200 box that supports more memory, I'm gonna spend more time getting that one set up correctly.
Just for kicks, why don't you see what system calls it is using. If it's not doing any, then the odds are that there's some sort of internal processing going on inside of zope. I've seen this occasionaly with zope 2.3 if a bunch of products have changed, but after it is running then performance is fine. Get the pid from top that is using up the cpu and run strace -p your_pid You will probably have to run it as either the user that started zope or root. -Paul Ron Arts wrote:
seb bacon wrote:
If you have a large Data.fs with a lot of products, it is normal to see a long startup time. But if this was a fresh Zope, then I would not expect the startup on your hardware to take more than 15 seconds at the most.
There are two possibilities:
1) Your system has a bottleneck you aren't aware of, processes blocking, running out of file descriptors, etc. 2) Python or Zope has some bug w.r.t your system.
Here are some questions for you:
What is your load average? CPU utilization? Disk activity? Perhaps you could post a 'vmstat 2 10' the system idling vs. starting up zope vs. viewing a page in started up Zope?
System idle:
[root@n010080 /root]# vmstat 2 10 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 4772 3208 5888 32576 0 0 6 3 27 49 95 4 1 0 0 0 4772 3208 5888 32576 0 0 0 0 188 52 2 4 94 0 0 0 4772 3208 5888 32576 0 0 0 0 218 89 7 16 77 0 0 0 4772 3208 5888 32576 0 0 0 0 177 52 1 4 94 0 0 0 4772 3208 5888 32576 0 0 0 0 187 59 3 3 94 0 0 0 4772 3208 5888 32576 0 0 0 0 210 92 8 14 78 0 0 0 4772 3208 5888 32576 0 0 0 0 197 57 2 3 94 1 0 0 4772 3212 5888 32576 0 0 0 0 225 98 7 17 77 0 0 0 4772 3208 5888 32576 0 0 0 0 194 79 1 6 93 0 0 0 4772 3208 5888 32576 0 0 0 0 200 51 2 4 94
Zope start
[root@n010080 /root]# vmstat 2 10 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 4772 16088 5380 32320 0 0 6 3 27 49 95 4 1 1 0 0 4772 15524 5380 32320 0 0 0 7 223 53 80 20 0 1 0 1 4772 13800 5800 32320 0 0 0 171 1337 110 73 27 0 2 0 0 4772 12776 5800 32320 0 0 0 7 470 71 83 17 0 1 0 0 4772 12308 5800 32320 0 0 5 1 194 64 91 9 0 1 0 0 4772 11640 5800 32320 0 0 0 0 179 56 90 10 0 1 0 0 4772 11004 5800 32320 0 0 2 0 203 58 87 13 0 1 0 0 4772 10420 5800 32320 0 0 0 0 192 50 89 11 0 1 0 0 4772 10308 5800 32320 0 0 0 1 162 53 95 5 0 1 0 0 4772 9580 5800 32320 0 0 0 0 173 49 92 8 0
Viewing a page:
[root@n010080 /root]# vmstat 2 10 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 4772 2452 6372 32408 0 0 6 3 28 49 95 4 1 1 0 0 4772 2428 6372 32416 0 0 1 0 200 57 93 7 0 1 0 0 4772 2412 6372 32428 0 0 0 2 203 60 94 6 0 1 0 0 4772 2392 6372 32432 0 0 0 0 193 51 91 9 0 2 0 0 4772 2328 6372 32448 0 0 1 0 221 84 91 6 3 1 0 1 4772 2216 6372 32468 0 0 0 2 224 77 89 11 0 2 0 3 4772 2156 6372 32524 0 0 6 0 245 73 86 11 3 1 0 2 4772 2140 6372 32544 0 0 1 0 180 58 92 8 0 1 0 0 4772 3108 6132 32336 0 0 4 0 239 62 80 18 2 1 0 0 4772 3072 6132 32360 0 0 2 32 464 81 78 20 2
What OS are you running? IIRC there have been problems with threads on solaris.
Linux 2.2.20 kernel.
Did you compile python, zope from source? What version of python are you using? What flags did you compile it with?
I used the RPM that is on www.zope.org, recreated that using the newest Zope version (only thing I needed to change was add some products to the spec file). The Zope RPM is running fine withouth CMF and plone.
If I add CMF it gets a lot slower, but when I add plone it really sucks.
Magnus said:
3) You have used a cvs CMF version too long ;-) My guess is that 7 minutes on a P233 to login is normal, if you are using Plone that uses PageTemplates, and CMF1.2 that does not have support for delayed cooking.
There is a HUGE difference in startup time/first access time when using CMF cvs with delayed PageTemplates cooking support.
So if I want to use plone I need to use latest CMF CVS-version? I did not know that, the docs said CMF 1.2 was OK, so I took it. I generally prefer not to use CVS versions.
Ron Arts
Paul Erickson wrote:
Just for kicks, why don't you see what system calls it is using. If it's not doing any, then the odds are that there's some sort of internal processing going on inside of zope. I've seen this occasionaly with zope 2.3 if a bunch of products have changed, but after it is running then performance is fine.
Get the pid from top that is using up the cpu and run
strace -p your_pid
You will probably have to run it as either the user that started zope or root.
Done that. It's very interesting to do this while zope is starting up. It seems the last 10 of my seconds zope is in a tight loop calling time() and doing nothing else. If I do strace -p on a thread that processes an HTTP request, strace immediately exits without displaying anything (maybe because strace does not support threads?) I'll try upgrading strace in a moment. Note: this is a RedHat 7.0 system. Ron Arts
Ron Arts wrote:
Get the pid from top that is using up the cpu and run
strace -p your_pid
Done that. It's very interesting to do this while zope is starting up. It seems the last 10 of my seconds zope is in a tight loop calling time() and doing nothing else.
Ouch! Now I see why Jim says timestamps in short records are bad :-( cheers, Chris
Chris Withers wrote:
Ron Arts wrote:
Get the pid from top that is using up the cpu and run
strace -p your_pid
Done that. It's very interesting to do this while zope is starting up. It seems the last 10 of my seconds zope is in a tight loop calling time() and doing nothing else.
Ouch! Now I see why Jim says timestamps in short records are bad :-(
Right. ZODB makes lots of time calls (one on each operation of a persistent object). Toby Dickenson's new ZODB cache eliminates these. We intend to get these merged into the core ASAP. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Thu, 14 Mar 2002 21:04:13 +0100, Ron Arts <raarts@netland.nl> wrote:
Done that. It's very interesting to do this while zope is starting up. It seems the last 10 of my seconds zope is in a tight loop calling time() and doing nothing else.
Thats not as strange as it looks. Zope calls time() on every access to attributes of persistent objects, because the code to work out which objects to deactivate is currently timestamp-based (all of this is different in Zope 2.6) Your strace just indicates that zope is spending 10 seconds working with some persistent objects. Toby Dickenson tdickenson@geminidataloggers.com
On Thu, 14 Mar 2002 11:00:01 +0100, Ron Arts <raarts@netland.nl> wrote:
During all these attempts, z2.py is in the top of `top`.
what does top tell you about what the process is doing? Toby Dickenson tdickenson@geminidataloggers.com
Ron Arts writes:
I installed Zope 2.5.1b2 + CMF1.2 + Plone 0.9.9PR5
Restart zope: 90 seconds. Log into /manage: 7 (!) minutes. Next pages in /manage: 5-20 seconds Site itself: 5-10 seconds
During all these attempts, z2.py is in the top of `top`. That's far too slow, indeed.
I would analyse such strange behaviour with the embedded profiler: Set the environment variable "PROFILE_PUBLISHER" (to something, e.g. "1"). and then start Zope in this environment. Go to "Control_Panel/DebugInfo/Profiling". You can there analyse the cycle crunchers. Dieter
On 14 Mar 2002 at 21:44, Dieter Maurer wrote:
Ron Arts writes:
I installed Zope 2.5.1b2 + CMF1.2 + Plone 0.9.9PR5
This sounds familiar. I'm running about 8 Zope's on a PIII-750, 512Meg ram SCSI160 Dell box. They're all great, lightly used.. Last week I setup an instance (Zope 2.5.0) with CMF 1.2 and Plone 0.9.9.PR5 AND LDAPUserFolder and CMFLDap I notice that startup seems a little longer than the others, about 10 seconds. However as soon as I make my first client access inside the CMF, CPU Utilization on the machine jumps to 100% for about 20 seconds. Then it's back to normal. This happens only during the first access after a startup/restart. But it happens every time. I don't know if it's CMF, Plone, LDAPUserFolder or whatnot. I haven't had much time to investigate. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax AOL-IM: BKClements
Brad Clements writes:
... However as soon as I make my first client access inside the CMF, CPU Utilization on the machine jumps to 100% for about 20 seconds.
Then it's back to normal. This happens only during the first access after a startup/restart. But it happens every time. That's ZPT and Python Script cooking...
Dieter
Well, Pentium-class 233 MHZ machine with 128MB, IDE disk: It's not a fast machine, but zope runs ok on it. Here are some benchmarks (ab -n 100 -c 5) Zope homepage: Requests per second: 5.86 [#/sec] (mean) Time per request: 852.95 [ms] (mean) CMFSite homepage: Requests per second: 1.01 [#/sec] (mean) Time per request: 4967.70 [ms] (mean) Plone Homepage: Requests per second: 0.23 [#/sec] (mean) Time per request: 21858.70 [ms] (mean) Zope itself can do almost 6 req/second on this machine. CMFSite goes down to 1 req/sec. I am told this is due to ZPT. After Plone installation, zope restart takes a full 7 minutes! Running plone.setup takes 368 seconds Plone makes Zope 25 times as slow. Even unbearably so on this hardware. On another machine (Dual 1GHz, 1GByte RAM, SCSI RAID-1) Zope homepage: Requests per second: 84.60 [#/sec] (mean) Time per request: 59.10 [ms] (mean) CMFSite Homepage: Requests per second: 17.13 [#/sec] (mean) Time per request: 291.90 [ms] (mean) After Plone install zope restart takes 15 seconds Running Plone setup takes 20 seconds Plone Homepage: Requests per second: 3.99 [#/sec] (mean) Time per request: 1253.65 [ms] (mean) Plone makes Zope 21 time as slow on this machine Even a fast dual pentium machine can only serve 4 (relatively simple) Plone requests per second. I think this will be a showstoper for actual deployment in many cases. Regards, Ron Arts
Restart zope: 90 seconds.
Pack the database. That'll help.
Log into /manage: 7 (!) minutes. Next pages in /manage: 5-20 seconds Site itself: 5-10 seconds
During all these attempts, z2.py is in the top of `top`.
How much CPU and memory?
All this on a Pentium 233, 128MB, no swapping. Hardly any other activity on this machine.
Should be enough; however running a Zope server does require a pretty powerful machine.
Is there a way to profile this? I know nothing about python, but am a proficient sysadmin, C, perl, PHP programmer.
Yeah, it's called CallProfiler and can be used to monitor what takes so bloody long time when a page is rendered. Not sure how this product works on the management interface though.
Thanks, Ron Arts
participants (13)
-
Brad Clements -
Chris Cothrun -
Chris Withers -
Dieter Maurer -
Jim Fulton -
Magnus Heino -
Matthew T. Kromer -
Oliver Bleutgen -
Paul Erickson -
Peter Bengtsson -
Ron Arts -
seb bacon -
Toby Dickenson