This is a log visualization I put together using Logstalgia (aka ApachePong). The lame ‘attack’ on the file ’28-tecoar-long.pdf’ has since been mitigated.
I have been communicating with Mr. Khalil on all sorts of topics regarding Pancake – he is the author of this software. In my discussions with him I raised concerns about security and how Pancake would handle traffic, among other issues.
These issues was promptly answered and he included the Pancake development roadmap, which might be of interest. Personally, I must say, this is one project I’m definitively going to keep an eye on. I think Pancake has great potential to become something big in the future.
On my development system it has been running flawlessly, but it still needs more evaluation. In any case, it works great so far — straight out of the box
I will only attach one reply here. In this reply Mr. Khalil briefly explains the roadmap, security and more.
Concerning your questions it might be interesting for you to know my current Pancake development roadmap. Pancake 1.3 will mainly feature some performance improvements as I am currently porting parts of Pancake from PHP to C. So far, the HTTP request parsing is more than twice as fast as in Pancake 1.2. 1.3 will probably also include support for php:// streams in the PHP SAPI, some additional improvements on rewrite rules and some small bugfixes. I’d not recommend using the master branch as I’ll soon push the first commits with the new classes in C, which might be a bit unstable at the beginning.
Pancake 1.4 will finally introduce support for HTTPS and maybe some more parts of Pancake ported to C.
1.5 will be quite a big release. I am planning on creating a web interface for Pancake that will show extensive statistics about requests including PHP profiling and debugging features, automatic CodeCache configuration and runtime configuration changes with nearly zero downtime.
At some point of time I also want to introduce some other performance improvements, especially concerning PHP. I had the ideas of creating an in-memory PHP session storage handler and offering some threading features to PHP web applications along with some more improvements.
As you can see, future versions of Pancake will offer great new features and improvements. I believe that Pancake 1.2 should easily be able to handle [DELETION] visitors per day, 1.3 even better.
Concerning security, I’ve conducted many tests with Pancake, testing several possible vulnerabilities. I believe that Pancake is safe against most forms of attacks like Slowloris for example. I just currently would not use Pancake for public hosting services as it is possible to block the RequestWorkers using manipulated PHP scripts. However, I am planning on changing the way the workers communicate with each other so that this exploit won’t be possible anymore in a future version of Pancake.
In case you have further questions, don’t hesitate to contact me again. I’d really like to see what you do with Pancake in the future.
If you’re interested and wish to learn more about the Pancake project please have a look here:
I have Pancake (see note #1) running successfully on “puff” now with WordPress, all working fine. So my next step is completing various comparisons between k0nsl-nginx, Apache and lighttpd so make a decision on my purposed usage of Pancake, to see if it’s viable. But these comparisons will be done in the coming days as I have something else to fix before that.
By the way, a new release of Pancake is available as of today, 1.2.4 (stable, see #note 2).
For those not knowing how to get the permalink / search engine friendly URLs working correctly on Pancake, please see below.
First of all, set permalinks to “/%postname%/” in WordPress. Now set the following rewrite rule in Pancake:
rewrite: - precondition: 404 pathinfo: ~()(/.+)$~
In case you have set “/index.php/%postname%/” this setting should work:
rewrite: - pathinfo: ~^(.+.php)(/.+)$~
That should take care of the issue. Enjoy your pancake
There are many good ways to craft a “Httpd Load Balancing” system. One of the most common is by using some sort of proxying service and a monitor in between which sends out pings (or so-called “heartbeats”) to a node of servers. To my knowledge that really is the most common one, even by “industry standards”. I am currently experimenting with this for a client so I am testing it on my blog.
I got it working really nice so far. I don’t wish to reveal the entire set up right now because I am somewhat tired, but it’s basically as I said in the first paragraph: a proxy service, monitor and the node. So simple, yet so useful.
If you’re new to load balancing then it takes a bit of reading to get a general understanding. Google is your friend for this kind of stuff.
My balancer switches between either my main / base set up, which is k0nsl-nginx+Apache2 or a Hiawatha webserver configuration that has some minor tweaks so far.
You can do some interesting stuff using PHP too if you don’t want to set up a load balancing between nodes. For example, write code using PHP (or whatever is your preference) that either switches between one webserver or another based on whatever input you chose or desire for a particular application.
One easy example is to switch between webservers based on URL/DOMAIN parameters, such as this very simple example:
Now granted, I have not tried the above code nor do I know if that implementation would be wise. Probably not. You’d need to code an entire skeleton for something like this to work optimally, I believe. However, the idea is albeit valid and load balancing between different servers or even different daemons for WordPress specifically in the simple example above is entirely possible. If somebody has a better idea than the example given in the screenshot above, give me a comment on it.
You can find out if your VPS is overselling the memory with utilities such as this one:
Or this Ruby one:
They more or less work the same, all of them. The C code is probably best with regard to memory utilization though.
For more comphrensiv reading with details, see:
G’day folks (with Australian accent),
On my development server I’m today testing Cherokee. I am evaluating whether or not to deploy this on one of my servers. According to the few benchmarks I’ve seen this one holds up quite well. In fact, it’s performing really well. However I am going to test it throughout the evening to get a better understanding of the internals.
The admin interface — cherokee-admin — is well-done.
Click on the screenshot for better resolution.
I may have reason to get back to this subject depending on what the outcome will be from evaluating this software.
Right off the bat I can say that it works fine, but you have to actually edit server.py (located in: /usr/share/cherokee/) to be able to install “apps” (such as project trackers, blogs and more), therefore, change the following line:
CTK.init (host=”localhost”, port=int(scgi_port), sec_cookie=True, sec_submit=True)
CTK.init (host=”localhost”, port=int(scgi_port), sec_cookie=True, sec_submit=False)
That’s the only issue I’ve encountered so far with Cherokee. I may report more later, either as update to this post, or a completely new one might be crafted. Probably the former.
kr0kedNET (formerly “neophytos IRC”) has been launched. Two hours or so ago. kr0kedNET is a free-for-all IRC network, without any of the typical rules one sees everywhere. There only is one rule, the unwritten one; no paedophilia-related discussions, channels or content of any kind.
So in any case, feel free to become a frequent user of kr0kedNET