It is hard to tell what happens with this particular configuration. There are many parameters in play. Instead, I can give a rough description of what should happen within that period. Having that you can tell if that works in your case or not. I can say that in general case of a public blockchain network this will unlikely work.
Now, you can expect the following things to happen during the block time:
- A block producer should import the current block. That means executing the runtime with the contents of the block, primarily the transactions.
- The result of block execution should be written into the database. This, however, can be performed asynchronously. It still will take some CPU, IO and memory bandwidth, and thus may need to be taken into account.
- At some point the block producer will need to come up with its own block. It will fetch transactions ready for inclusion and try to apply them. This may take more time than importing a corresponding block, since the block producer may try to apply a transaction but roll it back.
- The created block and its state changes will have to be saved into the database.
- The block producer then will have to disseminate the block to its neighboring peers. The peers in turn will do the same. Hopefully that will lead to each and every node being aware of that block in a certain amount of time. This process is not instantaneous and depends on how the nodes are connected, their bandwidth and etc.
- At some point the next block producer will have to produce a block.
Note that at certain low configuration of block time, the next block producer might have not received the current block. In that case, the next block producer will create a block chained to the previous and not the current block. This is not the end of the world, but it will lead to wasted effort, which will in turn affect the worsen the performance.
There is an article which expands on this.