[CalendarServer-users] DCS Production Deployment

rhodey rhodey at anhonesteffort.org
Wed Feb 18 16:36:24 PST 2015


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 at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/calendarserver-users
>>
> _______________________________________________
> calendarserver-users mailing list
> calendarserver-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/calendarserver-users
> 


More information about the calendarserver-users mailing list