<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 27, 2016, at 8:36 AM, Gaurav Jain <<a href="mailto:monkeyfdude@gmail.com" class="">monkeyfdude@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">* Could you please share documents of CalendarServer performance and load/stress testing?</div><div class="">* How much memcached helps with performance of CalendarServer?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">For eg. I found this. 55,000 seems quite low number.</div><div class=""><br class=""></div><div class=""><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol";font-size:16px;margin-bottom:0px" class=""><li style="box-sizing:border-box;margin-top:0.25em" class="">Test Scenario: With a well tuned multi-server deployment of identically configured caldav servers behind a load balancer, and a separate Postgres server with a fast RAID 0, in a low-latency lab environment using simulated iCal client load, it takes 5 or 6 caldav servers to saturate the postgres server (which becomes i/o bound at a load of about 55,000 simulated users in this test).</li></ul></div></div></div></blockquote><div><br class=""></div><div>We don't really have anything published specifically about performance. The excerpt you reference above (from our <a href="https://github.com/apple/ccs-calendarserver/blob/master/doc/Admin/MultiServerDeployment.rst" class="">MultiServerDeployment.rst</a> document) is kind of old, and beyond that, doesn't sufficiently explain the parameters of the test scenario. The amount of load generated by clients depends a great deal on specifically what kinds of requests those clients are issuing, and what the general workflow is. For example, 1000 people posting one 'non-scheduled' event (which is our strange term for events with no attendees, although they do occur at a time) per day would present WAY less load than 100 users posting one event with 10 attendees per day. Accordingly, any sort of performance / scalability talk must take the workload into account as the most important factor.</div><div><br class=""></div><div>We have good tools for characterizing the workload of any CalendarServer, through analysis of access.log - check out <a href="https://github.com/apple/ccs-calendarserver/blob/master/contrib/tools/protocolanalysis.py" class="">contrib/tools/protocolanalysis.py</a> This tool outputs a report summarizing the activity on your server, looking at the activity from a lot of different angles. The results might not make a lot of sense to you, but we could probably help you understand them and set expectations with respect to scalability.</div><div><br class=""></div><div>We also have a pretty nice <a href="https://github.com/apple/ccs-calendarserver/tree/master/contrib/performance/loadtest" class="">load simulator</a>, and it's actually documented - check out <a href="https://github.com/apple/ccs-calendarserver/blob/master/doc/Admin/LoadSimulation.rst" class="">LoadSimulation.rst</a> The default profile it uses provides what we consider to be a good mix of request types for an 'average' server where people are taking advantage of most of the server's features. It's also configurable, with the goal of allowing you to create a load sim profile that closely approximates what you see in production. There are several example profiles in there to look at for reference.</div><div><br class=""></div><div>memcached is rather important, and it becomes more important as general activity level rises. We tried to get rid of it not too long ago, and ended up bringing it back because stuff was too slow without it. The service is not designed to allow memcached to be optional.</div><div><br class=""></div><div>Also I think I would challenge the characterization of 55,000 users as 'quite low', unless you mean "low for that amount of hardware, compared to other common services", in which case... well, yeah, kinda. It is hard to compare CalDAV to other common types of services like email because the data model is soooo much more complex, with tons of inter-dependcies.</div><div><br class=""></div><div>Cheers,</div><div>-dre</div></div></div></body></html>