Forum

Hi folks

My background's in mod_php so I'm new to the world of fast-cgi.

Please forgive a newbie question, but I can't find anything on the site about opcode caching.

Is there any reason why Hiawatha/php-fpm won't play with APC?

Thanks

Operating System: CentOS 6 64 bit.

I have no experience with APC. But I think that APC has nothing to do with Hiawatha.

Btw, ever taken a look at Hiawatha's caching abilities?

Just a follow-up.

The more I research this the more confusing this issue becomes. If I'm understanding right, a fast-cgi process compiles the app to opcode and then serves around 500 requests before it's renewed. So why the need for opcode caching? But then you read benchmarks for opcode caching with fast-cgi showing 50% performance and memory gains. Some say that all processes can share a cache. Others say that each process requires its own cache. Can't find anyone who explains all this clearly

I realise that this is drifting away from a strict Hiawatha issue, but my real question is this:

"What is the fastest, most memory-efficient, most Slashdot-resistant way to set up Hiawatha and PHP ?"

Any tips would be most welcome!

Sorry Hugo - our posts overlapped.

No, not directly to do with Hiawatha, but more to do with my decision to move to fast-cgi.

The Hiawatha caching, if I understand it, is userland caching for content. Opcode caching caches the compiled PHP code, to cut the disk-read/compile cycle. My apps are complex, with a lot of code being read and compiled each request. In the mod_php model, opcode caching gives me huge gains.

I'm attracted to the lightweight, security driven approach of Hiawatha, but unless I can get my head around this opcode issue and fast-cgi I'm concerned I'll lose performance. And right now I don't have a lot of time to set up a testing scenario and benchmark...

Can anyone help with this? It must be a common issue...

My advice is to ask questions about PHP and opcode caching at the PHP forum. They know best.

About Hiawatha: at least turn on caching and make the internal cache size (default = 10MB) match the total file size of your website(s). Where possible, let the PHP application use Hiawatha's cache feature (via the X-Hiawatha-Cache and X-Hiawatha-Cache-Remove CGI headers) for the static-content pages. This will save a LOT of CPU power.
If you have more machines at your disposal, use one machine as the webserver and the other machines as PHP FastCGI servers. Use Hiawatha's loadbalancing FastCGI support to spread the load.

Thanks Hugo

Glad that you're sticking with Hiawatha development (seems that you had a period when you were discouraged about lack of uptake). My current survey of the options suggests that it still offers a combination of security and efficiency which none of the others can match.

Yes, some time ago I was thinking about closing down the forum or this entire website due to lack of interest in this project. I never planned to stop developing, because I use Hiawatha myself. So does a friend of mine.

Thing that changed is that I now mostly develop Hiawatha for myself and am quite reserved towards feature requests. I gave up the idea that one day Hiawatha will have a significant amount of users.

Hi Hugo

Just installed Hiawatha on Ubuntu Server 12. Pretty painless, though adding some notes on setting up with php-fpm would be good.

I got some good info on php opcode caching and fastcgi from the nginx guys. For the record, the advice was:

1) Yes, opcode caching gives big performance and memory gains with fastcgi & php
2) The most suitable fastcgi manager is php-fpm
3) The most suitable cache is Xcache. APC may have some issues with fastcgi.
4) No need to do any fancy setup for Xcache - just normal tuning
5) Each process group will only need one Xcache - so it's memory efficient.

Hope this helps someone.

As for giving up on popularising Hiawatha, I'm new here so I don't know what's been tried. But my impression would be that the time has never been better for a secure webserver. Just looked at my logs for a little site I run as a sideline, and there were over 300,000 attack requests in the last month alone. And it's only going to get worse... I'm looking for security, security, security, reasonable performance and ease of setup, in that order. I would have thought that would be quite a common perspective.

My background is in marketing, and if I was engaged to try and spread Hiawatha my first impressions would be:

GIVE USERS CONFIDENCE IN THE SERVER

1) Look & feel: you really need to refresh the website - it's looking tired and very "web-1". A cool web-2 logo and site-design would help a lot. Showed the site to a couple of other developers today, and they felt it was a turnoff.

2) Sell it on the front page: you have around 6 seconds to show visitors that Hiawatha is secure, fast and easy to use. Claims backed by testimonials would be what's needed. And a graph from an independent benchmark. There are lot's of good examples of best practice if you look around.

MAKE IT EASY TO USE

1) Official rpms and debs for download from the site
2) Get it included in the main distros, or at least set up a local repo
3) The docs aren't bad, but they could do with a little TLC when it comes to presentation - make them easier to navigate and use.

FIND SOME EVANGELISTS

It's not very visible right now. If you revamped the site, docs and distro, you could try and get some magazine writeups. And how about trying for testimonials from some influentual bloggers. Rasmus, for example, is very committed to light and secure solutions - why not get him on board?

Obviously, a lot of effort. But I'd have though there would be potential business here. Igor seems to be doing pretty well with nginx, with his capital injection and flash new site: http://nginx.com/ .

Probably this is all old news for you, but I thought I'd pass on my 2c worth...

Thanks for your feedback about how I could make Hiawatha more known. Believe me, I've tried hard to do so, but somehow it didn't work out. You might be looking for security, but many people only care about maximum performance. Is another webserver faster? Then you're out.

About the look & feel of this website: I agree that it could be better, but I'm only a software guy who doesn't know much about how to make a good webdesign. And I have no idea who to turn to for a free and good design.

I used to provide official debs, but there is some problem with that. It's impossible for me to provide a deb for every possible Debian release or Debian clone. And to provide only a Debian Stable deb causes problem, because although I stated it was a Debian Stable package, people installed it on a lot of Debian clones and ran into all sorts of unexplainable problems because of that. Compiling it themselves solved the problems in all cases. The only thing left for me to do was to remove the debs and make compilation and installation as easy as possible.

Hiawatha has been in some machazines. This one for example: http://www.linux-magazine.com/Issues/2009/107/Hiawatha. But that didn't do much good for Hiawatha's popularity. Finding evangelists is also not very easy. I've done all I can to make Hiawatha more known. I even did some nasty spamming on forums and blogs whenever there was a dissusion about webservers or website security going on. Nothing helped much.

It's not that I don't want to. It's just that after 10 years of trying, I think it's time to draw a conclusion: the world is not interested in another webserver.

You may well be right. Development is a funny world - the best option is rarely the most popular. Look at MySQL, which in my experience is a steaming pile of odure vs Postgres, which is my experience is a thing of beauty. I'm happy to go with the smart folks rather than going with the crowd.

From my own selfish point of view, I'm happy so long as you keep updating it and keep the site up!

I've just installed the deb from tuxhelp onto Ubuntu Server 12 beta. But from what you say it sounds as though I'd be better to compile?

Anyway, many thanks for keeping Hiawatha available. The community may be small, but I'm sure your work is much appreciated!

The Hiawatha source package has everything onboard to build a Debian package. Just run the extra/make_debian_package. You might first install some required packages, but the script will tell you about it. Unless a package has been build for your OS including the version, building your own is better.

Hugo

This worked painlessly, thanks!

Hugo, I agree entirely with G Caplan, and I've actually pondered offering to come up with a new visual identity for Hiawatha, as well as a website design, as I like the experience of using Hiawatha and your approach, but I wasn't sure if you'd be open to it. Time allowing, I'd love to help if possible. I'm really busy at the moment, but let me know if you'd be open to discussing a redesign and having designs done.

One area that I'm slow at is webserver configuration/maintenance - maybe we could help each other.

Feel free to email me at david - at - doliver . co . uk