MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
I was referring to the time(), and thinking of alternative ways of replacing the time() call.
I did that (without using the macros) - but didn't see much difference
though.. I think I was banging my head against the wall yesterday - by tring
to remove something, but introducing something else complex :(..
cool, thanks. Not sure why it didn't work, but whatever.
Infact, I tried this out yesterday (having the one global_time variable), it gives me around 3-4% improvement. But, occasionally I do get some un-conforming results, and I'm trying to figure out if it's because of the time stamp.
OK, I'm thinking of a compromise here...
1. Let's get your version working right, i.e., no complaints from the client
2. then let's see if we can move the init of global_time out of specweb99_quick_handler() to do_cadget() so we don't have any time overhead for the other types of requests that don't need it
3. then let's see if we can set global_time by feeding r->request_time thru a macro, rather than using a syscall
So do you want to post a patch for your version with the global_time? I'll be happy to take a look at it and see if I can help figure out why the client is complaining.
2. mmap the post.log, and since the post.log is requested only once, it can be closed & re-mapped when the request comes in.
That might work. I'm thinking that moving it to shared memory would be the ultimate cheap way to do it though.
Greg
p.s. something you might want to try is to change the workload mix parameters (DYNAMIC_CONTENT, DYNAMIC_POST, etc) in the rc file so that you get 100% static requests, 100% POSTs, 100% CAD GETs, or 100% standard dynamic GETs. The last time I did that, the CAD GETs were the slowest of all and std dynamic GETs were faster than static files, believe it or not. But then I got rid of a couple of strlen's in the CAD path, so I don't know which part of the workload is the slowest at the moment (other than CGI, and they are always going to suck).
