After such hard work to get SSL in a shape that every browser seems to like it, we must continue to broadly test our current 1.0.8 release.

We want to know if we can safely close:
Bug 594
Bug 909

Please, if you have a server running HTTPS, now is the time to switch! Help us, and tell us if this is what you expect from a high performance webserver. Your feedback is strongly appreciated!

HTTPS · SSL

It is the number of evilness and bad karma: 594. For months funny things are happening with SSL. Since I ran a website that did about 40Mbit tops on SSL I was pretty sure nothing was wrong with Cherokee. I mean, how can you do that amount of traffic if something is wrong?

I have blaimed you Ubuntu guys about everything, not upgrading to the latest OpenSSL, etc. Until finally someone pointed me to a way to actually reproduce the error. Yes, I could kill Chromium with bad SSL mojo. To investigate the bug, I wanted to get all the distractions out of the way.

You must understand that debugging is a processes that is pretty straight forward, everything out of the ordinary is evaluated first. A common tool to find memory and thread badness is Valgrind. I have used this to first identify the memory leaks, in order to do so with you must recompile OpenSSL with the CFLAGS: -O0 -ggdb -DPURIFY. Usually memory leaks within Cherokee indicate:

• Alvaro was lazy (no offence)Alvaro had many higher priority tasks to accomplish
• The program flow is tampered with

The first thing can be very annoying, when you are debugging and trying to find stuff that is out of the ordinary, you don’t want to see anything that can distract you, since plugins are only intialised, everything that happens there is in fact never freed until the application finishes. Since everything that attracts with a flood of information will be useless in finding that one specific problem, I started with solving some true memoryleaks: the socket operations. And some minor stuff that trigged a segmentation fault. To overcome all annoying distractions I also finished up the memory allocation of the keys.

Now everything was relatively speaking clean. Still badness happened. Firstly we had ignored the OpenSSL examples regarding to multi-thread operations. Alvaro and I both implemented this code. Now all strange base key operations where solved. One issue remained: the connection was still reset.

The connection reset was transfering the entire document to the client, but prevented the the SSL_shutdown to finish. I ended up in respinning the connection, the first socket_close would shutdown SSL, the second one would close the socket. It seemed this timeframe allowed SSL to do its thing (and not annoy me). Alvaro on the other hand indicated an interesting thought regarding what to do instead, in a clean way so to say.

Currently there is some code committed to the SVN. It doesn’t seem to be the final solution because there are timeouts within ab that weren’t there when I used the ’simple’ respin. I’m hoping we can checkout a simple flush today, and see the issue has gone away…

…for good ;)

SSL

David talks about Cherokee success cases in the European Space Agency, Accenture, etc. [This talk was held in Spanish]

No tags

No tags

No tags

No tags

No tags

Don’t be shy, confess your love!

No tags

While doing my late night browse through the Bugtracker I stumbled upon two bugs of mine. Obviously when I posted those feature requests I was young, innocent and did not what to touch the code at all. But after giving a presentation on the Cherokee Summit, attending the Hackingparty after the Summit, I realised that we all contribute to Cherokee and that it should not be too hard to come up with solutions for bugs yourself. Interestingly, once you actually dive into the code you may even get better feature requests than a the average user.

Today I want to take a look with you all at the encoder_gzip.c. It will bring you straight to the point that I want to make.

gzip_header (10 bytes) + [gzip_encoder_content] +
crc32 (4 bytes) + length (4 bytes)

Now it is probably not to hard to take a peak what the above implies. If we want to use gzip, we are going to waste at least 18 bytes for the encoding step alone, excluding: the extra HTTP header, the encoding cpu time server side, and obviously decoding on the client side. Given this overhead, it might be useful to prevent the content being encoded by the encoder if:

1. It does not exceed the minimum overhead of the encoder
2. If the encoder step will enlarge the request

Lets take a peak at how that could work. Within connection.c we can find the function cherokee_connection_instance_encoder. From there on we see that some documents can never be encoded. Since not all encoding functions have the same overhead, we would like to know, just based on the length if it would be beneficial to pursue this type of encoding. If we would implement a function such as cherokee_encoder_overhead(cuint length); we could overcome our first mistake. This would go for documents shorter than 68 bytes in the gzip scenario, the overhead of gzip (18 bytes) plus the HTTP header overhead (50 bytes). Given the common use of short messages within AJAX, this actually could be useful.

Now step two, we could implement a check within the cherokee_connection_step function. Was the encoding actually beneficial?

/* Was the encoding beneficial?
 */
if (conn->buffer.len < conn->encoder_buffer.len) {
	/* Swap buffers
	 */
	cherokee_buffer_swap_buffers (&conn->buffer,
				      &conn->encoder_buffer);
} else {
	/* Prevent further header output
	 */
	cherokee_encoder_free (conn->encoder);
	conn->encoder = NULL;
}

Now you may say: “obviously this will be the case especially for larger messages”, I’ll gladly dispute that. Since every message has a minimum entropy, there exist encoded messages that plus the overhead will never be smaller than the source message. Imagine a compressed image, lets take PNG, it will use a method to decrease entropy. In the case of PNG it is Deflate. Now do we really expect that our gzip or deflate encoders will do better on lossless binary compression than the actual format itself? Because this problem is more fundamental, we might need a method to a priori exclude certain (known) filetypes from being encoded at all, just because it is stupid even to attempt it.

connection_step · encoders · gzip

The first video of the Cherokee Summit 2010 is on-line now:

Cherokee Summit 2010 – Welcome – Alvaro Lopez Ortega

We are currently working to get the rest of the videos on-line as soon as possible.. so, by tuned!

No tags

Today Michael (binBASH @ irc://irc.freenode.net/#cherokee) told me his parser was ready. It seems to we are falling into the middle of a story, we are. The story about strong winds, development and high performance PHP.

If we look at a typical PHP setup, we get our webserver integrated with PHP as a mod_php solution. Opposed to the Cherokee solution that uses FastCGI. All solutions in this style suffer the same problem: performance. No matter how much accelerators we throw at PHP, it will just never behave like a fast program. For PHP it is not the forking overhead we observe with spawning C programs; but the interpreter phase, the setup of SAPI, the parsing of headers, and what not more. Michael envisioned PHP without the overhead, building a webserver inside PHP that could handle this all. He wrote the webserver, got the t-shirt, …

Interestingly this was the beginning of something bigger. What if you use a PHP program as application server? A single application that runs as separate process, connected as a typical HTTP server. What performance can be achieved using that? Having investigated most options of header parsing, and today polishing the memory leaks away, we ended up with a single instance (blocking i/o) that is currently able to handle 47.000 req/s per core. The cost? Adding a callback function to your MVC-compatible code.

Being in the phase of development and a Pecl extension to PHP, Mistral does suffer from limitations. Multi-Threading issues within PHP prevent a proper balanced backend server, and therefore blocks on each request. A long request such as a search operation blocks all the other requests. But with the use of Cherokee, as proxy and static file handler we can provide much faster access to PHP applications than before. If you want to follow the development progress, our GIT repository might be a startingpoint  http://repo.or.cz/w/mistral.git.

mistral · php

Hello Planet Cherokee!

The Cherokee Community Blog is now subscribed by the Planet Cherokee, as it could not be otherwise. :-)

Please do not hesitate to drop me a line if you’d like your blog to be added to the Planet Cherokee feed.

No tags

The mugshots of the Cherokee Summit 2010 attendees are now available. Too bad we missed some of you guys.

Mugshot

One of the decisions we made during the Cherokee Summit 2010 was to open this blog so the community can get their thoughts out. Here it is!

Blog · Community · Group