Category: "LAMP"

just_a_test, just_another_list ...

Reduce your 'net print

Bandwidth reduction will soon be a priority. The proliferation of RIAs exponentially increases the bandwidth requirements of initial page loads, while potentially reducing that of subsequent requests.

  • Use public CDNs - both to access and distribute libraries. Public CDNs are built for this purpose and often compres content. If you have your own CDN, use it.
  • Use and allow the use of logo images from their original sources. For example, the logo for your product could be displayed, from your server, on many sites. This allows headers to be set for browser caching, such that subsequent requests for the images will be served from the client, not the server.
  • Use compression where appropriate. Optimize images and ensure text is text, not images.
  • Examine your file and page architecture. Strive to deliver only that content required for each page.
  • Check the stats to find where the bandwidth is being used and focus on improving page performance for those pages. Use http://websiteoptimization.com
  • Use AJAX.
  • Develop locally, use XAMPP or VMWare.

RPM vs. tar for distribution for open source web applications

RPM advantages

  • Installation always puts it in the same location
  • Single copy of the source on the server, saves disk space
  • Potentially more secure, since permissions can be set to read-only
  • RPM can serve as an installation wizard, rather than writing one
  • RPM can also uninstall
  • Dependencies managed by RPM
  • Upgrades can be managed by RPM
  • Fits nicely into larger architecture
  • Can cross directories to handle configuration at different levels, for example, add an Apache .conf file.
  • Allows custom default configuration to be installed easily

RPM disadvantages

  • Single copy means application shouldn’t be customized once installed, all accounts will have to run the same
  • Single copy also means there may be additional filesystem architecture adaptations, for example a compiled template directory normally placed under the application would have to be accommodated. Application may have to be modified
  • May require root access
  • Filesystem architecture should be known
  • Requires installer to have some knowledge of RPM, usually more complex than tar
  • Requires installer to understand more filesystem commands (how to link into installed application, rather than install it
  • If application is normally distributed as a tar/gz file, RPM will be outside the documentation
  • Creating RPMs is far more complex than creating tars. Learning curve.
  • Development team and environment. If everyone is working on a single server, it may be difficult for them to share a single copy of an application. Consider VMWare.

Deciding Factors

  • Installation type - single application on the server, or multiple. Single is best with RPM, multiple is probably better with tar
  • Application source - custom applications may be better with RPM, outside/open source applications are probably better with tar
  • Dependencies and type - RPM really does a nice job with dependencies
  • Upgrades - RPM allows yum/up2date management of upgrades, with dependency observation
  • Skill/experience/education level of team
  • Servers in use - tar may be slightly more portable
  • Flexibility of target system
  • Updates during development are very easy to apply with RPMs

dojo - ContentPanes - compression

To compress the content delivered to a dojo ContentPane, you can compress the content and cache it with the Zlib functions of PHP, then open it with the filesystem functions and deliver it with the Content-Type header set to “text/html” (or other appropriate setting), and Content-Encoding set to “gzip“.

The compress and cache should be performed if the file is likely to be reused. If reuse is unlikely, or the file is relatively small, use gzencode or gzdeflate.

This should work with other libraries as well.

Application Upgrades - an excellent business opportunity

The web is constantly changing and keeping applications on servers which can support them may be difficult, as hosting companies upgrade the servers to improve security, the applications may fail.

Most web companies are extremely careful and use strategies such as running PHP 5 through php5 extenstions, and leaving PHP 4 as the default, but there does come a time when the server has be upgraded. In addition, it is the responsibility of the application installer to ensure the application is maintained for security and performance.

This creates an excellent business opportunity for web companies, especially for powerful applications with complex hosting requirements, such as eZ publish. The key is careful identification and management of the opportunities.

Once identified, one must look at the site to try to assess the quality of work. Upgrades can be difficult, so the offer to upgrade an eZ installation should be made carefully - so all parties understand the risks and estimated costs.

Bear in mind if the application is running from a subdirectory, this strategy may not work. That’s okay, there are lots of other sites. :)

This approach will work for any application that provides identification information in a publicly accessible area (either the headers or the HTML). It is especially valuable for applications with steep learning curves.

Use curl or wget to get the site headers or HTML.