|
Scalability
SummaryWhile the default library suffices for small-scall WebDAV installations, there are areas that can be optimized for maximum perfmance, and operations in a load-balanced environment. This manual aims to cover the most important bits. ObjectTreeAll operations are done on Nodes managed by the ObjectTree. In order for the ObjectTree to find the nodes, it must traverse the entire tree. You should optimize getChildren() and getChild() in your nodes as much as possible to accomodate for it. You can avoid traversing the tree by subclassing Sabre_DAV_ObjectTree and overriding getChild, getChildren and childExists with your own methods. If this really helps you highly depends on your situation. Move and CopyMove and Copy operations can be slow, especially when moving/copying bigger objects. Each of these methods tranferses the entire tree, and operates on them one-by-one, as an example, a move of a directory follows the following pattern:
You can override the copy and move functionality by subclassing the ObjectTree, if this makes sense for you. In addition, if you purely use SabreDAV to expose a filesystem, you can choose to use Sabre_DAV_Tree_Filesystem instead of Sabre_DAV_ObjectTree. This class is specifically optimized for plain filesystems. DeleteDeleting files has similar problems, as it will also generally traverse the objecttree. If you have created your own File and Directory objects, you might be able to optimize access by overriding delete(), if your backends allow it. CalDAVCalDAV is currently a bit bulky. For a lot of operations (such as getting a list of Events in a calendar) all the iCalendar objects within a calendar will be generated. You are encouraged to make sure all your objects are properly cached in your Calendar backend. Load Balanced SabreDAVSabreDAV has a few standard utilities for locking and catching 'temporary files'. These classes (Sabre_DAV_TemporaryFileFilterPlugin and Sabre_DAV_Locks_Backend_FS) store information on the filesystem. It would be possible to store these files on a network location instead, as long as the network filesystem has proper support for flock() (which NFS as an example doesn't). Storing locks could be implemented in a database server or caching layer such as memcached, the temporary files are a bit bigger, so that might pose some issues. We chose to not supply any plugins for these alternative backends, as there are a lot of options out there and impossible to cover them all. Instead it was made really easy to extend these subsystems. Currently 'temporary files' don't get cleaned up, and a cron job should be made to delete older files (>1 hour). Large Files | |
One could also look at combining the Sabre php files into a single source file?
A profiler will show that >50% of the time is spend loading source files (each an expensive operation with overheads).
I've noticed it was slow too.
Are you using APC?