[EMAIL PROTECTED] wrote: [snip] > > 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 -Mike _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"