Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by gurkendoktor

  1. Thank you for the input and I know, that "Hamburger Menu" is an anti pattern. However, it was an active decision. I will explain why. First, I'm expecting more traffic from mobile than from desktop devices. It's about 2/3 to 1/3 at the moment. Considering the traffic sources and the market we're operating in, this is probably not going to change. Second: it looks ugly. I played around with a couple of options beforehand and considered various design approaches. Always when I came to the desktop part, I didn't want the menu there. I could just not figure a way to make it look right. Right as in: I am convinced. Maybe I can't design menus. This assumption is therefore right If we had more traffic, we could do some A/B-testing and see what performs better. But this is not the intention as of yet. Performance-driven (as in: maximum conversion rate) sites look different, and this is not one of them. I'd rather set up various campaigns with dedicated landing pages living outside this website.
  2. Haha, I was so excited I actually forgot this. Thanks @justb3a for updating – and for finding the strange title.
  3. Finally, our site is live. It's a quite small, straightforward site with not much use for a CMS as of yet. However, as we will grow we might need easy ways to easily add or exchange content. Comments welcome. If you see anything strange, please let me know. I didn't optimize the hell out of it, but a 98/100/97 in PageSpeed is not too bad. Oh, I didn't use any front end framework or npm module. I thought this might be a little too much overhead for a site like this. I still need to minify my stuff, and there is room for optimization - but I really tried to keep my CSS lean. Don't look at the selectors though Modules used: * MarkupSEO * ProcessHannaCode * WireMailSMTP * SimpleContactForm * MarkupSitemapXML * TextformatterVideoEmbed On the technical side, this site runs on a small DigitalOcean VPS (1 CPU, 1GB RAM) with nginx and PHP 7. This is the first site I made that uses HTTP/2. And here it is: https://studio8.productions
  4. A comprehensible tutorial also covering Apache is here: https://www.digitalocean.com/community/tutorials/how-to-upgrade-to-php-7-on-ubuntu-14-04 (Basically it's all the documentation and the output of the CLI tools compiled and put in a human readable format )
  5. Well, now I come back with something PHP 7 related. So if you upgrade your server to PHP7 and you happen to have PHP run as php-fpm, then DO NOT FORGET to install php7.0-mysql. I was scratching my head for almost half an hour where this strange 500 error stems from. Everything was working fine (info.php, some tests, another website), until I figured that the difference between "the other site" and my PW site was the database. Just a heads up, keep it in mind when you run into an error
  6. I have a small request: form data should be stored regardless whether a mail has been sent or not. Just in case, someone forgets to install sendmail on their DigitalOcean server (or, on a more serious note, a component in the notification chain is failing)
  7. No problem, I followed exactly the steps on their website. $ git clone https://github.com/letsencrypt/letsencrypt $ cd letsencrypt $ ./letsencrypt-auto --help and then ./letsencrypt-auto certonly --webroot -w /var/www/example -d example.com This generates a .pem-File with the full certificate chain ("ssl_certificate") and a private key ("ssl_certificate_key"), both of which you enter in your nginx config – restart nginx and there you go
  8. i installed it on my DigitalOcean VPS and run it in --certonly mode (as I run nginx). Worked like a charm, instantly.
  9. I personally use docker solely for local development, but in the way it is intended (i.e. 3 containers per project). For my own webhosting, I don't use it yet. We had a live docker env in the company however, as a first "live test" of deployment and operations. It's also running behind nginx. However, the SSL offloading with the easy letsencrypt cert generation is one main reason to at least keep a keen eye on Caddy. I think I might migrate one of my VPS to this one just proxying. Let's see.
  10. Why you want a second Docker container? Or do you mean the Docker container that is to be proxied is generating the Caddyfile? Well I thought of putting together a Docker container / Dockerfile for Processwire, why not also make one with Caddy? Only issue is that my Docker skills are rather on the user side
  11. Yes, or to work with designers and give them an easy way to start the project. Or as a replacement for MAMP / XAMP / whatever. For everyone who needs a local dev server and doesn't want to bother with Docker or Vagrant
  12. i see myself in your rewrite { } section
  13. For a general comparison of the performance of both PHP7 and HHVM, I suggest this site. In general, you should have plenty of memory to run HHVM. Here is a tutorial how to install HHVM.
  14. As I already said in this thread, I have Processwire running with PHP7 and also HHVM. So this thread is dedicated to all the question and experiences people run into when trying to get ProcessWire work with HHVM. I will start with a small tutorial, so you can try it yourself and make your own mistakes instead of repeating mine I highly recommend running HHVM on a production system only if you know what you're doing.
  15. I couldn't believe my own numbers, so I checked again. Turns out, HHVM still had caching enabled – my bad. It's still faster, but these numbers are not real. It's rather 1.5x faster. I have to get a bigger server to see how it scales out on multiple CPUs and when it's hitting limits. I will not longer reply on this thread, as it is about PHP7. I made a new one.
  16. Yes, but HHVM is also a JIT compiler to PHP like V8 for JavaScript. Yes, in fact it does. I'll make a tutorial the next days.
  17. Well, according to my short tests with very unscientific methods, HHVM still overtakes PHP, runs to the finish line and back to start just to overtake PHP again. With a normal ab -c20 -n500, HHVM is approximately 24 times faster than PHP 7, under higher load (-c100) this scales up to 60 times. Then the saturation is reached for this small server I'm testing this against. Of course, both are tested out of the box and with a PHP opcode cache you could actually gain more performance. EDIT: Caching was still on, the numbers are wrong. The server was delivering static pages. However, this is a good demonstration of fcgi_cache. However, PHP7 is still super fast compared to 5.4 or 5.5 – and probably has less side effects in large production environment. Or at least they are documented. Let's say it like this: if you have moderate traffic on your site and your application is decently written, you will probably won't note much of a difference. And if you have high traffic, you might face other bottlenecks than PHP, especially if you work with highly dynamic content.
  18. Yes, this is the basic setup. With this, it's running. Of course you can define rules and everything, like in nginx. To be honest, I'm not even sure if I would want this server to be in a production environment. I just like playing around with things, and I like how straightforward and simple this is
  19. OK, got it. rewrite { regexp .* ext / to /index.php?it={path}&{query}&{args}#{frag} } Admin area is working!!! Still no uploads possible, but this might also have another reason.
  20. I read about this new HTTP/2 webserver, Caddy. It's written in Go and it is really super lightweight, the binary is just 3 MB. And the best thing is, that it's super easy to use. You just put the binary in the path of your website and start caddy – and already you have an HTTP/2 server running that serves static files (and who doesn't want, as HTTP/2 is The Future™). And the best thing is: no PITA with certificates and all these thing, as Caddy has letsencrypt already built in. So as you start it, the certs get generated and your site is automatically running on an encrypted connection (which is by the way required for HTTP/2). The best part is however, that you can connect any backend to Caddy, for example php-fpm. This comes even with a "recipe", so you usually don't need to worry about configuration this. So I cobbled something together to have Processwire running with this server, and guess what: it works. Almost. The site is running, but the admin area is still behaving a little bit weird. I cannot edit pages (instead I get the "bookmarks" page) and all the behaviour of the admin area is a bit strange. The other option is that I get "Unrecognized path" I believe this is still a problem with rewriting which I can't figure. This is my Caddyfile: mydomain.com { root /var/www/mypath fastcgi / unix:/run/php/php7.0-fpm.sock php rewrite { regexp .* ext / to /index.php?it={dir}&{args}#{frag} } } I go crazy with the rewriting. Here is the documentation, maybe someone has an idea. Thanks and maybe you have a reason now to try Caddy yourself.
  21. Hey, sorry for the long break here and on the module. I just moved to another country on another continent, and after 4 weeks I moved again in this city I'm living in now, so there were some tideous tasks that required more effort than I thought. I just picked up developing things and writing about stuff again, and will share any improvements on this module here. However, many things haved changed in processwire itself since then, so I have to first read some docs to keep up with all of the things happening.
  22. Just tried it on a rather old test installation (default profile) and it worked like a charm. This Thing Is Flying! HipHop VM (HHVM) I tried before, it's also quite fast but I'm not sure about the coverage in more complex systems.
  23. not yet, as i said: "it's on my list". but i reckon if you put varnish in front of processwire and configure it properly, you will achieve a performance gain. how much, that depends on the amount and structure of your traffic.
  24. i wrote something about it here: https://processwire.com/talk/topic/8161-website-performance-with-processwire-nginx-and-fastcgi-cache/ as other people said before: it always depends on the audience, the type of traffic and the architecture of your site. Sticking to the thread title, caching with fastcgi_cache or ProCache is not really the right way for a "highly dynamic site". Varnish is still on my list, especially because of the Edge Side Includes. What I think might also be a nice way to gain performance in terms of caching would be the use of memcached together with MarkupCache. That would – done right – probably give a nice speed boost. Depending on your hosting environment you could also try Facebooks HHVM as a backend. This is a JIT-Compiler for PHP and works way more efficient than just opcode caching (although APC would already boost things up). Disadvantage is that it needs some time to "get warm", so if you only have one visitor in a while, it might not be the right thing for you. Still: when you use Apache and have a high(er) traffic site, try ProCache first. It's only fair, as Ryan will profit from that and he deserves it It's not worth to completely switch infrastructure just to save a few bucks.
  • Create New...