Thank you very much for all your support! On Wed, Feb 18, 2015 at 4:49 PM, Andre LaBranche <d...@apple.com> wrote:
> Hi Rhodey, > > Comments inline. > > > On Feb 18, 2015, at 4:18 PM, rhodey <rho...@anhonesteffort.org> wrote: > > > > I've been running DCS in production for the past ~year, at the moment my > > deployment supports ~800 users. It took *a lot* of reading through doc > > and code to feel even remotely comfortable with storing real data for > > real people and I still don't feel all that great about it. > > We are slowly compiling actual documentation. I'll take this as feedback > in support of accelerating this process. > > > ... > > > > 2. DCS uses the python twisted framework but at the same time it > > doesn't-- calls to DirectoryService (regardless of the implementation) > > are blocking 0.o > > I believe this is addressed in 6.0+ with the new twext.who stuff that is > all async, iirc. > > > 3. DCS has this weird multi-process, master-slave concept where multiple > > DCS instances run on the same box-- I just think this is weird and > > dealing with dead processes has been strange. > > The Python GIL means we need a multi process architecture to saturate CPU > on multi core systems. Technically these processes are all part of the same > service instance because they all cooperate on doing the work. > > > 4. If a user uploads a contact containing a photo and you're using a > > database for storage (as you should), DCS will store that photo in your > > database-- yuck! Even with your 1000 users, each with maybe 100 contact > > photos, things get kinda bloated. So, I modified DCS to strip contact > > photos from contacts and store them in Amazon S3, then piece them back > > together on demand. > > Cool hack :) > > > 5. Someone could DOS my DCS instances via network resource exhaustion > > very easily and there is very little that I could do to stop it other > > than launch a crazy number of EC2 instances and burn through money. DCS > > is not efficient (blocking calls to DirectoryService, etc) and I feel > > very uncomfortable having any less than than two m3.medium instances > > running at all times (costly!). > > Understood, however this is true of any network service that limits its > own concurrency (imo this is required of any sane service). Part of the > challenge is the extremely large range of request cost for legitimate > CalDAV requests. We are moving to a model where we do more work a > synchronously in a database work queue, and we now have a notion of cost in > that implementation, so we are becoming better equipped to address resource > utilization problems. > > > All that being said, DCS is still the best free and open source option > > out there but I wish I had written my own WebDAV server from scratch > > using 'dropwizard' instead. The world of high availability services > > changes so rapidly and many of the ideas in this project are dated-- > > like, even table joins really shouldn't exist anymore. > > We're not yet ready for NoSQL but maybe someday :) > > Thanks for the feedback. I'm interested to hear anything else you'd like > to share about your experiences hosting DCS. > > -dre > > > > > -- rhodey orbits > > > >> On 02/18/2015 01:04 PM, Gaurav Jain wrote: > >> Hi, > >> > >> Thank you very much for CalendarServer > >> > >> I have few questions: > >> > >> * I used CalendarServer-5.2.2 during development phase. > >> * Now I want to use it for some real (users) use cases. > >> * Right now, I do not have any scaling issues. > >> * I run it on Ubuntu EC2 instance. > >> > >> My question is: > >> > >> * Has CalendarSever-5.2.2 been used in PROD deployments? > >> * Since I don't have scaling issues, is it ok to use XMLDirectoryService > >> for like 1000 accounts? > >> > >> Any tip would be useful for PROD deployments. Even for 1000 users, we > would > >> like it not to go down at all. > >> > >> > >> Best Regards, > >> Gaurav Jain > >> > >> > >> > >> _______________________________________________ > >> calendarserver-users mailing list > >> calendarserver-users@lists.macosforge.org > >> https://lists.macosforge.org/mailman/listinfo/calendarserver-users > > _______________________________________________ > > calendarserver-users mailing list > > calendarserver-users@lists.macosforge.org > > https://lists.macosforge.org/mailman/listinfo/calendarserver-users > _______________________________________________ > calendarserver-users mailing list > calendarserver-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/calendarserver-users >
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
