... | ... | @@ -84,7 +84,7 @@ The implementations compared in the figure above are: |
|
|
* **Blobs + session cache:** same as above, but also caches session in server-side, thus avoiding having to query couch for user authentication data on every request.
|
|
|
* **Blobs + session cache + persistent http:** same as above, but also reuses HTTP connections on client side, thus avoiding having to open a new TLS/TCP connection for every request.
|
|
|
|
|
|
As it can be seen, the BLOBs implementation (with all the performance features) outperforms the legacy implementation for the same amount of data as the number of messages decrease and the size of each message increases.
|
|
|
As it can be seen, the BLOBs implementation (with all the performance features) outperforms the legacy implementation for the same amount of data as the number of messages decrease and the size of each message increases. This is expected, as BLOBs implementation is targetted to have a better performance with larget documents. Also, BLOBs only looses to the legacy implementation because legacy includes batched upload/download using the same HTTP request, while BLOBs still doesn't. Once that feature is implemented, we should see better results for BLOBs even for larger amounts of emails with smaller sizes.
|
|
|
|
|
|
## Server-side backend storage optimization.
|
|
|
## Server scalability. |
|
|
\ No newline at end of file |