Jump to content

gurkendoktor

Members
  • Posts

    61
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by gurkendoktor

  1. are you sure about using the "wegstrich" / "geviertstrich" ( — ) in prices? usually i thought it's the "halbgeviertstrich" / hyphen ( – ) … i'm curious, it's been a while for me since i last had practical application for this knowledge.
  2. ok, whoever uses this and wants to test drive the purging module, here it is: https://github.com/gurkendoktor/processwire_purge_fcgi_cache in branch develop Just install it and you're good to go. I will prepare a README later. Looking forward to feedback or if it makes any sense for anyone except me. Known issues: * You will see errors if the page has not been cached yet * You will see errors if no page at all has been cached * The UI is still a bit of a mess
  3. re:headers this is a very interesting read i came across: http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/
  4. For some reason I didn't get notified about your post, but you're right with the headers. Depending on the rest of your config, you actually might need to add this line. Exactly this cost me 30 minutes today, I just couldn't get it to work on a new installation. Thanks for pointing this out. As with the cookie, the "=" version should, according to the documentation, work - but yours will definitely work better. I personally removed this part, because for my use case it's enough to know whether I'm using the admin area or not. Anyway, I will also update this part. Thanks for you input. The clear cache module is also taking shape (way too slow for my taste, but I only have so much time…), and should be ready for a first test drive soon.
  5. Also worth reading: http://en.wikipedia.org/wiki/SPDY http://en.wikipedia.org/wiki/HTTP/2 This is where we are going, and if not for anything else, at least for performance reasons you should adopt this as early as possible.
  6. i read this yesterday. great initiative. after that, no excuses to not encrypt traffic anymore!
  7. You can make a master / slave configuration with continuous syncing from one to another. For this to work you would have to make sure that admin traffic is only routed to one ("master") server. You could use rsync (which could be triggered by a module after onPageSave), the more "true" way as far as I understood is block level syncing. I don't know anything about this however. Alternatively, you could for example mount one server's /assets/ folder into the other one. This makes sure you always read / write to the same dir. In this case, you should make sure in your application logic that the same information cannot be stored at the same time from different servers. You could also combine these two options.
  8. Yes, it does. I have it run with nginx, so I don't care about the .htaccess Read the instructions on how to get hhvm running here: http://hhvm.com/blog/1817/fastercgi-with-hhvm You might need some tweaking and run into a lot of issues - hhvm has not been tested with ProcessWire. I also chose to let it run at port 8999 to be easily able to switch between hhvm and php5 for reasons of comparison. Your mileage may vary, but with a modern system your chances of getting it to work are better. Some stats using a fresh installation of Processwire with the site-beginner scheme ab -c10 -n500 http://pwtest.gurkendoktor.de/ php5-fpm: Concurrency Level: 10 Time taken for tests: 23.425 seconds Complete requests: 500 Failed requests: 253 (Connect: 0, Receive: 0, Length: 253, Exceptions: 0) Total transferred: 1902241 bytes HTML transferred: 1700241 bytes Requests per second: 21.34 [#/sec] (mean) hhvm: Concurrency Level: 10 Time taken for tests: 8.702 seconds Complete requests: 500 Failed requests: 232 (Connect: 0, Receive: 0, Length: 232, Exceptions: 0) Total transferred: 1900304 bytes HTML transferred: 1700304 bytes Requests per second: 57.46 [#/sec] (mean) This is in no way scientific. PHP does not use an opcode cache, which speeds up things a lot. on the other hand, hhvm gets better the "warmer" it gets (ie. the more load it gets). The nice thing is, that it still works with fcgi_cache: Concurrency Level: 10 Time taken for tests: 5.110 seconds Complete requests: 500 Failed requests: 491 (Connect: 0, Receive: 0, Length: 491, Exceptions: 0) Total transferred: 1912527 bytes HTML transferred: 1699527 bytes Requests per second: 97.85 [#/sec] (mean) Yes, there are some more "failed requests" - I blame this on ab Anyway, this is just plain ol' PHP Code. What would be interesting is to actually write a module in hack (the hhvm language) and see if this actually works. Because then you'll be able to harness hhvm's full power and experience an incredible performance boost. I'll figure this out later when there's time. More interesting it would be to fork the ProcessWire core and move it to hack. This would incredibly boost the performance, but brings other issues. But I guess this is too much of an effort, I myself wouldn't be able to do it
  9. Hi, I don't know if this is the right section for this but I collected some thoughts and a kind of manual about how to increase the performance of your website under load with nginx and fastcgi_cache. At best, this could be a kind of ProCache for nginx users, as not everyone is using Apache and thus not able to use ProCache on their sites. Additionally, this solution comes with the benefit of server side mobile detection and selective caching. http://svn.matthiashaak.com/website-performance-with-processwire-nginx-and-fastcgi_cache/ Please let me know your thoughts or questions about this. Be aware however, that with this solution you end up serving static pages, so no hooks or PHP functions will be called. I am currently working on a module that eases the cache purging, so kindly be patient if you need this. "Wait, and thou shalt receive"
  10. To add some background: the thought behind this is called Responsive Web Design + Server Side Components (http://www.ress.io) The big advantage over "just responsive" is that you don't only have a responsive site, but instead cater to the various environments. For example, you could assume that users with mobile devices almost always operate on a smaller bandwidth with a bigger latency. You might want to deliver only the JavaScript that's needed for the mobile version, not necessarily all the bytes for the full fledged desktop version. Or, to turn it around, auto-load videos on the not-mobile versions, and just have images on the mobile version… you name it. Horst in #12 also has a good use case. This is especially necessary, when you have the – nowadays somewhat old-fashioned – opinion, that web sites should also work without JavaScript. At least the basic functionality. It is a bigger effort though and has some pitfalls, one of which is caching. We don't have issues with that, but you could easily run into trouble. As mentioned before, TemplateCache can only cache whole sites. You could use MarkupCache instead, which is more work again, but should give you the control you need. With ProCache i haven't been working yet, but I assume from what I've read that it's a TemplateCache on steroids. We are currently working on a caching solution somewhat similar to ProCache, which also respects the user's environment and the version they get delivered – for which this module comes in handy again This is yet one of the harder issues.
×
×
  • Create New...