Databases Reference
In-Depth Information
COUNT(*)
----------
10
Now, after switching into MPM mode using the settings described above, let's look at the Apache
processes again:
[ohs@ae1 conf]$ ps -u ohs | grep httpd
18686 ? 00:00:00 httpd.worker
18687 ? 00:00:00 httpd.worker
18690 ? 00:00:00 httpd.worker
18691 ? 00:00:00 httpd.worker
The
httpd.worker
in the output confirms we're running in MPM mode. We should also notice fewer
database connections (since the true connection pooling is in force):
SQL> select count(*) from v$session where osuser = 'ohs';
COUNT(*)
----------
4
Obviously, the number of connections will fluctuate depending on system load—the connection
pool should adapt and create more connections as needed and free them when no longer needed.
However, the key thing to bear in mind here is the difference between the two methods. Generally, the
benefits of running in MPM mode can have an influence on the performance and responsiveness of your
application when supporting a larger number of users, not to mention the reduced overhead on the
database in terms of having to maintain fewer database sessions.
It's worth noting, as Joel mentions in his blog post, that on Windows, the OHS has always been
multi-threaded, so this setting is only of interest to people running the OHS on Unix servers (which
seems to be the majority of people that I speak to).
Web Server Compression
One of the other really cool features available with the OHS is the ability to have it compress the web
server response before sending it to the browser. This has a couple of big advantages:
•
The size of the content that needs to be returned is smaller, therefore taking less
bandwidth and less time
•
Since the content is returned faster, the Apache web server process is freed up
faster and is therefore able to process another user's request more quickly.
Web server compression is pretty much what it sounds like: the web server will compress the
content in the same way you would run WinZip (or another compression application) to reduce the size
of a file. The amount the file can be compressed is really a factor of the type of file it is. Files such as
JavaScript files, CSS files, and HTML files, which are all text, are highly compressible, while images are
typically not as compressible (particularly JPEG images, which are already in an optimized format). So
usually you would configure web server compression to only compress things that you know are highly
compressible—otherwise the payoff is not worth the overhead of compressing it.
Now, before we dive into how you configure web server compression, I want to show you a couple of
tools I use when looking at my APEX applications to evaluate how they can be optimized. As I described
