> I'll probably be upgrading to 7.0 in the next month or so, given that
> this is obviously a thread issue and that that release has much
> improved thread code. However, for the time being, the pressing issue
> is fixed, and for anyone in my position stuck on 6.2...this is night &
> day.

It has been over a year and a half, or so, since I last experimented with
Zope. I only have 9 FreeBSD servers, but in my circumstance I've had good
results with 7.

When you build Python set the HUGE_STACK_SIZE to yes. I believe the default
is to have thread support already on.

Even when Python app code is written with multithreading, the execution
still runs through the 'Global_Interpreter_Lock' when run. So with this
limitation in mind, should you still observe Zope/Python only utilizing
only one core in an SMP machine an alternative may be to see if you can run
Zope as FastCGI and start more than one instance, ie one for each core.
Keep in mind that FastCGI brings in a whole new dimension of it's own
problems and instabilities.

A problem that may arise in such a situation is loss of session if a request
should "switch" instances somehow. Test for this if you can.

Before attempting such I would profile/bench the box as it is now. Since
this might be considered expiremental I'd *not* use the production box
unless you are in a downtime, and have sufficient time to play around. Best
would be to try this kind of stuff on a second box and not mess with the
production one, ala - "if it works don't FIX it"!  :-)

If you succeed in getting multiple Zope instances using multiple cores, and
have lots of RAM you may also consider giving memcached a go. 

As I said earlier I'd only play with these ideas in a lab testing scenario
and *not* the production box. YMMV


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to