On Jul 3, 2012, at 12:49 PM, emport wrote:
hi,
Andre LaBranche-2 wrote:
Yes, that is expected in your configuration, for this ancient version. In your version, there is a python software load balancer that distributes requests to available instances. You now have three available instances and not one, so it's expected to see additional listeners.
ok, this sounds reasonable.
Andre LaBranche-2 wrote:
There is, however, one additional variable that affects concurrency, the config variable MaxRequests.
hm, where can i find this variable? i didn't see it in caldav.plist...
http://trac.calendarserver.org/browser/CalendarServer/tags/release/CalendarS... If MaxRequests meant the same thing then (in 2.4) as I think it means, the default value of 600 is ... potentially terrifying; it should stop accepting new work far sooner than that. Anyway, this isn't the bottleneck for you :) -dre
Andre LaBranche-2 wrote:
Just to set your expectation, doing such a large-distance upgrade successfully (when there is data to be maintained / upgraded) will be a lot of work.
do you mean an upgrade from 2.4 to 3.x? i'm a little bit curios what you mean by *a lot of work*. my naive approach would be: set up the server, migrate all *.ics files and go to lunch :)
kinds regards, emport
-- View this message in context: http://old.nabble.com/Performance-and-Parallel-Requests-to-Calendarserver-tp... Sent from the Calendar Server - Users mailing list archive at Nabble.com.
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users