OnlyOffice Community Edition without 20 connections limitation

Hi, I followed this discussion and did some tests to check the ressource usage:
My server needed ~200MB RAM for 30 connections and not noticably more cpu with the php document server (tested with a small text document). It seems that one user can open more than 20 connections in the same browser window, but then any other users are denied. At least it seemed like that in my test.

But in the php version you can just increase the limit yourself in the php files without recompiling and it seems to work just fine.

1 Like

Yes. OnlyOffice has a huge code base.

As you already know they limit the number of concurrent workers to 20 for the community edition. That’s happening above.

Here is the method building the license information.

I don’t see such a limitation in general for docummentserver_community (nextcloud’s implementation of their server). The limit is probably the number of php processes. But I might be wrong.

heartbreak the community about the futur of the nextcloud client…no news then. You can read it it’s very interesting…

@Nemskiller I probably did. I have no idea why we are talking about Virtual Drive now. That’s the OnlyOffice thread? It seems to me that you have to mention that with every of your posts (hey make it your signature :smile:). Virtual Drive seems to be a complicated topic. I see a pull request from November 2019 on GitHub. It’s not dead people still work on it.

@Cloudy1 Which is the PHP version? The ony released with Hub? I cant imagine that wouldnt need a recompile.

I’m talking about the documentserver_community included in nextcloud 18. And I said that it works without recompiling for me, because the php version is not compiled. But I only tested it using ~35tabs in the same browser.

But in the php version you can just increase the limit yourself

Where is this limit?

@kesselb @Beezus

I changed the following in nextcloud/apps/documentserver_community/:

lib/Controller/StaticController.php (line 92):
} else if ($this->sessionManager->getSessionCount() >= 20) {

lib/XHRCommand/AuthCommand.php (line 37):

If you also want to change the message:
js/sessionlimit.js:"documentserver", "The community document server only supports up to 20 concurrent sessions"), {

Increasing the limits in these lines works for me. I’m not sure for what each of the occurences is exactly, but I just set both to the same high number.


Nice finding :+1: How could I miss that :see_no_evil:

Interesting. When I get to playing around with it, I’ll be curious to see how many connections it will support before hitting the real limits.

I should be able to spin up a test server to give this a shot and try and hammer it with clients.


I imagine the PHP version could be somewhat less efficient than the original implementation, but I suspect we’ll find a hard ceiling of 20 connections makes no practical sense.

It probably depends much on what each instance does, so it could be hard to test, but I think more than 100 shouldn’t be a problem on decent hardware. This is just based on my quick test though. With 30 I had a hard time noticing a difference in cpu load so a few percent max. Memory usage probably depends on the documents, so a test with big documents would be interesting.
I won’t test it though, because only use it myself anyway.

Most likely it the OnlyOffice server just stores changes in RAM and connects users through that document, all formatting and main processing is done in browser. I cant imagine it is very CPU intensive at all. If Nextcloud had any real concerns on OnlyOffice’s performance they wouldnt have given the option for users to All-In-One install onto the same server.

1 Like

Hmm. I have wished that it was not limited. But yes that’s probably OnlyOffice’s business model. At least it should be able to workaround easily. I’m not a heavy foss advocate like @Semjel but I dislike “shipping” (it’s not shipped actually but installed by default) a user/session limited software component. Very sad :disappointed:

1 Like

Yes, it must depend on what each editing session is doing, so it would be hard to test perfectly without a live environment. Perhaps some could test that in due course.

Bearing in mind, though, their main selling point is that almost all the processing takes place on the client, and they can support hundreds of live connections on a 4 core server.

Just to say, I wouldn’t claim to be a heavy FOSS advocate, in the very zealous sense.

But I (and I think quite a lot of moderate folks) do make a distinction between software that really respects the idea of opensource, and those that use opensource to take advantage of its marketability, but their opensource parts are only really meant to act as a limited demo for their paid products.


I totally respect OnlyOffice decision about limited connections, whether it be for commercial or performance reasons, but imho it should have never been bundled with NC. Distributing it as a separate app should suffice.
Therefore I think the discussion about limitations should be continued at whatever forum OnlyOffice has, but the issue of bundling it with NC is relevant here. Which also is what the title of this thread is, if I interpret it correctly?


Trouble is, the OnlyOffice forum is a ghost town, and I expect discussing it over there would not be very fruitful.

Now that it’s a default part of the new Nextcloud Hub, I think it’s fair game to discuss it over here, where there’s a much better chance of finding folks with a similar view.

As you say, they have the right to choose their monetization strategy. It’s just that some of us choose to stick to truly opensource projects, which Nextcloud has always been. In some ways, I think it makes more sense to discuss it here.


I share your view, but for me the discussion should be about whether it should be bundled, not how to overcome the limitation. The option to use it was already there, although not as seamlessly as now.
I’d hate to see Nextcloud falling into the same pit as ownCloud did, and loose the respect of the F(L)OSS community.
I stopped as an ownCloud community developer for that reason.


Yes, I think where perhaps I differ, is that while I respect their right to choose their strategy, if they want to make deliberately limited opensource software, then we also have the right to take that source and see if we can make it better, for our purposes.

The way I see it, they can use that model, but they can’t have their cake and eat it, as it were. You can’t have benefits of claiming to be opensource, but also the control of a proprietary model. So, I think it’s fine for us to see if we can modify it for our requirements.


Your arguments are valid. I hope for an official response from the “head office”, but…