[BlueOnyx:26061] Re: BlueOnyx Webserver Performance a.k.a. the impact of "open_basedir"

Tobias Gablunsky t.gablunsky at cbxnet.de
Mon Apr 3 06:12:59 -05 2023


Hi Michael,



thanks for looking into it. I was really suprised by your perfomance measures. But I found there is a difference in commenting out the open_basedir option and disabling it by setting it to the value "Off". When disabling the php process gets the server wide setting, which isn't off.



Please repeat your test with "php_admin_value[open_basedir] = Off". I am sure you will see the difference. The website I just tested (a real world wordpress with lots of content and plugins installed) just took 5 seconds before and less than 1 second after the change..





Regards,
Tobias



-----Ursprüngliche Nachricht-----
Von: Michael Stauber <mstauber at blueonyx.it>
Gesendet: Freitag 31. März 2023 21:43
An: blueonyx at mail.blueonyx.it
Betreff: [BlueOnyx:26060] Re: BlueOnyx Webserver Performance a.k.a. the impact of "open_basedir"


Hi Tobias,

> we had some complaints lately about very poor web server performance on
> our BlueOnyx servers. All affected sites are cms driven, mainly
> Wordpress. We did a lot of tests and comparisons with other hardware and
> software - always looks as if the reason was within BlueOnyx itself.
>
>
> We now are very sure to have found the reason, why a non-blueonyx
> webserver is about 3 times as fast as a blueonyx one: If you disable
> open_basedir the problem is gone (A single request on
> https://server.name/wp-login.php <https://server.name/wp-login.php> is
> sufficient to see the difference).
>
> The problem behind that is, that the php feature "Realpath cache" is
> disabled when open_basedir is enabled, see:
>
> https://serverfault.com/questions/158584/php-safe-mode-open-basedir-lstat-performance-problem <https://serverfault.com/questions/158584/php-safe-mode-open-basedir-lstat-performance-problem>
>
> https://bugs.php.net/bug.php?id=52312
> <https://bugs.php.net/bug.php?id=52312>


Ok, I just did a test on a 5211R. Two identical Vsites. Both using
PHP-FPM with PHP-8.2.4 from the shop. And the latest WordPress also
installed from the shop.

I just finished the web based initial setup of Wordpress, so both
installs have the same sample configuration and identical appearance.

One is installed as "site1", the other as "site2".

I then edited /etc/php-fpm-8.2.d/site2.conf and commented out the ...

php_admin_value[open_basedir] = [...]

... line and restarted PHP-FPM:

systemctl restart php-fpm-8.2

I then prepared Firefox to have two tabs open with the debugging console

activated and the "Network Analysis" open and accessed the Worpress
installs. "site1" in one tab, "site2" in the other.

Both Vsites use SSL (LE certs), so I used HTTPS for testing.

site1: load time 2.31s on first load, 1,06s on reload
site2: load time 2.84s on first load, 1,17s on reload

So the Vsite w/o open_basedir actually loaded SLOWER and reloaded SLOWER.

I then hit reload a couple of times and the results were all over the
place. The best speed I could ever get on reloads for "site1" was 1,01s
and the best speed for reloads of "site2" I could ever get was 0,96s.

So the best speed gain (after many retries) measured in 0,05s (five
miliseconds!).

I then opened a new Firefox in private mode and tested "site1" (initial
load and multiple reloads) and then closed that browser, opened another
Firefox in private mode and repeated the same steps for "site2".

Again the results were all over the place and I could make out no
discernible speed advantage of one over the other. In fact in some cases

both the initial load as well as the reload were faster on the Vsite
with open_basedir enabled and on retries the Vsite with open_basedir
disabled was faster.

So if there is any speed advantage of NOT having open_basedir
configured, then in my experience it is so miniscule that it's almost
impossible to measure.

> We are aware of that open_basedir is a security feature. But I have to

> open a discussion here: Is it really needed? From my understanding there
> should be file access rights permitting access of every website only to
> areas they are allowed to access and permit the others.

Recall that we're doing shared webhosting on a BlueOnyx. So normally a
PHP script can access *ANYTHING* on the server that the user who runs
the script has read permissions for. Without the limits imposed by
open_basedir a malicious user could use scripts to get read access to
privileged information that includes some of the server configuration as

well as some limited information about what other Vsites are present and

possibly also read access to some of the data that other Vsites have
hosted in their webspace.

For that reason open_basedir is really an absolute must have to isolate
content of Vsites against access from other Vsites.

> Nice would be an option to disable it per site. But at least we'd need

> an option to disable it per server.

That is certainly doable, but it would be a feature that only the server

admin can activate/deactivate on a per Vsite level.

> Maybe it would be a good compromise to include this plugin
> https://github.com/Whissi/realpath_turbo
> <https://github.com/Whissi/realpath_turbo> to get both, performance and
> security as for sure this is we all want. In addition to disabling
> open_basedir they disable dangerous PHP functions (link,symlink)

The last update to that code on GitHub was posted on January 4th, 2020.
The latest PHP versions available at that time were PHP-7.4.1 and
PHP-7.3.14.

https://github.com/Whissi/realpath_turbo/blob/master/realpath_turbo.c
indicates that this is a Zend extension and in PHP-8.0, 8.1 and 8.2 the
API for Zend extensions changed drastically (yet again). So I doubt that

this extension will work in any modern PHP. In fact: It won't work in
any PHP that hasn't been EOL'ed long ago.

It having received no updates in three years is a really bad sign. For
all intends and purposes it is abandonware and I wouldn't want to base
critical infrastructure on something that is no longer actively supported.

Out of curiosity: What BlueOnyx version and PHP versions (also PHP
implementation - DSO, RUID, suPHP, FPM) are you testing this and what
speed improvements (if any) do you see?

--
With best regards

Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20230403/bfc6cdcc/attachment.html>


More information about the Blueonyx mailing list