Home  /  RSS  /  RSS Comments  /  Enter

IIS Supports FastCGI? Not really!

IIS officially supports FastCGI and even provides built-in module starting from version 7.0.

Does it mean that you can now develop generic applications that use the industry standard widely supported API and deploy them with IIS?

Not really.

Several things you should know about IIS and FastCGI:

1. It does not support multi-threaded FastCGI applications. That means your generic application would be able to process only a single request per process.

   Even the standard example that comes with the most popular fastcgi library implementation would not work.

   This basically means: you can't implement with IIS/FastCGI long polling techniques, or share some cache between multiple worker threads of the same process.

2. It does not allow you to use external FastCGI applications - something very common in web servers world. All popular web servers: Apache, Lighttpd, Nginx fully support it/

   IIS must manage your application life cycle and does not allow you "to do what you think is good for you".

This basically means only one things: FastCGI support for IIS was designed to run PHP... Nothing more.

One again - Microsoft takes very good generic standard and... succeeds to implement it in the most horrible way.

The lecture slides and the poster from August Penguin 2011 conference.

I had given a lecture at August Penguin conference about Boost.Locale and presented a poster about CppCMS project.

• The slides for the lecture about Boost.Locale:
  • odp
  • pdf
• The poster pdf

When the memory allocation matters

There are many different bottle necks in C++ networking applications, many of them related to the architecture, the way system calls are used, the way application generates the data.

However at certain point applications reach the point when memory allocation becomes the bottle neck, this is especially relevant for the cases where text strings are widely used. And this is usually the case for all networking and web applications that finally need to deal with strings.

The old and good std::string has one limitation - it requires memory allocation for the chunk it represents. This is actually correct for almost any kind of string around whether they reference counted, immutable - all they allocate chunks of memory.

Consider situation, where I need to search against path /foo/bar/123 in some hierarchical structure like std::map that uses std::string as the key. So I need to find a path using after fetching two keys foo and bar from the path.

So basically for the function:

void find_path(std::string const &str);

The call:

find_path("/foo/bar/123");

Would need to:

• Create a string /foo/bar/123
• Create a sub-string foo
• Create a sub-string bar

So I've got three memory allocations and this is not matter whether these strings are mutable or immutable, reference counted or not.

CppCMS should handle such code in multiple places so how it solves this problem?

1. Create a special object cppcms::string_key it holds inside a full std::string but also can be created explicitly from a pair of two char const * pointers that define a text in range [begin,end).

   What is important that in in the second case object does not copy the data but only references it and I'm as a user responsible to ensure that the text range remains valid as long as I use this object.

2. Now we add an overload for the function above:

   void find_path(char const *str);
   void find_path(std::string const &str);
   

   And when we split the text into parts we use only "unowned-strings" such that creation of a strings /foo/bar/123, foo, bar would not require memory allocation at all.

It is a general line, but there are much more interesting tricks to deal with 0 or few allocation strings and streams, like creation of a small memory pools that release all strings in once, like using on stack storage for small text chunks and much more.

This technique is widely deployed in CppCMS 0.99.9 code and had allowed to improve performance of page generation by up to twice in some cases.

Now these tricks should be done careful as they rely on manual memory management so, unless you do something many-many times or you detect some bottle-neck in the application still stick with std::string as it is usually good enough. Memory allocation today is very fast, just don't abuse it.

Version 0.99.9 Released

New Features:

• Clang is support provided, CppCMS was tested against Clang 2.8.

  Now CppCMS supports 5 families of C++ compilers:

  • GCC 3.4.x to 4.6.1
  • Visual Studio 2005 - 2010
  • Clang 2.8
  • Intel 11
  • Sun Studio 5.10

• Significant performance improvements in XSS filtering by rewriting URI validation using a C++ parser rather then using complex regular expression.

  Added support of fully custom validation for HTML attributes using callback functions in the XSS filter.

• Significant performance improvements over multiple places in code by eliminating multiple memory allocations:

  • HTTP, SCGI and FastCGI backends - improved memory allocation for CGI variables.
  • Fetching values from JSON objects using get(...), find(...) APIs is now done with 0 memory allocation.
  • URL mapping is now done with 0 or very low memory allocation.
  • Various filters like escape, urlencode and some others now work with no or few memory allocations.

• Performance improvements in caching by replacing the balanced binary tree by hash table in the primary cache key index.

Breaking Changes:

• json::object had changed from std::map<std::string,value> to std::map<string_key,value>. It should be fully transparent for almost all users.

Bugs:

• Fixed a crash in http::response when writing HTTP headers throws due for example to incorrect file permissions.
• Fixed a bug in booster::regex that prevented some valid patterns to be matched against some regular expressions.
• Fixed a bug that may prevent from booster::regex to work on big endian 64 bit platforms
• Added initial support of Python3 for templates compiler.
• Added a workaround for systems that use python3 by default.

CppCMS 0.99.8 and Boost.Locale 4.0.0 Rleased

New Versions of CppCMS and Boost.Locale were released.

New Features:

• Boost.Locale is updated to the latest version that is going to be merged into Boost svn tree.

  It includes some breaking changes:

  • Redesigned boundary analysis interface:

    Instead of using mapping, token_iterator and break_iterator new classes that provide same functionality introduced:

    segment_index, boundary_point_index and the elements that can be iterated segment and boundary_point.

    See: http://cppcms.sourceforge.net/boost_locale/html/boundary_analysys.html

  • Updated messages interface, now messages use same type of character for key and output message, i.e.

      std::wstring wh = translate(L"hello").str();
      std::string   h = translate( "hello").str();
    

    Instead of

      std::wstring wh = translate("hello").str<wchar_t>();
      std::string   h = translate("hello").str<char>();
    

    It allows to use non-US-ASCII keys transparently.

  • Update date_time interface to be more consistent with Boost.DateTime and Boost.Chrono. Operations are more type safe now.

• Introduced support of SunStudio Compiler on OpenSolaris.

• New nightly tests: Linux Armel and Solaris/SunStudio.

Bug Fixes:

• Fixed bug that virtually disabled gzip compression in CppCMS 0.99.7

• Some compilation and testing fixes for older versions of Mac OS X/Darwin 8.

  Note Darwin 8 is not supported due to bugs in the standard C library, but there should be no problems with newer Mac OS X versions.

• Fixes to support ICU 4.8
• Fixes to support gcc-4.6 and gcc-4.0
• Fixes to support Python 2.3.5

Note to SVN-trunk users

Do not forget to untar the updated cppcms_boost.tar.bz2 file.

Pages

• About This Project
• My Open Source Astronomy Projects

Categories

• Progress
• Storage
• Benchmarks
• Templates
• FastCGI
• Framework
• Cache
• Berkeley DB
• Comet
• Unicode and Localization
• Off Topic