I recently had to compile from source the Percona blend of mysql 5.4 and ran into a few hiccups that I don’t normally see when doing a vanilla mysql install. In particular I ran into the same issue described here and here.
"/bin/bash ../ylwrap sql_yacc.yy y.tab.c sql_yacc.cc y.tab.h sql_yacc.h y.output sql_yacc.output -- -d --verbose
../ylwrap: line 111: -d: command not found
make[1]: *** [sql_yacc.cc] Error 1"
Apparently having nothing to do with percona but with mysql and yacc not finding bison and possibly flex. So I installed both of those via APT and ran a make clean, make, make install and still same error. Then I realized that the configure script is probably what sets the make switches for using bison so I re-ran
CC="gcc -static-libgcc" CFLAGS="-O3 -pipe -m64 -fPIC -fomit-frame-pointer" CXX="gcc -static-libgcc" CXXFLAGS="-O3 -pipe -m64 -fPIC -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" sudo ./configure -prefix=/opt/xtradb -enable-local-infile -enable-thread-safe-client -enable-assembler -with-client-ldflags=-all-static -with-mysqld-ldflags=-all-static -with-unix-socket-path=/opt/xtradb/tmp/mysql.sock -with-plugins=partition,archive,blackhole,csv,federated,heap,ibmdb2i,innobase,innodb_plugin,myisam,myisammrg -with-big-tables -without-debug -with-tcp-port=3306 -with-readline -enable-profiling -disable-shared -enable-static -with-extra-charsets=complex -with-pic -with-fast-mutexes -with-zlib-dir=bundled -with-ssl
and then another
make
make install
And it worked successfully.
Hope this helps!
PS. If you want the full list of libraries that I needed to install in order to compile correctly:
apt-get install gcc build-essential automake ncurses libncurses5-dev libtool termcap bison flex
Update: since I was using the stock ubuntu 10.04 server install apparmor was installed and keeping mysql from correctly installing it’s databases in a non-standard directory. I kept getting this error:
/opt/xtradb/bin/mysql_install_db --user=mysql --ldata=/opt/xtradb/data
Installing MySQL system tables...
100802 10:26:54 [Warning] Can't create test file /opt/xtradb/data/ubuntu.lower-test
So just had to run a
apt-get purge apparmor
restart and then run
/opt/xtradb/bin/mysql_install_db --user=mysql --ldata=/opt/xtradb/data
and finally I could start mysql
/opt/xtradb/bin/mysqld_safe --defaults-file=/opt/xtradb/conf/my.cnf --user=mysql --basedir=/opt/xtradb --datadir=/opt/xtradb/data --log-error=/var/log/xtradb/mysql.err &
Had to talk through another php mod_fcgid setup today. It is amazing to me how difficult it is to find clear information on this setup out there on the internet.
If any of the below are wrong please tell me. I am not always right but I have studied this setup quite a bit and have come across many permutations and the below finally make sense.
Assumptions:
The most MEMORY efficient way to use php with apache is via the WORKER MPM with a fastcgi plugin forking PHP-CGI processes. I specify MEMORY here because I am pretty sure that CPU wise mod_php is still faster. I can only assume that is because all of the data structures etc that are used within php are within direct access of the apache processes servicing the request. Faster still is probably compiling mod_php directly into apache rather than using the shared module.
The most MEMORY efficient way of using PHP-CGI is to use as FEW parent processes as possible if not 0 and use as many child processes as possible under those parent processes. This is especially true when using an opcode cache like APC. There is a known bug with the mod_FCGID that causes it to be unable to share memory between FCGI processes. mod_FASTCGI on the otherhand does not have this bug. Why not use mod_FASTCGI module instead? Because unfortunately it is a dead project (nothing since 2003): http://freshmeat.net/projects/mod_fastcgi/
Thus APC is not very effective when using mod_fcgid. It just can’t share its memory across subsequent requests to the same php code if those requests get routed to seperate php-cgi processes. See here:
“PHP child process management (PHP_FCGI_CHILDREN) should always be disabled with mod_fcgid, which will only route one request at a time to application processes it has spawned; thus, any child processes created by PHP will not be used effectively. (Additionally, the PHP child processes may not be terminated properly.) By default, and with the environment variable setting PHP_FCGI_CHILDREN=0, PHP child process management is disabled.
The popular APC opcode cache for PHP cannot share a cache between PHP FastCGI processes unless PHP manages the child processes. Thus, the effectiveness of the cache is limited with mod_fcgid; concurrent PHP requests will use different opcode caches.”
Anyway I used the following config on a relatively low traffic 4gb virtual instance with a VERY memory intensive PHP app.
In apache httpd.conf:
<IfModule mod_fcgid.c>
AddHandler fcgid-script .fcgi
</IfModule>
## Sane place to put sockets and shared memory file
#FcgidIPCDir run/mod_fcgid #to use sockets on unix or pipes on windows
#FcgidProcessTableFile run/mod_fcgid/fcgid_shm #to use shared memory on unix
<IfModule mod_fcgid.c>
## FcgidInitialEnv PHPRC "/etc" # is also set in the wrapper script per virtual host. both ways will send the variables on to the cgi instances
##the following MaxRequestsPerProcess is also set in the wrapper script. both ways will send the variables on to the cgi instances
FcgidInitialEnv PHPRC=/etc/php5/cgi #working directory of php-cgi
#"By default, PHP FastCGI processes exit after handling 500 requests, and they may exit after this module has already connected to the application and sent the next request. When that occurs, an error will be logged and 500 Internal Server Error will be returned to the client. This PHP behavior can be disabled by setting PHP_FCGI_MAX_REQUESTS to 0, but that can be a problem if the PHP application leaks resources. Alternatively, PHP_FCGI_MAX_REQUESTS can be set to a much higher value than the default to reduce the frequency of this problem. FcgidMaxRequestsPerProcess can be set to a value less than or equal to PHP_FCGI_MAX_REQUESTS to resolve the problem."
FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 5000 #same as below just as environment variable. sometimes good to set as well. due dilligence
FcgidMaxRequestsPerProcess 5000 #restarts child after so many requests to take care of memory leaks. needs to equal or be less than the PHP_FCGI_MAX_REQUEST variable sent to the cgi process
FcgidIdleTimeout 300 #allows process to sit for 5 mins while idle
FcgidIdleScanInterval 120 #how often fcgid parent polls children who are idle
FcgidBusyTimeout 3000 #allows php to spin for 50 mins before throwing 500 error
FcgidBusyScanInterval 120 #how often fcgid parent polls children who are busy
FcgidErrorScanInterval 60 #how often fcgid parent polls children for errors
FcgidZombieScanInterval 60 #how often to scan for zombie processes
FcgidProcessLifeTime 7200 #max time a child is alive by default
FcgidMaxProcesses 15 #max children PER PARENT PROCESS (remember this is not max TOTAL)
FcgidMaxProcessesPerClass 15 #Max fcgi processes
FcgidMaxProcessesPerClass 15 #Min to leave lying around
FcgidIPCConnectTimeout 3600 #Max time to wait for first "packet" on port or socket from child process
FcgidIPCCommTimeout 3600 #Max time to wait since the last "packet" on port or socket from child process
FcgidOutputBufferSize 128 #comm buffer between mod_fcgid and the cgi process. flushed to client after full.
</IfModule>
In vhost definition:
<VirtualHost *:80>
<IfModule mod_fcgid.c>
SuexecUserGroup some_unprivileged_user_with_rights_to_webroot some_unprivileged_group_with_rights_to_webroot #often these are www or apache user and group
FcgidFixPathinfo 1 #"This directive enables special SCRIPT_NAME processing which allows PHP to provide additional path information. The setting of FcgidFixPathinfoshould mirror the cgi.fix_pathinfo setting in php.ini."
<Directory "/var/www/html">
Options +ExecCGI
AllowOverride All
AddHandler fcgid-script .php
FcgidWrapper /var/www/php-fcgi-scripts/php-fcgi-starter .php #location of your suexeced bash script
Order allow,deny
Allow from all
</Directory>
</IfModule>
</VirtualHost>
Inside the suexec starter script /var/www/php-fcgi-scripts/php-fcgi-starter
#!/bin/sh
PHPRC=/etc/php5/cgi/ #again the php-cgi working directory
export PHPRC #also set in the httpd.conf. I think this just stomps the one set in the httpd.conf.
#"By default, PHP FastCGI processes exit after handling 500 requests, and they may exit after this module has already connected to the application and sent the next request. When that occurs, an error will be logged and 500 Internal Server Error will be returned to the client. This PHP behavior can be disabled by setting PHP_FCGI_MAX_REQUESTS to 0, but that can be a problem if the PHP application leaks resources. Alternatively, PHP_FCGI_MAX_REQUESTS can be set to a much higher value than the default to reduce the frequency of this problem. FcgidMaxRequestsPerProcess can be set to a value less than or equal to PHP_FCGI_MAX_REQUESTS to resolve the problem."
export PHP_FCGI_MAX_REQUESTS=5000 #again setting the max number of requests per child process. Again also in httpd.conf so I think these are redundant.
#"PHP child process management (PHP_FCGI_CHILDREN) should always be disabled with mod_fcgid, which will only route one request at a time to application processes it has spawned; thus, any child processes created by PHP will not be used effectively. (Additionally, the PHP child processes may not be terminated properly.) By default, and with the environment variable setting PHP_FCGI_CHILDREN=0, PHP child process management is disabled. The popular APC opcode cache for PHP cannot share a cache between PHP FastCGI processes unless PHP manages the child processes. Thus, the effectiveness of the cache is limited with mod_fcgid; concurrent PHP requests will use different opcode caches."
export PHP_FCGI_CHILDREN=0 #THIS IS WHERE YOU SET THE NUMBER OF PARENT PROCESSES These will each spawn 15 children in this example. If set to 0 then you will have 1 parent with 15 children and apache will handle spawning the children not php.
exec /usr/bin/php-cgi #the php-cgi binary
References:
http://www.linode.com/forums/viewtopic.php?t=2982&postdays=0&postorder=asc&start=15
http://www.magentocommerce.com/boards/viewthread/29264/
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
http://2bits.com/articles/apache-fcgid-acceptable-performance-and-better-resource-utilization.html
When using a varnish/squid/nginx or any reverse proxy +cache / http accelerator on top of a modern web framework / web application that has it’s own caching layer you may run into some strange seemingly uncontrollable TTL’s on your content. I have come to rely heavily on varnish in the last year and squid before that. If your reverse proxy is setup defensively (and in my opinion it should be) then you probably tend to ignore somewhat the http headers coming out of the application layer and put an additional TTL on top of all of the (non-dynamic) content. A for instance: There is a certain editorial site that I maintain that I cache everything on the site in varnish for 30 mins… period. This means that once an editor pushes a publish button and the content is picked up into the cache it won’t change for a half an hour. OR WILL IT? Turns out that since the application layer also has a cache lifetime of something like 5 mins the object in varnish may or may not refresh for an hour or more. How? Well that’s where it gets difficult to explain. It all depends on when the change get’s published to the content with respect to the application servers cache expiry on the object AND varnish’s cache expiry on the object AND the time of the next request for the object after Varnish’s cache expiry has happened. HAH! Before we go any further a picture is needed.
As you can see from the graph there are two sawtooth looking lines representing the two types of cache’s in use on this site. I have made the assumption that an editor publishes a change to an object (say a homepage of a site) every half hour. Really they may publish 25 times within that half hour but let’s just keep it simple. So in the best case example an editor publishes a change. That publish event happens RIGHT BEFORE the cache in varnish AND the cache in the application server is invalidated for that object and the user request comes in RIGHT AFTER the cache is invalidated in both places so that the user request flows all the way upstream to the application server which re-renders the page with the new content, caches it and then sends it back up to varnish which also caches it and then sends it to the client. That is the BEST POSSIBLE case. That RARELY happens. What normally happens is that a user request comes in, hit’s the varnish cache and is served a moderately old object. I say moderate because more than likely on average the object is somewhere near the middle of it’s TTL. IF the varnish TTL has expired on an object what is next most likely is that the APP server is somewhere within the middle of the TTL for the object within IT’S cache and the app server will just serve the cached response and then varnish will do what it knows best and CACHE THE OBJECT FOR ANOTHER CACHE CYLE. That means ANOTHER 30 mins in this scenario. Hmmm editors are not to happy about this situation. Thing is. It get’s worse. What CAN happen is that editor publishes a change immediately AFTER the app server rolls over on it’s cache for the object, re-caches the old content and never sees the editors change. The re-cached old content in the appserver is then served again to varnish who could (as within the last example) roll over on it’s cache RIGHT at the end of the app servers cache cycle for the object BUT BEFORE the appserver’s cache actually invalidates. As explained in the last example the appserver serves varnish the old object, varnish re-caches the old object and then that old object is within the varnish cache for the extra cache cycle. SO in the worst case the editors story doesn’t get picked up for what is essentially the sum of TWO FULL CACHE CYCLES of both cache’s TTL’s.
All of this is VERY hard to explain to laypeople. Hence the picture above with the perty colorful stars.
I hope this helps someone out there. I know I will use it over and over again..
P.S. I do realize you can always just get rid of one of the application servers cache. Varnish is performing the same exact function so why bother. Fact is I simplified this example to html buffer caching in both layers so that you it would be easier to understand. What Is really going on is that the application layer is not caching the html buffer. It is actually caching the results of the queries from the database in memcache for a period of time. In addition there are “partials” strewn through out the app that are cached independently of context within the app which gives finer grained control over areas that change less frequently than varnish allows for. BTW I do realize varnish supports ESI allowing certain of these partials to be re-calculated at the app server rather than at varnish even when varnish serves some of the page from it’s cache. I hope to utilize ESI in the future but that will require an app re-write. ALSO I would love to have the application server send the cache invalidation requests upstream to varnish when it’s own cache cycles roll over on objects. Unfortunately the off the shelf app we are using is not that smart and again it would require a re-write to get that in there.
I have recently been doing some work with Camel routing library/engine for java that plays really nice with Spring and JMS via ActiveMQ. Camel makes it really easy to implement EIP (Enterprise Integration Patterns) into your Java app and ultimately allows you the beautiful flexibility describe in Gregor Hohpe’s work on enterprise integration patterns… great book btw!
Anyway I got to thinking how fun it would be to create a custom predicate that employs a machine learning algorithm (possibly based on a neural network) to do image recognition and route messages (images) based on it’s understanding of them. Given enough time and enough input this could really open up some awesome possibilities!
The most immediately applicable solution is moderation, allowing the AI to do the first pass, pipe positives to an administrative interface where an actual human being could determine if the image was actually naughty or if the algorithm flagged a false positive. The feedback on false positives could then be driven back into the pipeline thus tuning the algorithm further (false positives) or deleting the image from the servers and warning the contributing user (actual positives).
Another cool application would be to do something like google is doing where you could use the routing engine and the image recognition predicate to make a first guess at what the image is basically of and then query all sorts of different data stores/apis to find more information about the image. You wouldn’t need to do so much legwork query everything or storing a “master index” you could simply allow the algorithm to make an educated guess and say for example “this is a painting” or “this is a barcode” and then ONLY query the applicable datasources.
Of course this will be full of false positives. BUT if you make it fun and allow feedback back into the routing engine from the end users the algorithm will get smarter over time!
Performance profiling php in my opinion is best done with xdebug and kcachegrind (install it via APT on an Ubuntu virtual machine and save yourself some trouble. I know you can get it to work with xwindows natively on a mac but damn it’s not easy and it certainly isn’t as pretty as using it in KDE 4 )
How to performance profile an app is an art not covered here. Seriously if you want to start somewhere I suggest reading this article over at Zend developer zone (It’s from 2007 but it’s still relevant):
http://devzone.zend.com/article/2899-Profiling-PHP-Applications-With-xdebug
Also there is a great article if you can find it from the September 2004 edition of php|Architect… If you can’t find it on the internet email me and I will send you a PDF version of it. It is a complete and comprehensive article and should not be missed if you are working with xdebug at all.
So finally back on topic:
Installing xdebug is pretty easy assuming you have php/pecl/pear installed… If you don’t I suggest you use yum and if you don’t have that installed then just follow this tutorial: http://www.matteomattei.com/en/install-yum-and-php-pear-on-centos-5
Anyway once you have pecl installed you can run the following:
# pear install pecl/xdebug
downloading xdebug-2.0.5.tgz …
Starting to download xdebug-2.0.5.tgz (289,234 bytes)
……………………………………………………done: 289,234 bytes
67 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20050922
Zend Extension Api No: 220051025
/usr/bin/phpize: /tmp/tmpOcEvNL/xdebug-2.0.5/build/shtool: /bin/sh: bad interpreter: Permission denied
Cannot find autoconf. Please check your autoconf installation and the $PHP_AUTOCONF
environment variable is set correctly and then rerun this script.
Woops!
Looks like something is up with running /tmp/tmpOcEvNL/xdebug-2.0.5/build/shtool
I have seen this type of build error before when using other package management systems and it turns out that what I thought was true. That the /tmp directory was mounted with the noexec switch.
See here:
# mount -l | grep /tmp
simfs on /tmp type simfs (rw,noexec)
simfs on /var/tmp type simfs (rw,noexec)
# pear install pecl/xdebug
downloading xdebug-2.0.5.tgz …
Starting to download xdebug-2.0.5.tgz (289,234 bytes)
……………………………………………………done: 289,234 bytes
67 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20050922
Zend Extension Api No: 220051025
/usr/bin/phpize: /tmp/tmpOcEvNL/xdebug-2.0.5/build/shtool: /bin/sh: bad interpreter: Permission denied
Cannot find autoconf. Please check your autoconf installation and the $PHP_AUTOCONF
environment variable is set correctly and then rerun this script.
So let’s remount it with the exec switch:
mount -o remount,exec /tmp
And now let’s see what mount -l says:
mount -l | grep /tmp
simfs on /tmp type simfs (rw)
simfs on /var/tmp type simfs (rw,noexec)
So we can see that now the /tmp does not have noexec listed.
Ok let’s try and install via pecl again:
# pear install pecl/xdebug
downloading xdebug-2.0.5.tgz …
Starting to download xdebug-2.0.5.tgz (289,234 bytes)
……………………………………………………done: 289,234 bytes
67 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20050922
Zend Extension Api No: 220051025
building in /var/tmp/pear-build-root/xdebug-2.0.5
running: /tmp/tmp3tHVR2/xdebug-2.0.5/configure
checking for egrep… grep -E
checking for a sed that does not truncate output… /bin/sed
checking for gcc… gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… configure: error: cannot run C compiled programs.
If you meant to cross compile, use `–host’.
See `config.log’ for more details.
ERROR: `/tmp/tmp3tHVR2/xdebug-2.0.5/configure’ failed
Well were not in the clear yet the error looks surprisingly similar… let’s just try to mount /var/tmp without the noexec switch as well:
# mount -o remount,exec /var/tmp
And again the pecl install:
# pear install pecl/xdebug
downloading xdebug-2.0.5.tgz …
Starting to download xdebug-2.0.5.tgz (289,234 bytes)
…………………………………………..done: 289,234 bytes
67 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20050922
Zend Extension Api No: 220051025
building in /var/tmp/pear-build-root/xdebug-2.0.5
running: /tmp/tmpkWolpH/xdebug-2.0.5/configure
checking for egrep… grep -E
checking for a sed that does not truncate output… /bin/sed
checking for gcc… gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… yes
checking whether we are cross compiling… no
checking for suffix of executables…<SNIP>
Build process completed successfully
Installing ‘/var/tmp/pear-build-root/install-xdebug-2.0.5//usr/lib64/php/modules/xdebug.so’
install ok: channel://pecl.php.net/xdebug-2.0.5
You should add “extension=xdebug.so” to php.ini
Nice. Ok so now it worked. Notice the path that it was installed to (on this 64 bit machine it was): /usr/lib64/php/modules/xdebug.so
We will need that later when we put it in our new /etc/php.d/xdebug.ini: (the contents of which I will explain in another blog post but for now the comments inside of it should be self explanatory)
#extension_dir = “/usr/local/lib/php/20060613″
#doc_root=”/usr/local/apache2/htdocs/web”
#the following was added by jesse to fix the path variables when run in cgi mode
#cgi.fix_pathinfo=0zend_extension=”/usr/local/lib/php/20060613/xdebug.so”
#xdebug.remote_enable=1;JESSE: the following was taken from: http://code.google.com/p/syslogr-utils/wiki/XdebugHelper
;When using Eclipse with PDT and xdebug — make sure to change your
;tools –> addons –> xdebug helper –> preferences –> idekey = ECLIPSE_DBGP
;(This is the setting that XDEBUG_SESSION_START is set to on your web browser URL);JESSE: I have put the following notes in from some research into profiling with webgrind:
;(they were taken from: http://www.chrisabernethy.com/php-profiling-xdebug-webgrind/ );NOTE: usually use cachegrind.out.%t.%p when I want one output file per script run,
;but if I want to run a script multiple times and see the aggregate numbers
;I use cachegrind.out.%s and set xdebug.profiler_append = on;NOTE: A Nice to know, for different cachegrind files per host you can use %H in the
;profiler_output_name, according to
;http://www.xdebug.org/docs/all_settings#trace_output_name;Always profile scripts with xdebug:
;xdebug.profiler_enable = 1#xdebug.profiler_enable=1
;Alternatively, enable profiling with GET/POST parameter XDEBUG_PROFILE,
;e.g. http://localhost/samplepage.php?XDEBUG_PROFILE:
;xdebug.profiler_enable_trigger = 1xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=”/tmp/xdebug/”
;the following forces xdebug to append to the outfile rather than
;overwrite it on each exec of a script
;xdebug.profiler_append=On;the patterns for the names of the outfiles
;xdebug.profiler_output_name = cachegrind.out.%s
xdebug.profiler_output_name = cachegrind.out.%t.%p;the following opens debug output links in textmate
xdebug.file_link_format = “txmt://open?url=file://%f&line=%l”xdebug.remote_host=”127.0.0.1″
xdebug.remote_port=9000
xdebug.remote_handler=”dbgp”
xdebug.remote_mode=req
xdebug.idekey=1
Now check the php-cli and see if xdebug shows up in it’s ini dump.
php -i | grep xdebug
/etc/php.d/xdebug.ini,
xdebug
xdebug support => enabled
xdebug.auto_trace => Off => Off
xdebug.collect_includes => On => On
xdebug.collect_params => 0 => 0
xdebug.collect_return => Off => Off
xdebug.collect_vars => Off => Off
xdebug.default_enable => On => On
xdebug.dump.COOKIE => no value => no value<snip>
Looking good!
Oh and obviously restart apache… /etc/init.d/httpd restart
Sweet.
I had a client who didn’t understand why caching was breaking things on their site. Of particular nuisance was the polls. To be fair, grasping why something as easy as polls works without caching and then does not work with caching can be confusing. Here is the email I wrote to help educate all of us. Below you will see the contents of my email to them.
<snip>
To begin I think it is necessary to explain why things are cached and why caching has an impact on editorial workflow and functionality. Specifically this is in reference to polls. It’s going to take a bit to grasp what is happening so please read slow and bare with me.
Full web page caching or HTTP acceleration is done in part to effectively reduce the load experienced by an application and also to mask performance bottlenecks in the application to users.
Without caching, every time a user makes a request, that request eventually has some action that is performed by business logic in the application and ultimately the database. That action can actually be one or THOUSANDS of connections and queries. Those thousands of queries per user request are normally NOT unique as in one request will normally cause the same exact connections and queries to be performed as the next request for the same content. So as the number of users goes up the number of requests go up and ultimately the number of connections and queries on the db will go up (however far more dramatically).
Here are some scenarios:
1 user makes 1 request for 1 page that takes 500 queries to render = 500 queries on the database.
1 user makes 3 requests for 3 different pages each taking 500 queries to render = 1500 queries on the database.
2 users each make 3 requests for 3 different pages each taking 500 queries to render = 3000 queries.
It’s linear when you look at it in this fashion but if you think about how the database actually performs transactions you will see that the performance hit becomes EXPONENTIAL.
The database performs each transaction in a fashion that is sometimes blocking only allowing a single transaction to request a certain record at a time (rare in read only scenarios) OR the io needed to service requests can actually cause the processor to wait while the hard disks are saturated (common on high volume, data intensive applications). This wait time experienced by the processor can quickly add up to minutes experienced by an individual request. Minutes can become tens of minutes even hours as queries stack up waiting for the hard disks to return the data to the queries in the queue ahead of them.
There are many ways to solve this problem but the first is always to remove the waste.
Why perform all those non-unique calculations over and over again when you can just do them once, store the results and then return those stored results when the same non-unique request comes back again?
That is caching.
There are many levels of caching.
We can cache the query results for each query performed on the database. Every single one of the thousands of unique queries is currently kept cached automatically by the datbase for a certain period of time until it is thrown away to make room for “Hotter” queries.
We can also cache the results of the processing of the business logic (in the case of web applications this is usual some sort of html or xml output) those results can be used to produce an actual .html file on the hard disk.
This called “page level” caching.
Hotness explained (this is not unique to databases this is for most simple caching algorithms)
If a certain request is made for a certain piece of data lets assign it an importance value of 1.
If a subsequent request is made for that same data lets add 1 to that importance value so that it is now 2
If no other request is made for that data it’s value stays at 2 for some period of time.
Now let’s graph this importance or hotness value:
The x axis is some deliniation of the volume of data. Lets just presume that all your data is in a single directory and it all has random alphabetical filenames. Then X would possibly start at at AKURALEJD and end at ZNFNALHE. NOTE the filenames are RANDOMLY assigned to the data.
The Y axis is the hotness or importance value assigned to each piece of data so the Hotter the data the higher it is plotted on the Y axis.
What you will find is that SOME portion of the data is hotter than others. The plot of said hotness follows a bell curve.
So why not just cache ALL possible data ever produced by an application?
Memory is limited. We can’t possibly account for every single unique view of the data. SO we can only keep a portion of that data in the cache. There for we draw vertical lines on our graph starting at the middle of the bell curve and expanding them until the content contained in distance between them is equal to amount of available memory. After that the “tail ends” remain un-cached.
Now what happens when what’s hot changes? Well we have to make room in the cache so that this new data can be put in. How do we know what to throw out of the cache to make room? Well we introduce a lifetime or a TTL (Time To Live) on each element in the cache.
So in it’s most basic form a TTL will tell the cache to “Throw out anything older than X”
That means that as time goes on if something HAS not been requested in a longer period of time than the TTL is set to then it will eventually make it’s way out of the cache.
This aging process also allows for the content that is cached to be “refreshed” or updated periodically. SO if you add NEW data or change data in the application then those changes will eventually make their way into the cache and ultimately be seen by people making requests for cached data.
Ok so that all sounds good so why all the issues with caching?
Before we get into this we need to take an even farther step back. Let’s look at how our content is uniquely named.
When it comes to the web our content is uniquely named by it’s URL (uniform resource locator) See: http://en.wikipedia.org/wiki/Uniform_Resource_Locator
With a unique URL the cache is able to determine “what is what” or more technically what the “STATE” of the application is for that URL. The web used to be so simple.
What webservers do with URL’s:
I will briefly explain the two most common functions a web server performs. These are:
Responding to GET requests. (commonly associated with clicking a link)
Responding to POST requests. (commonly associated with pushing a submit button)
NOTE that BOTH are “REQUESTS” there for if you click a link OR click a submit button you are “REQUESTING” something from the webserver. In the case of a POST request most times you are also sending something extra to the webserver (for instance a contact form OR your answers to a poll!)
Once the webserver receives your request it will check to see if it is a GET or a POST, then it will check to see what file was requested and then if the file is of a certain type it will sometimes offload the request to some application server (for instance PHP running as a cgi process). This application server (PHP for instance) will then process the request (taking into account the information in the GET or POST, making needed database queries etc.) finally the application server returns a response back to the webserver which will in turn return the response to your browser.
That response may or may return unique information depending on what was passed in the GET or POST request to the webserver (and ultimately to the application server) NOTE: In the past ALL requests both GET and POST caused the browser to refresh the page. THAT fact alone is what defined WEB 1.0.
Enter AJAX.
Now web 2.0. We no longer have Unique URLS for every piece of content. More importantly we don’t have page refreshes upon every request. The same URL/page might look one way when you first visit it and then let’s just say (for the sake of a timely example) you submit a poll for instance. If the submission of that poll does not navigate you away from the page to a new URL then with page level caching you will never see the results of the poll as your submission will only return the same exact cached page that you first saw since the url is the same. THEREFOR you will see the UNSUBMITTED poll once again.
So then how do we deal with caching AND AJAX?
We do so in one of two ways.
1) By maintaining STATE or at least some subset of the state on the client side (within the browser’s cookies).
OR
2) By caching only small parts of a page that don’t change and allowing the other parts of a page to remain UNCACHED. This is commonly called “partial caching”.
So why not use partial caching on my project?
Partial caching is entirely application dependent. It has to be architected into the application from the start. You unfortunately cannot “just add” partial caching because someone has to take the time to determine which portions of an application CAN be cached and which portions CANNOT. Most times off the shelf web applications cannot have partial caching added on top of them. Most traditional CMS applications and legacy web applications are not Web 2.0 “savy” enough.
Drupal falls into a gray area. Some modules are smart enough. Others are not. In general you cannot use partial caching with drupal without some legwork.
SO we use the page level caching described above. Now what?
Well now we have to take into account the functionality implications of a page looking the same way no matter what every time you visit it. Sounds like it doesn’t fix anything, and it doesn’t, without some tricks.
To start we can tell the cache to NEVER respond to a POST request with cached content. That means that every time someone submits a poll then show them the results. The results are generated each time by the application server and then the unique response is sent back to the browser.
Why does the poll still NOT work on the site then?
The long and the short of it:
It does. BUT unfortunately the poll is one of those modules that was NOT written to be used with page level caching.
What’s happening is this:
The first time you visit the site (or at least before ever taking the poll) you get there by typing www.yourpage.com into your browser. That is a GET request and the homepage is retrieved from the cache. You see the poll and you ARE allowed to vote and you DO see your results. Your request is sent via a POST to the application servers and your response is returned by the application servers… NOT the cache because it was a POST request.
Then you navigate away from that page and everything is fine. Then let’s say you come back to the home page by clicking the logo in the top left. That is a GET request. The homepage is returned FROM THE CACHE this time and you do NOT see your results in the poll. You see a poll that has not been taken yet. Because that is how the homepage was cached originally.
SO then you try to take the poll again and this time it doesn’t let you submit. Why? Because the poll module in drupal was built to only allow ONE vote per person per poll. That means that you CANT submit the poll more than once.
So since you have already submitted and since the poll is cached as unsubmitted you are stuck with an unsubmittable poll.
DARN! How do we fix this?
The easy way: Make the polls allow more than one vote per person per poll. Really why is that so bad?
The hard way: Rewrite the poll module correctly to refresh itself via another Ajax call for an un-cached version of the results. This means essentially writing a new poll module.
I hope that explains why the polls are not working. Maybe you picked up a thing or two a long the way.
</snip>
I will go into the details later but I am thoroughly convinced that youtube is one of the largest most racist places on the internet. You would be hard-pressed to find a more high profile site with the N-word used so frequently in a derogatory sense. Anyway more recently in parallel I have been looking for some way of getting my hand’s on enough data to put Hadoop to the test. About a week ago the two idea’s converged in my head and I had a vision of creating an application that would consume all of the comments on youtube (or at least as many as it can swallow) and then using a little linguistic regexp magic figure out who is the MOST racist user on Youtube. I started out by writing the basic mapper in python in my previous post. It is only good for a single video however. I new I would need a spider and I was planning on writing my own (python has some awesome dom and xml parsing: beautiful soup mini-dom, expat) but decided that for future use it might be better to make use of something based on lucene. I have been using solr quite a bit lately but was hoping for something a little more lightweight. Luckily I was able to remember the name of the spider that came out shortly after lucene was made available. Nutch! It hasn’t had the glory that Solr has had in recent years (I don’t understand why these two projects exist and don’t converge?) but it turns out that it is now based on Hadoop by default! In fact little to my knowledge but it looks like Hadoop was actually spawned by Nutch?! Anyway I spent some time setting up nutch on a hadoop cluster today and I have to say it is still not the easiest thing in the world to work with. I am still new to Hadoop and was following this Nutch tutorial very closely. Unfortunatley it glazes over setting up the slave nodes so I plan to fill in the details here and offer them to the community. One thing that it fails to mention that I should have know from my other Hadoop tutorials (never underestimate the minutia!) hdfs configurations need to use FULLY qualified hostnames! you can’t just user your machine name even though you may be able to ping each machine on a local subnet with just the hostname and even though you can telnet from the slave machine to say an Httpd instance running on the namenode you WILL get silent failure when trying to telnet to the namenode daemon’s port. Check your firewalls of course but even if they are turned off on both your master and slave it is quite pssible you will just see:
telnet: connect to address 127.0.0.1: Connection refused
$telnet master 9000
telnet: connect to address 192.168.0.1: Connection refused
however if you try the same thing from the master machine itself it works!? (assuming your name node is currently running and supposedly listening on port 9000)
This of course through me for a loop and I assumed it was everything from firewalls to bad interconnects between my machines. Strange that I never thought about the hostnames. I guess it was because all other services between them have been working fine. If anyone has any idea why hdfs has a problem with this I would love to know.
Here is my python script for grabbing the latest 1000 comments (the api only allows access to the latest 1000 unfortunately) and then checks them against a regexp for matching agains known racist words. Right now it is just looking for the N word. This script will be one of the inner MAP tasks in a series of Map-Reduce steps.
#!/usr/bin/env python
import sys
import gdata.youtube
import gdata.youtube.service
import re
racist_pattern = re.compile(‘.*igger.*’, re.IGNORECASE)
#import pprint
#pp = pprint.PrettyPrinter(indent=4)
yt_service = gdata.youtube.service.YouTubeService()
#yt_service.developer_key = “” #turns out the developer key isn’t necessary
urlpattern = ‘http://gdata.youtube.com/feeds/api/videos/%s/comments?start-index=%d&max-results=50′
for line in sys.stdin:
video_id = line.strip()
index = 1
url = urlpattern % (video_id, index)
#print url
comments = []
while url:
if index < 20:
comment_feed = yt_service.GetYouTubeVideoCommentFeed(uri=url)
#comments.extend([ comment.content.text for comment in comment_feed.entry ])
for comment in comment_feed.entry:
if racist_pattern.match(comment.content.text):
print ‘%s\t%s\n’ % (comment.author[0].name.text, comment.content.text)
#print [ 'Author: %s\t Comment: %s\n' % (comment.author[0].name.text, comment.content.text) for comment in comment_feed.entry ]
url = comment_feed.GetNextLink().href
index += 1
else:
#currently the google youtube gdata api will not support over 1000 comments
url = ‘http://gdata.youtube.com/feeds/api/videos/%s/comments?start-index=951&max-results=49′ % video_id
comment_feed = yt_service.GetYouTubeVideoCommentFeed(uri=url)
for comment in comment_feed.entry:
if racist_pattern.match(comment.content.text):
print ‘%s\t%s\n’ % (comment.author[0].name.text, comment.content.text)
#comments.extend([ comment.content.text for comment in comment_feed.entry ])
#print [ 'Author: %s\t Comment: %s\n' % (comment.author[0].name.text, comment.content.text) for comment in comment_feed.entry ]
break
#!/usr/bin/env python
import sys
import gdata.youtube
import gdata.youtube.service
import re
racist_pattern = re.compile(‘.*igger.*’, re.IGNORECASE)
#import pprint
#pp = pprint.PrettyPrinter(indent=4)
yt_service = gdata.youtube.service.YouTubeService()
#yt_service.developer_key = “AI39si7MDdkK_3HKW7C-NykJxoCuBYSBk3GfFDdjEG7tHWmNIZKyLgnvLR9sj6D4wss3IXWQ-oIWm_hB29vb7oOFUCMk8OClMQ”
urlpattern = ‘http://gdata.youtube.com/feeds/api/videos/%s/comments?start-index=%d&max-results=50′
for line in sys.stdin:
video_id = line.strip()
index = 1
url = urlpattern % (video_id, index)
#print url
comments = []
while url:
if index < 20:
comment_feed = yt_service.GetYouTubeVideoCommentFeed(uri=url)
#comments.extend([ comment.content.text for comment in comment_feed.entry ])
for comment in comment_feed.entry:
if racist_pattern.match(comment.content.text):
print ‘%s\t%s\n’ % (comment.author[0].name.text, comment.content.text)
#print [ 'Author: %s\t Comment: %s\n' % (comment.author[0].name.text, comment.content.text) for comment in comment_feed.entry ]
url = comment_feed.GetNextLink().href
index += 1
else:
#currently the google youtube gdata api will not support over 1000 comments
url = ‘http://gdata.youtube.com/feeds/api/videos/%s/comments?start-index=951&max-results=49′ % video_id
comment_feed = yt_service.GetYouTubeVideoCommentFeed(uri=url)
for comment in comment_feed.entry:
if racist_pattern.match(comment.content.text):
print ‘%s\t%s\n’ % (comment.author[0].name.text, comment.content.text)
#comments.extend([ comment.content.text for comment in comment_feed.entry ])
#print [ 'Author: %s\t Comment: %s\n' % (comment.author[0].name.text, comment.content.text) for comment in comment_feed.entry ]
bre
I have been using Varnish for quite some time and have always wished that there was some way for Varnish to know to serve “Stale” pages when the upstream application servers are swamped. There is actually a feature request for this on the Varnish Trac system here. NOTE: this feature should not really be necessary unless you have underestimated the ability of your application servers to handle your traffic. However even after proper capacity planning sometimes you get well… DUGG. We all know the “digg effect” (formerly referred to as the “slashdot effect”) and it’s repercussions (500, Guru meditation, Houston we have a problem!) There are many ways to skin a cat, but none would be as simple as this (considering we have an existing varnish setup). I should note that simply getting “Dugg” or “Slashdotted” normally wouldn’t take down a site with a proper reverse proxy setup based on Varnish. If your TTL is appropriate and you are using an appropriate GRACE value (for you Squid readers: “stale-while-revalidate“) then you will probably not saturate your app servers. Unfortunately if your content is good and your UI is right then maybe, just maybe a certain percentage of your new readers will stick around. And here is where it gets scary for the app servers. Maybe just, maybe your new readers will start to navigate in ways that your cache is not used to. Maybe they will start to hit those really OLD articles that haven’t been requested in months! If you think about your sites content vs it’s popularity you it will look something like this:
No matter what you do there will always be something that falls into those “long tails” if your traffic patterns shift suddenly you can very well start to make a lot more request to your upstream servers than you (or more importantly your reverse proxy) expected.
Back to the task at hand. What can I do while I wait for the Varnish team to put this feature through? EASY… use Squid! There are so many debates over which reverse proxy is currently the fastest, which one is easier to setup or integrate with legacy apps etc. I’m certainly NOT trying to get into that! In fact I will skirt the issue entirely saying this: when the features are right and you can afford to use it then why not? NOW don’t get me wrong. Afford can mean a lot of things. Take it as you will. I personally HATE using software, ANY software when I don’t have to. In fact I try to design my stacks as small as possible. As a general rule LESS SOFTWARE IS BETTER! It means less maintenance, less quality assurance… less hastle! However there are situations like the one I described above when you are put between a rock and a hard place. I can either:
A) Swap Varnish out completely and start using squid.
B) Augment my http acceleration layer with squid.
C) Buy more application servers and avoid the issue.
I wish, I wish, I wish C was always an option. Unfortunately not all client’s can afford to simply throw more money at the problem. If I had my choice I would scale horizontally off to the…horizon. SO I now get to choose between A and B. A is what my Sysadmin gut feeling (about never using more software than necessary) is telling me to do. BUT A also has the Test Engineer in me screaming “You will have to test everything all over again!”
Sooo here is another instance where the REAL WORLD comes crashing down on good systems engineering. C is the cheapest most cost effective solution. It could be said that maintaing another piece of software over time is going to be more costly than the upfront cost of swapping out Varnish entirely. But consider this…the Varnish feature that I was mentioning earlier… has already been assigned. It is only a matter of time before someone decides to pick it up and implement it. Hell I might even go ahead and do it if I can find the time. (BTW if your reading this month’s past the publish date of this post then you should definitely check that Trac ticket and see what has become of it.)
C it is. Now I am going to have to dust off my Squid skills and install that beast again. (Of course I couldn’t get through an article about varnish and squid with out some opinion…. Setting up Squid is not the easiest thing in the world!)
I had a bit of a quandary today as I reviewed some code today and I decided to write up this little post on the experience. In essence it came down to choosing between code readability and code reuse. I am a huge fan of both and they almost never conflict in fact they almost always exist in a symbiotic state. But not this time.
This title of this post has been buzzing around in my head recently as I have been doing a lot of performance tuning on a very large and HIGHLY trafficked web site of a major print publication. Anyway I was recently reading (reference coming soon! until then dig through my delicious links) a blog post on the topic of performance tuning and why it is silly how often people micro-tuning. Think of that in the same negative respect that you think of micro-managing. It’s a waste of time and resources. The moral: even though performance tuning is normally a good thing, after a while it looses it’s value. You spend your money on the low hanging fruit (AHEM more hardware!)
Back to today. The code that I was reviewing had a few very cryptic stanzas that included a call to a function that consumed a single integer based parameter which after thorough inspection simply ended up determining if the query it finally triggers against the database is ascending or descending. Now I honestly doubt this developer (no matter how Jr) actually thought they would be increasing the performance of the application by including this integer parameter. In fact I am sure that they assumed that they were doing a good thing by reusing code (which I am a HUGE proponent of normally!) but when it came time for another developer to get into the code to augment it slightly it took exponentially more time then it would have if the original developer had simply a) created the database queries inline or b) created two separate nearly identical functions. Instead (fyi we are using an ORM that follows the ActiveRecord Pattern) the object has one single method getNextArticle(int foo) that returns both the previous AND the next article! How confusing! Anyway the best solution that required the least new untested code at this point was to wrap that function with two new functions that map to the integer values. Now we have:
/*Note that the following function has a different method signature than the original and thus can coexist due to the method overloading feature of java*/
getNextArticle(){
return this.getNextArticle(1);
}
getPreviousArticle(){
return this.getNextArticle(2);
}
I can already hear someone out there saying: “That’s silly why not re-factor the whole object so that it has:
getNextArticle()
getPreviousArticle()
wrapping some new function that is called with a String paramater like ASC or DESC.” Well to put it simply, time. Regression testing takes time and we would have to do a heck of a lot more of it on this project that unfortunately does not yet have 100% unit test coverage (to my DISDAIN) and does not have an automated testing setup. So the moral of the story is this. Even though code reuse is almost always a GOOD sign of proper software development practices sometimes it can lead to poor readability which then becomes more of a maintenance problem than the code reuse actually solves. In retrospect it would have been great to have found this code before it went through thorough user acceptance testing. However due to the accelerated nature of meeting client demands and working on unrealistic project schedules we were not able to do enough peer code reviews of code nor were we able to create a team large enough to do pair programming.
AHH how the real world always ruins principles, techniques, patterns and paradigms that work so well on paper!
