Appliance improvements

[Karl]

Hi,

Some suggestions for improving the base appliances:

- VPS. I believe if yum updates a kernel it'll break them. It may be a good idea to ship them with the kernel in the yum excludes list, especially as CentOS ships with the yum updates deamon already enabled.

- Web. Include PHP APC cache as a module, with framework driven sites it can make a huge difference in the number of hits that can be handled and there really shouldn't be any need to branch just for a PHP module.

- Web. Allow PHP modules to be optionally loaded - currently the PHP install is very bloated in size as all modules are loaded - they should be there, but not loaded unless <docs_dir>/.php_ini/*.ini loads them, similar to the Apache config.

[PeterNic]

Karl,

Thanks for the input.


- VPS. I believe if yum updates a kernel it'll break them. It may be a good idea to ship them with the kernel in the yum excludes list, especially as CentOS ships with the yum updates deamon already enabled.

Update: this is not yet fixed; it is a simple thing but has given grief to a few people. We'll fix it, both in the VPS/VDS appliances and in all regular catalog appliances. (SCR number to follow)


- Web. Allow PHP modules to be optionally loaded - currently the PHP install is very bloated in size as all modules are loaded - they should be there, but not loaded unless <docs_dir>/.php_ini/*.ini loads them, similar to the Apache config.

OK. How is this as an approach: : add a property php_modules; values: "all", "none" or list of modules. Default "all" (current behavior). List is comma- or space-separated list of php modules to be loaded.
(AppLogic change request SCR2565). Option: also support negation (modules not to load): all,-apc,-imap


- Web. Include PHP APC cache as a module, with framework driven sites it can make a huge difference in the number of hits that can be handled and there really shouldn't be any need to branch just for a PHP module.

Makes sense (change request SCR2566). Looks like this should be implemented together with the ability to control loading of modules. Should it be loaded by default?

We'll try to put in the two PHP changes the next time we reopen the WEB5/WEB64 appliances. Would it make sense to also do it for WEB4 (with php4)?

Best regards,
-- Peter

[Karl]

Sounds a good way of doing it Peter - although I still think you're going to need to allow users some control over the PHP ini by at least letting them specify an additional ini file to be included - as some of the modules can require a bit of configuring.

APC - I'd not enable it by default, as it can cause grief to people in certain situations, but I think it's deffo needed as I was doing some load testing against a script using a few components of the Zend framework and the performance was bad compared to a simple PHP script - Like 190/s vs. 8/s for a simple phpinfo page vs. a page using Zend Framework (and the page wasn't actually doing any data processing).

TBH, I'd not bother back-porting this to the PHP4 versions, as PHP4 is now EOL.

[spyderdyne]

I have a large LAMP application and would like to add PHP APC, but every time I try to install it my appliances fail to start on application reboot. I am using a modified WEBX5 appliance with webmin and added SSH and HTTPS IN ports. Has anyone found a way to install PHP APC without breaking their appliance? I would even be happy to recompile if necessary...

[PeterNic]

spyderdyne,

How does the appliance fail to boot?

You can access the appliance on failure -- pretty much work the same way as you would with a physical server, if you start the application/appliance with --debug option. This way, AppLogic will leave the appliance running, so you can ssh into it and figure out why it is not starting (I am assuming the most likely reason is that apache fails to start -- being able to log into it will likely allow you to see why and correct it).

Let me know if you have any questions... also, you can take a look at Pavel's post on how to install PHP modules without branching (http://forum.3tera.com/showthread.php?t=471)

Best regards,
-- Peter

[spyderdyne]

I spent about a week and a half try to get this to work and gave up. I have installed SQUID for transparent proxy caching. At least the software doesn't break the app.

[PeterNic]

Spyderdyne,

I sorry this didn't work out for you...

Using SQUID in a separate appliance is a good approach in general, and if it works for you, it is better than combining the caching with the processing; you can scale those separately and independently. (We're also building a SQUID appliance, so if you like to review the preliminary data sheet when it is available and/or the pre-release appliance, let me know.)

With respect to PHP APC - I still don't understand what was causing the problem. We use an absolutely standard build of apache and php -- we're not even rebuilding those, we installed them straight from CentOS's rpms. There is a bit of AppLogic specifics during the installation (you need to branch the appliance and make the usr volume read-write before the install; after testing, make it read-only again before moving the appliance into the catalog) -- but you're already up to speed on it. If you still want to get to the bottom of this, I will be happy to get one of our engineers to help -- we have folks that cover pretty much all time zones. We also have enough self-help tools (like the boot console, --debug option, etc.) to be able to work this out.

Best regards,
-- Peter

[Karl]

Rather than Squid I'd actually suggest Varnish - so far it's looking like it blows Squid out of the water :)

[PeterNic]

Karl,

Thanks -- we're have also looke at Varnish. I am not yet sure that it is better in all cases -- really comparing in-memory and on-disk caching are separate modes. Varnish's architecture definitely makes sense and there is a wonderful architecture document that compares the two.

I think we'll do the SQUID one first because more people are familiar with it; we'll probably follow up with a Varnish appliance after that.

Were you able to compare them side-by-side (and if yes, in which mode -- mostly in memory or mostly on disk)? How much configuration/tweaking do you have to do to make it work for your app?

Thanks,

-- Peter