# Load Testing **URL:** \ **Category:** Questions\ **Created:** [March 9, 2020, 4:29pm UTC](https://community.n8n.io/t/load-testing/978 "2020-03-09T16:29:12Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![tcurdt](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/tcurdt/32/215_2.png) [@tcurdt](https://community.n8n.io/u/tcurdt)\ **Post date:** [March 9, 2020, 4:29pm UTC](https://community.n8n.io/t/load-testing/978/1 "2020-03-09T16:29:12Z")
Has anyone used n8n with traffic spikes? Is there some documentation on the software architecture behind n8n? Will a request be pass through the whole workflow? Or are the requests decoupled from the processing? I am wondering what will happen when a workflow is hit with e.g. 100 or even 1000 request/s. Of course I can test this myself but I thought I ask first how much real world usage n8n has gotten so far. ---
**Author:** ![jan](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/jan/32/9_2.png) [@jan](https://community.n8n.io/u/jan)\ **Post date:** [March 9, 2020, 4:53pm UTC](https://community.n8n.io/t/load-testing/978/2 "2020-03-09T16:53:07Z")
No there has been no load testing done. It is also quite hard as it would depend a lot on the hardware and even more on what exactly the workflow is doing. If you would like to do a lot of short running workflows I would advise to set `EXECUTIONS_PROCESS=main` > **[Explore n8n Docs: Your Resource for Workflow Automation and Integrations |...](https://docs.n8n.io/#/configuration?id=execute-in-same-process)** > > Access n8n Docs for comprehensive guides on workflow automation and integrations. Learn how to integrate apps and enhance your automation capabilities. Because if that option gets set, it executes everything in the main process. If that does not get set, it creates (by default) a new process for every workflow execution and this has obviously much more overhead and the startup time increases a lot. From a few ms to like almost a second. Here a related topic which talks about it: > [@WorkflowRunner use 'fork' to create subprocess , when WebHook always receive request, will make many subprocess , and CPU usage so high](http://community.n8n.io/t/workflowrunner-use-fork-to-create-subprocess-when-webhook-always-receive-request-will-make-many-subprocess-and-cpu-usage-so-high/348/1): > > Example: When I use Apache ab to benchmark workflow(workflow just make a http request to other website), and server CPU usage so high so many process(/usr/local/lib/node\_modules/n8n/dist/src/WorkflowRunnerProcess.js) was created. ---
**Author:** ![tcurdt](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/tcurdt/32/215_2.png) [@tcurdt](https://community.n8n.io/u/tcurdt)\ **Post date:** [March 9, 2020, 7:26pm UTC](https://community.n8n.io/t/load-testing/978/3 "2020-03-09T19:26:06Z")
The underlying architecture is more important than the hardware. The absolute numbers don’t matter. The information about the forking is exactly the kind of info I was looking for. What also would be important to know is how the request/response time is dependant on the actual workflow. Is there some kind of back pressure on high loads? These kind of things. ---
**Author:** ![jan](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/jan/32/9_2.png) [@jan](https://community.n8n.io/u/jan)\ **Post date:** [March 10, 2020, 12:21pm UTC](https://community.n8n.io/t/load-testing/978/4 "2020-03-10T12:21:59Z")
Not sure if anything is more important than the other. In the end is the throughput currently probably decided by a formula similar to: ```auto [hardware] X [architecture] X [workflow] = [throughput] ``` So each of them can increase or decrease the throughput. n8n is currently not optimized for high throughput at all or in any way. It does currently also simply not scale very well. Improving that and many other things and to make n8n generally enterprise-ready and able to be used in big deployments is one of the things which we will work on over the next months to a year.