On 15/02/2015, at 10:53 AM, Paul Royik <[email protected]> wrote:
> I already tried this approach.
>
> It seems good.
> But when I tested it on server, by simultaneously executing page on two
> different computers, it gave me 500 error.
>
> How this can be explained? Again something with apache? Logs didn't show
> anything. But I noticed again serious memory usage. And this happens only
> when I use code for limiting time.
Some tips for you about ensuring you get the best help.
Stop discarding the message content for the message you are replying to. It can
be frustrating to have to keep going back to old messages to see what was said
originally and what you may be following up to, especially when on a phone.
When asking questions on mailing list, let the person you are asking questions
of decide what can be discarded from the message chain as they will know better
what should be kept in the message to provide easy access to important
information for context.
When you reply to say you are have a new error, provide the actual code you
were using exactly at the time you had the error. Saves the person who is
helping you having to go back and ask for it if it is unclear what code you
were using.
Your messages here and on StackOverflow show that you play around with the
example code I am giving you and I have reduced confidence you were running
with the code I suggested at the time of the problem you are now relating to.
If you are getting 500 errors and nothing is being logged, it is because Django
is capturing the exception and converting it to a generic 500 error response
page. Configure Django to send you emails with the details of the exceptions.
If you are on a local system, then set DEBUG=True in the Django settings so the
details of the error are shown in response that goes back to the browser.
As to the code, I did test it this time, including under mod_wsgi with 20
request threads and hitting it with concurrent and successive requests with a
benchmarking tool. I saw no issues and it appeared to behave as I would expect.
So in a test2.py file I had:
import time
import functools
import threading
def time_limit(seconds):
def decorator(func):
func.info = threading.local()
def check_timeout():
if time.time() > func.info.end_time:
raise RuntimeError('timeout')
func.check_timeout = check_timeout
@functools.wraps(func)
def wrapper(*args, **kwargs):
print 'hasattr counter', hasattr(func.info, 'counter')
if not hasattr(func.info, 'counter'):
print 'init counter to 0'
func.info.counter = 0
if func.info.counter == 0:
func.info.end_time = time.time() + seconds
print 'counter', func.info.counter
func.info.counter += 1
try:
return func(*args, **kwargs)
finally:
func.info.counter -= 1
return wrapper
return decorator
@time_limit(5)
def algorithm(limit, nest=0):
algorithm.check_timeout()
print 'sleep'
time.sleep(1.0)
if nest == limit:
print 'return'
return
algorithm(limit, nest+1)
In serial2.py I had a straight serialised test:
from test2 import algorithm
try:
algorithm(3)
except RuntimeError:
print 'timeout'
try:
algorithm(10)
except RuntimeError:
print 'timeout'
try:
algorithm(10)
except RuntimeError:
print 'timeout'
And then in hello2.wsgi I had it used by a WSGI application.
from test2 import algorithm
def application(environ, start_response):
status = '200 OK'
output = b'Hello World!'
algorithm(1)
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
In the latter case I ran mod_wsgi-express against it as:
mod_wsgi-express start-server hello2.wsgi --port 8002 --threads=20
and then hit it with ab as:
ab -n 100 -c 15 http://localhost:8002/
In this case it wasn't designed to timeout anything, but that should not be a
concern as the counter initialisation is still being tested.
Do note that if you did cut and paste that last code, I did change the
exception type.
Anyway, the best thing to do is setup Django so that it provides the details of
the exception it captured but then effectively discarded because it converted
it to a 500 page.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
