On Aug 3, 7:39 pm, iceb...@21cn.com wrote:
> Well, actually I am not sure whether is a wsgi problem or a webfaction
> problem. Anyway I just observe TWO separated instances of cache.ram inside
> ONE web2py instance. How could this be?
>
> Detail description.
>
> One of my web2py app's action is to refresh cache.ram and then log the result.
>
> def cron_job():
> session.forget() # otherwise session files will pile up
> unnecessarily
> cache.ram('foo', lambda: time_consuming_job(),
> time_expire=1800)
>
> # following code borrowed from appadmin.py's ccache()
> ram = { 'hits':0, 'misses':0 }
> for key, value in cache.ram.storage.items():
> if isinstance(value, dict):
> ram['hits'] = value['hit_total'] -
> value['misses']
> ram['misses'] = value['misses']
>
> status = 'hit:%d, miss:%d' % (ram['hits'], ram['misses'])
> open('cron_job.log', 'a').write('... (%s), [%s]'% (...,
> request.client, status))
>
> And there is an external web2py cron running this trigger script:
> import urllib
> urllib.urlopen('http://localhost:54321/myapp/default/cron_job').read()
>
> I setup web2py on webfaction days before. It is in wsgi mode, and I shrink
> the working process from 2 to 1 (in order to use cache.ram supposedly). The
> default apache2/conf/httpd.conf is very short and here is the important part
> (I think):
> LoadModule rewrite_module modules/mod_rewrite.so
> Listen 54321
> LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\"
> \"%{User-Agent}i\" %D" combined
> CustomLog /home/iceberg1975/logs/user/access_web2py_1_81_5.log
> combined
> ServerLimit 1
> WSGIScriptAlias /
> /home/my_webfaction_account/webapps/web2py_1_81_5/web2py/wsgihandler.py
>
> Everything seemingly works fine, until I surprisingly notice that, web2py
> uses one cache.ram instance when being visited by a real-world request, but
> uses another separated cache.ram instance when being visited by the
> localhost's cron job.
>
> Here is the apache log when being visited by a real-world request:
> 112.94.8.140 - - [03/Aug/2010:05:38:40 -0500] "GET /myapp/default/cron_job
> HTTP/1.0" 200 15 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
> AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.125 Safari/533.4" 34391
>
> And here is the apache log when being visited by local cron script, note that
> there is no incoming IP:
> - - - [03/Aug/2010:05:39:05 -0500] "GET /myapp/default/cron_job HTTP/1.0" 200
> 19 "-" "Python-urllib/1.17" 33972
>
> Both generate similar log on web2py level:
> 127.0.0.1, 2010-08-03 05:38:40, GET, /myapp/default/cron_job, HTTP/1.0, 200,
> 0.033933
> 127.0.0.1, 2010-08-03 05:39:05, GET, /myapp/default/cron_job, HTTP/1.0, 200,
> 0.033501
>
> But the cron_job.log reveals the difference, they are hitting different
> cache.ram instance. How come?
> Triggered at Tue Aug 3 05:38:40 2010, took 0.002 seconds. (112.94.8.140).
> [hit:54, miss:64]
> Triggered at Tue Aug 3 05:39:05 2010, took 0.002 seconds. (127.0.0.1).
> [hit:20727, miss:702]
>
> Oh yes, I guess one of the workaround/solution is to use cache.disk or
> cache.memcache instead. But I am still curious to know what cause the above
> "two cache.ram instances" problem even when I am running only one web2py
> process. Or, do I?
> [my_wf_acco...@web150 conf]$ ps -ef|grep 1_81
> 528 3529 1 0 Aug01 ? 00:00:00
> /home/MY_WF_ACCOUNT/webapps/web2py_1_81_5/apache2/bin/httpd -f
> /home/MY_WF_ACCOUNT/webapps/web2py_1_81_5/apache2/conf/httpd.conf -k start
> 528 3531 3529 0 Aug01 ? 00:01:37
> /home/MY_WF_ACCOUNT/webapps/web2py_1_81_5/apache2/bin/httpd -f
> /home/MY_WF_ACCOUNT/webapps/web2py_1_81_5/apache2/conf/httpd.conf -k start
>
> Any feedback will be appreciated.
>
> Sincerely,
> Iceberg, 2010-Aug-03, 18:39(PM), Tue
Mmm, I (partially) know the cause and solution. It is my cron script.
Change it from:
urllib.urlopen('http://localhost:54321/myapp/default/
cron_job').read()
into:
urllib.urlopen('http://MY_DOMAIN:80/myapp/default/
cron_job').read()
then the cron script DOES visit the server in exactly same way as end
user's browser, then serving by the same cache.ram instance. Problem
disappear.
I still don't know why a localhost:wsgi_port will cause problem. If
anyone has a theory or explanation, I will be more than happy to know.
That is it for today, my day X experience of web2py on webfaction.
Regards,
Iceberg
