OnlyOffice Community Edition without 20 connections limitation

Beezus · January 21, 2020, 9:03pm

@Semjel Exactly. They recommend in their own documents for 200-400 concurrent/active users as being Quad Core 2.8GHz, 4GB RAM and 160GB disk space - easily achievable and very much surpass-able by any vhost these days at any size of company big or small. Even an old $150 Dell R410 off ebay has 12 cores, 16GB of ram and 2TB drives.

Cloudy1 · January 21, 2020, 9:22pm

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.

kesselb · January 21, 2020, 9:24pm

Yes. OnlyOffice has a huge code base.

github.com

ONLYOFFICE/server/blob/42c7c874659235618d88ed3496bffd05f9820640/FileConverter/sources/convertermaster.js#L48-L51


      
          const readLicense = function* () {

            licenseInfo = yield* license.readLicense();

            workersCount = Math.min(licenseInfo.count, Math.ceil(numCPUs * cfgMaxProcessCount));

          };

github.com

ONLYOFFICE/server/blob/7db900bdc9506862798b20a3b5556fcc9be53708/DocService/sources/server.js#L50-L53


      
          	const readLicense = function*() {
          		licenseInfo = yield* license.readLicense();
          		workersCount = Math.min(1, licenseInfo.count/*, Math.ceil(numCPUs * cfgWorkerPerCpu)*/);
          	};

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

github.com

ONLYOFFICE/server/blob/2fe7db8dcd993267fc483caf59940bb0f7e9ddc8/Common/sources/license.js#L53


      
          const redisClient = pubsubRedis.getClientRedis();

          

          const buildDate = '6/29/2016';

          const oBuildDate = new Date(buildDate);

          const oPackageType = constants.PACKAGE_TYPE_OS;

          

          const cfgRedisPrefix = config.get('services.CoAuthoring.redis.prefix');

          const redisKeyLicense = cfgRedisPrefix + ((constants.PACKAGE_TYPE_OS === oPackageType) ? constants.REDIS_KEY_LICENSE :

          	constants.REDIS_KEY_LICENSE_T);

          

          exports.readLicense = function*() {

          	const c_LR = constants.LICENSE_RESULT;

          	const c_LM = constants.LICENSE_MODE;

          	const resMax = {count: 999999, type: c_LR.Success, mode: c_LM.None, connections: 999999999, customization: false, users: 999999999};

          	const res = {

          		count: 1,

          		type: c_LR.Error,

          		light: false,

          		packageType: oPackageType,

          		mode: c_LM.None,

          		branding: false,

Here is the method building the license information.

https://github.com/nextcloud/documentserver_community/blob/6bd7769a88ae7825c9d920de303c81c925e5d1ea/lib/Controller/DocumentController.php#L93-L104

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 ). 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.

Beezus · January 21, 2020, 9:24pm

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

Cloudy1 · January 21, 2020, 9:28pm

@Beezus
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.

kesselb · January 21, 2020, 9:31pm

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

Where is this limit?

Cloudy1 · January 21, 2020, 9:35pm

@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):
const MAX_CONNECTIONS = 20

If you also want to change the message:
js/sessionlimit.js:
OC.Notification.show(t("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.

kesselb · January 21, 2020, 9:36pm

Nice finding How could I miss that

Semjel · January 21, 2020, 9:39pm

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.

Beezus · January 21, 2020, 9:41pm

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

Semjel · January 21, 2020, 9:46pm

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.

Cloudy1 · January 21, 2020, 9:51pm

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.

Beezus · January 21, 2020, 9:55pm

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.

kesselb · January 21, 2020, 9:56pm

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

Semjel · January 21, 2020, 9:56pm

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.

Semjel · January 21, 2020, 10:17pm

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.

tanghus · January 21, 2020, 11:24pm

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?

Semjel · January 21, 2020, 11:41pm

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.

tanghus · January 21, 2020, 11:58pm

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.

Semjel · January 22, 2020, 12:14am

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.