Glad I could help. :-) I haven't tried the multisite and have used MU for QUITE a while, but did use it once successfully on an "alternative" web server called Abyss and it worked fine. All of mine are individual standalone WP installs for various clients.
I do plan on trying out the multisite soon though on Cherokee. I'll let you know if I encounter anything. On Sun, Jul 25, 2010 at 1:16 AM, C. Mundi <[email protected]> wrote: > Dennis, > > Actually, your comments have been very helpful. If I may ask... are you > using WP3 multisite, WP-mu, or separate side-by-side installations of WP for > your mutliple sites? I ask because in my preliminary reading it seems to me > that the new WP3 multisite leans strongly toward Apache. So I'm curious to > know if the new multisite feature works with Cherokee. > > Thanks again for your help and for the Totalcache tip! > > Carlos > > > > > > On Sat, Jul 24, 2010 at 8:46 PM, Dennis Clayton <[email protected]>wrote: > >> Wish I could help. Instead of WP Supercache, I switched to W3 Totalcache >> when I switched to Cherokee, seems to work much better with different >> servers other than Apache. Doubt that's the problems though. Good luck. >> >> On Sat, Jul 24, 2010 at 11:27 PM, C. Mundi <[email protected]> wrote: >> >>> >>> Updates: >>> >>> I'm pretty sure I am dealing with a WP issue, unrelated to Cherokee. But >>> since I started this thread, I figure I should finish it. In case anyone >>> finds this thread with google, I should set the record straight. >>> >>> 1. I made sure the Cherokee IO Cache is enabled. >>> 2. I installed the Wordpress SuperCache plugin. It appears it is really >>> built for apache and only "half supports" other servers. >>> 3. I reduced my php memory_limit to 64MB, in case grabbing for more >>> memory was causing thrashing. No effect. >>> >>> I am getting *lots* of 500 errors, lots of partial pages and occasional >>> "could not connect" errors, all of which are corrected by a page reload. >>> >>> I am seeing all of this with both Firefox 3.6 and IE8. >>> >>> What I'm seeing in my logs is this: >>> >>> {'type': "error", 'time': "24/07/2010 20:10:39.594", 'title': "ALERT - >>> script tried to increase memory_limit to 268435456 bytes which is above the >>> allowed value (attacker '<ip-address>', file >>> '/srv/www.<mydomain>.com/public_html/blog/wp-admin/admin.php', line 96) >>> ", 'code': "handler_fcgi.c:118", 'error': "42", 'version': "1.0.5", >>> 'compilation_date': "Jul 7 2010 01:32:03", 'configure_args': " >>> '--host=x86_64-linux-gnu' '--build=x86_64-linux-gnu' >>> '--enable-os-string=Ubuntu' '--enable-pthreads' '--prefix=/usr' >>> '--localstatedir=/var' '--mandir=${prefix}/share/man' >>> '--infodir=${prefix}/share/info' '--sysconfdir=/etc' >>> '--docdir=/usr/share/doc/cherokee-doc' '--with-wwwroot=/var/www' >>> '--with-included-gettext' 'build_alias=x86_64-linux-gnu' >>> 'host_alias=x86_64-linux-gnu' 'CFLAGS=-Wall -g -O2' >>> 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS=' '--host=x86_64-linux-gnu' >>> '--build=x86_64-linux-gnu' '--enable-os-string=Ubuntu' '--enable-pthreads' >>> '--prefix=/usr' '--localstatedir=/var' '--mandir=${prefix}/share/man' >>> '--infodir=${prefix}/share/info' '--sysconfdir=/etc' >>> '--docdir=/usr/share/doc/cherokee-doc' '--with-wwwroot=/var/www' >>> '--with-included-gettext' 'build_alias=x86_64-linux-gnu' >>> 'host_alias=x86_64-linux-gnu' 'CFLAGS=-Wall -g -O2' >>> 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS='", 'backtrace': ""} >>> >>> where I have used <expressions> in angle backets to conceal my site. >>> Note the very large amount of memory which the fcgi is requesting! It is >>> interesting to note that 268435456 = 0x1000 0000 = 256 MB which seems a >>> little suspicious to me since phpinfo() is correctly reporting that it is >>> reading memory_limit=64M from the /etc/php5/cgi/php.ini file. >>> >>> If I dig into the stock wp-admin.php, I find this at lines 95-96: >>> >>> if ( current_user_can( 'manage_options' ) ) >>> @ini_set( 'memory_limit', apply_filters( 'admin_memory_limit', >>> '256M' ) ); >>> >>> It looks like wordpress is asking for an awful lot of memory. >>> >>> So I still don;t have a solution to my problem, but I think I have an >>> idea of what the problem is, and I'm pretty sure it has nothing to do with >>> Cherokee. >>> >>> Carlos >>> >>> >>> >>> On Sat, Jul 24, 2010 at 6:05 PM, C. Mundi <[email protected]> wrote: >>> >>>> Hi. >>>> >>>> I'm interested to hear from anyone who has deployed wordpress on >>>> cherokee. I have set up a trial system: >>>> >>>> ubuntu10 x64 VPS with sub-40ms pings from my browser >>>> cherokee 1.05 >>>> mysql 5.1.37 >>>> php 5.2.10 with CGI/FastCGI and memory_limit=64M >>>> wordpress 3.0 >>>> >>>> This is a single instance of wordpress, embedded in a subdirectory of >>>> one of several virtual servers hosted on this box, per >>>> http://www.cherokee-project.com/doc/cookbook_wordpress.html >>>> >>>> The wordpress site performance is **horrible** out of the box. >>>> Unusable. >>>> >>>> My django apps (on one of the other virtual servers) are snappy, and the >>>> CPU never gets over 5%. And phpmyadmin (embedded in its own directory on >>>> the same virtual server as wordpress) runs fine as always. >>>> >>>> The system is under *very* light load -- its just for testing. >>>> >>>> Admittedly, this is the first time I've installed wordpress in over a >>>> year, and all my past experience with wordpress is on apache. I kind of >>>> doubt that WP3 is suddenly worse than earlier versions of WP. >>>> >>>> I may try to serve wordpress from apache and see if maybe WP has been >>>> tuned for apache in some way. >>>> >>>> As I said, I'm interested to hear from anyone who is serving WP with >>>> cherokee, how well its working and what you did to tune it up. >>>> >>>> Thanks! >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Cherokee mailing list >>> [email protected] >>> http://lists.octality.com/listinfo/cherokee >>> >>> >> >
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
