one more important note: If you're going to deploy this in production find yourself a python statsd library and add timers everywhere you can manage.
-- rhodey orbits On 02/18/2015 04:18 PM, rhodey 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. > > Please, allow me to ramble for a minute, take from it what you will... > > 1. IMO the idea of XMLDirectoryService is seriously dated and kinda > crazy so I wrote my own postgresql backed DirectoryService with support > for memcached. This SQL-backed DirectoryService is much easier to manage > (because SQL) and allows me to have other services work off of the same > account database. Speaking of memcached, DCS (as far as I can tell) > caches very little and could stand to benefit from using it more often. > > 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 > > 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. > > 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. > > 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!). > > 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. > > -- 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