Performance

Webslice Serverless is designed to be performant, scalable and cost effective by default, but various options and paths exist for those looking to extract even more performance or value.

Caching

Implementing strong caching strategies is one of the most effective ways to improve performance and reduce costs on Webslice Serverless. When content is cached properly, our CDN can serve requests directly without invoking your serverless function, which:

• Dramatically reduces response times: CDN edge locations serve content closer to your users
• Lowers your costs: Fewer invocations means lower resource consumption
• Increases reliability: Cached content can be served even during deployments

Static asset caching should be aggressive. Set long cache times (e.g. 365 days) for versioned assets like JavaScript bundles, CSS files, and images. Use cache-busting techniques (filename hashing) to ensure updates are delivered when needed.

Dynamic content caching should be implemented where appropriate. Even short cache times (e.g., 60 seconds) on frequently accessed pages can significantly reduce load and costs.

Resource Configuration

Finding the right balance of memory and CPU cores is crucial for both performance and cost optimization:

• Default configuration: We provide sensible defaults that work well for most applications
• Smaller resources: Reducing memory/cores can lower costs, but may increase response times for compute-intensive operations
• Larger resources: Sometimes increasing resources speeds up requests enough to offset the higher per-invocation cost, especially for CPU-bound workloads

Recommendation: Monitor your response times and costs over a representative period. If want faster response times, try increasing resources. If response times are consistently fast with headroom, consider reducing resources to optimize costs.

Concurrency Settings

Concurrency controls how many simultaneous requests your deployment can handle:

• Minimum: The number of instances always running and ready for traffic (default: 1)
  • Increasing this reduces cold starts but increases baseline costs
  • Raise this if you need consistently fast response times during traffic spikes
• Maximum: The limit of instances that can run simultaneously (default: 10)
  • Increase this to handle more traffic but increases maximum potential costs

Recommendation for typical workloads:

• Keep minimum at 1 for cost efficiency unless you require guaranteed instant responses
• Increase maximum to 20-50 if you expect significant traffic spikes
• Monitor your actual concurrency usage and adjust accordingly
• Use Spend Limits to safeguard against unexpected cost spikes

Recieve very little traffic?

If your website recieves very little traffic, or is only needed occassionally you can even set your concurrency to 0 to reduce costs even further. This can be an effective trade-off if slower response times are not a concern.

File System Performance

The Webslice Serverless platform uses a NFS based file system to store files for your website. We have a layer on top of NFS to accelerate the performance of the file system, however filesystem IO is generally the bottleneck for a request’s performance.

There are a few things you can do to improve the performance of your website:

• Minimise the use of flock during a request
• Avoid using SQLite, SQLite generally doesn’t work well with NFS and will degrade performance.
• Minimise the number of file system writes during a request.

Persistent Storage

Rather than regenerating objects such as responsive images each deploy, utilise the persistent storage to allow objects to persist between deploys.

Region Selection

Choose the region closest to the majority of your users to minimize latency. Even with our global CDN, dynamic requests that reach your serverless function will benefit from being geographically closer to your user base.