Solved thread

This post is marked as solved. If you think the information contained on this thread must be part of the official documentation, please contribute submitting a pull request to its repository.

Phalcon on Alpine Linux with Hiawatha Web Server

Hey People,

In an attempt to build a lightweight, performance friendly, secure web platform i came up with the PHA stack. I thought it would be fun to explore phalcon on Alpine, so i kept track of what i did and write it all down here.

https://github.com/commandline-be/commandline-blues/wiki/Dev:-Phalcon-with-Hiawatha-WebServer-on-Alpine-Linux

(link was broken, now fixed)

PHA Stack stands for Phalcon with Hiawatha on Alpine Linux as these projects focus on small, simple, secure which most often implies performance while still lightweight.

I believe these projects attain these goals.

Phalcon is a (really fast) PHP framework built on and extendable by Zephir which is an open source, high-level language. Zephir is designed to ease the creation and maintainability of extensions for PHP with a focus on type and memory safety. >> go to documentation

Hiawathahas been written with security in mind. This resulted in a highly secure webserver in both code and features. Hiawatha can stop SQL injections, XSS and CSRF attacks and exploit attempts. Via a specially crafted monitoring tool, you can keep track of all your webservers. >> go to documentation

Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency.

Let me know if this works for you, what improvements can happen etc. There should be no mistakes but it can be incomplete as i think to have omitted small configuration changes in php and php-fpm configuration.

Yes, i did not mention a database choice because this is agnostic to both Phalcon and PHP.

Best Regards,

commandline.be

you must search this thing on https://www.janbaskdigitaldesign.com/ if i am halping you its my plesure



61.9k
Accepted
answer
edited 22d ago

Kind of exotic stack - but nice contribution @commandline-be

Thanks.

While reviewing the features and requirements for each of PHA i came to the conclusion it would be stable, scaleable, secure out of the bow. Hence i seek to learn/develop based on PHA to see if i'm right.

On top of that the footprint for PHA is low for each component. An image based on this one will be small and supposedly fast as can be.

Kind of exotic stack - but nice contribution @commandline-be



60.0k

The upside to using anything other than Apache is a much easier config syntax. My favorite for dev work is Caddy because it uses a Caddyfile and so sharing between people is very easy.

Similar reasons drove me to hiawatha, i was appaled by the growing complexity of Apache. I just needed a webserver/reverse proxy.

I saw caddy before but never ended up doing anything with it, since not being a dev. Maybe i should consider doing the same and offer a PCA stack :)

The upside to using anything other than Apache is a much easier config syntax. My favorite for dev work is Caddy because it uses a Caddyfile and so sharing between people is very easy.

What i'm most curious about is if a machine built on an off the shelf PHA-stack would perform admirably or miserably :)

Are there interesting benchmarks for me to run ?



60.0k
edited 19d ago

Caddy would make a terrible web server for a CDN since it is simply slower than Apache, nginx and other ones. It excels though in its configuration, ACME SSL setup with providers plugins, fresh cutting edge support for HTTP/2, newer experimental protocols and ease of use features. Its probably also not the best web server for an API that is about tons of small pings with JSON or Graph QL. I think thought that its quite good for my kinds of uses which are SPA where most of the work is being done in Javascript and with a minimal amount of hits on the server per user or that each user is expected to be more valuable than the tiniest fraction of a cent each. Basically the time spent in PHP and Database is so much larger than the HTTP part that the slower speed of Caddy is irrelevant. Caddy keeps improving slowly as Go rolls out better HTTP tech so as far as that goes its largely just improvements that happen for free as time goes on. Also I think that memory usage when using Phalcon is pretty much not an issue. Phalcon makes the stack much more of a lower fixed cost for memory usage. I wonder if anyone would ever run out of memory using Phalcon before their IO or CPU became overrun. I think that more people should check Caddy out as an alternative. I hope that more people use Caddy for at least the earlier part of development since investing upfront in Apache or nginx configs can get a new project off to a very slow start. I'd rather just copy my trusty Caddy file into a new Phalcon project and then run it that way over something like 8080/8443 and with full instant real SSL certs (not self-signed) while developing in a VM instead of doing unencrypted the entire time and then changing over later in the project. Caddy gives me more of a painless early process without a system installation. Then later when its time to deploy just a quick setup of the systemd service file and the creation of the /etc/caddy with the typical sites-available, sites-enabled to then just import the local Caddyfile. I think that this reall the best usability and I can understand if they think that the good features aren't worth the trouble but then I wonder what are you really getting out of this PHA stack that you couldn't get easier with nginx? The nginx syntax is pretty decent, definitely better than Apache IMO (which really shows its age in this regard). Nginx would be my goto for massive static content and then if its SPA apps then for sure its Caddy. I suppose that if I needed massive real time absolute fastest responses then I wouldn't use Caddy because its just slower to some degree and if 0.1ms means something then that couldn't be the best tech.

edited 19d ago

For the kind of website i'm using i think Hiawatha Webserver (www.hiawatha-webserver.org) does great. I know for sure some people run it on sizeable websites because it manages to handle a lot of load and has great configuration. When it comes to a webserver-only requirement, Hiawatha is it. Even with reverse proxy functionality etc. The built in security features are simple yet effective.

HTTP/2 support is not yet there but in the works.

FYI : https://www.hiawatha-webserver.org/howto

FYI: https://www.hiawatha-webserver.org/manpages/hiawatha

I could not find the benchmark article but this slideshare sums my motivation for Hiawatha up pretty nicely : https://www.slideshare.net/Brunty/hiawatha-the-best-webserver-youve-never-heard-of

And this PDF https://www.hiawatha-webserver.org/weblog/9 from a while ago.

To me what hiawtha offers is exactly how i think stuff should work. Webservers serve webpages as a frontend to backend services. They do no integrate anything facy. They just offer webpages :-) All else should be taken into consideration elsewhere.



60.0k

Nginx was the hipster goto alternative for Apache for a while for this kind of stuff. Does it compete in those same categories? I'll read the two non-doc links later. I'm considering giving up nginx for usage since Caddy does what I need better for that better (newer protocols, features and easier configuration) and then just using Apache mod php for all of the other use cases and less FPM related headache. I might consider Hiawatha though if its good. I don't really need to invest into learning another web server though if something kind of better will just come out in 3-5 years since trusty Apache will still be there keeping up a bit and working well even with its internal warts.

Hiawatha is not really a hipster thing. It is most respected with people who do have a technical background.

Let me know what you think after some testing, if HTTP/2 is high on your list you'll have to wait though.



60.0k

I like this from the docs:

UrlToolkit {
    ToolkitID = phalcon
    Match ^/public/ Skip 1
    Match ^/(.*) Rewrite /public/$1 Continue
    RequestURI exists Return
    Match (.*)\?(.*) Rewrite $1&$2 Continue
    Match ^/public/(.*) Rewrite /public/index.php?_url=/$1
}

Its super nice to be able to post a UrlToolkit section that is applicable across all sites without site specific stuff mixed in with it.