I'm deep into developing an application in Cakephp 1.3 so while I'd like to upgrade to version 2 I'd rather leave that as a last resort.
My problem is that the Token expiration time for forms when the security component is used is too low. I expect people to sit on this form for a little while, but after 10 minutes using it will result in a blackhole.
Is there anyway to increase the time before the token expires? Cakephp 2 has this option as detailed here: cakephp 2 security csrf-configuration
It doesn't seem to work in 1.3, is there a way?
Yes this is perfectly do-able, look for the Session.timeout number in your config/core.php and increase it. The number assigned is the base amount of seconds, the actual amount of time the timeout is set to is depending on your security level also:
High: Session.timeout * 10
Medium: Session.timeout * 100
Low: Session.timeout * 300.
As you want the features of high security, I would keep it on high but increase Session.timeout to your needs.
Further reading.
Update
It actually turns out that the Form token timeout only depends on the security level, and for some reason doesn't take the timeout into effect (see here), so the only way to increase this is to lower the security level or alter Cake :/
Related
how can I check my requirement of 100 requests are processed in less than 1 second in my gatling3 report. I ran this using jenkins.
my simulation looks like as below
rampConcurrentUsers(1) to (100) during (161 second),
constantConcurrentUsers(100) during (1 minute)
Below is my response time percentile graph of two executions for an interval of one second.
enter image []1 here
What does the min,max here will tell us, i am assuming the percentages 25%-99% are the completion of the request.
Those graph sections are not what you're after - they show the distribution of response times and the number of active users.
So min is the fastest response time
max is the longest
95% is the response time for which 95% of your requests were under
and so on...
So what you could do is look at the section of your graph corresponding to the 100 constant concurrent users injection stage. In this part you would require that the max response time always be under 1 second
(Note: there's something odd with your 2nd report - I assume it didn't come from running the stated injection profile as it has more than 100 concurrent users active)
It seems like I'm being overbilled but I want to make sure I am not misunderstanding how Per Use billing works. Here are the details:
I'm running a small test PHP application on Google App Engine with no visitors other than myself every once in a while.
I periodically reset the database via cron: originally every hour, then every 3 hours last month, now every 6 hours.
Pricing plan: Per Use
Storage Used: 0.1% of 250 GB
Type: First Generation
IPv4 address: None
File system replication: Synchronous
Tier: D0
Activation Policy: On demand
Here's the billing through the first 16 days of this months:
Google SQL Service D0 usage - hour 383 hour(s) $9.57
16 days * 24 hours = 384 hours * $.025 = $9.60 . So it appears I've been charged every hour this month. This also happened last month.
I understand that I am charged the full hour for every part of an hour that the SQL instance is active.
Still, with the minimal app usage and the database reset 4 times a day, I would expect the charges (even allowing for a couple extra hours of usage each day) to be closer to:
16 days * 6 hours = 80 hours * $.025 = $2.40.
Any explanation for the discrepency?
The logs are the source of truth usually. Check them to see if you are being visited by an aggressive crawler, a stuck task that keeps retrying etc.
Or you may have a cron job that is running and performing work. You can view that in the "task queue/cron jobs" section in the control panel.
You might be have assigned an Ipv4 address to your instance and Google Developer Console clearly states
You will be charged $0.01 each hour the instance is inactive and has an IPv4 address assigned.
This might be the reason of your extra bill.
My program fetches ~100 entries in a loop. All entries are fetched using get_by_key_name(). Appstats show that some get_by_key_name() requests are taking as much as 750ms! (other big values are 355ms, 260ms, 230ms). Average for other fetches ranges from 30ms to 100ms. These times are in real_time and hence contribute towards 'ms' and not 'cpu_ms'.
Due to the above, total time taken to return the webpage is very high ms=5754, where cpu_ms=1472. (above times are seen repeatedly for back to back requests.)
Environment: Python 2.7, webapp2, jinja2, High Replication, No other concurrent requests to the server, Frontend Instance Class is F1, No memcache set yet, max idle instances is automatic, min pending latency is automatic, using db (NOT NDB).
Any help will be greatly appreciated as I based whole database design on fetching entries from the datastore using only get_by_key_name()!!
Update:
I tried profiling using time.clock() before and immediately after every get_by_key_name() method call. The difference I get from time.clock() for every single call is 10ms! (Just want to clarify that the get_by_key_name() is called on different Kinds).
According to time.clock() the total execution time (in wall-clock time) is 660ms. But the real-time is 5754 (=ms), and cpu_ms is 1472 per GAE logs.
Summary of Questions:
*[Update: This was addressed by passing list of keys] Why get_by_key_name() is taking that long?*
Why ms of 5754 is so much more than cpu_ms of 1472. Is task execution in halted/waiting-state for 75% (1-1472/5754) of the time due to which real-time (wall clock) time taken is so long as far as end user is concerned?
If the above is true, then why time.clock() shows that only 660ms (wall-clock time) elapsed between start of the first get_by_key_name() request and the last (~100th) get_by_key_name() request; although GAE shows this time as 5754ms?
The Google App Engine memcache documentation states that the time parameter of memcache.set() is an "Optional expiration time, either relative number of seconds from current time (up to 1 month), or an absolute Unix epoch time."
So I tried to set a value for 30 days, which according to Google is 2 592 000 seconds.
However, I highly suspect that this value is too high, because the value was set (memcache.set() returned the value True), but a memcache.get() just after always returned None. Reducing this value to 1 728 000 seconds just worked fine/as expected.
I guess that once passed the highest value, the time parameter gets interpreted as an absolute Unix epoch time. That would mean that 2 592 000 seconds got interpreted as "Sat, 31 Jan 1970 00:00:00 GMT", which is obviously a date in the past...
So what is the highest value you can enter that will get interpreted as a number of seconds in the future?
Edit: On the local dev server, 2 592 000 second worked OK, but not on the production servers. I suppose both servers have a different interpretation of the values.
Your linked Google documentation is oddly imprecise; the actual memcached documentation is more specific, saying the number may not exceed 2,592,000 (30 days of seconds). So in theory, that should have worked, barring implementation issues. (That statement is echoed in the PHP documentation for its memcache stuff.) So according to the memcached docs, your first value should have worked.
I don't suppose 2,591,999 works? The Google doc does say "up to one month", which if you assume 30 days in a month (not a valid assumption) would be up to 2,592,000 (e.g., but not including). That's at odds with the memcached docs, but perhaps there's an implementation difference or something.
We recently got some data back on a benchmarking test from a software vendor, and I think I'm missing something obvious.
If there were 17 transactions (I assume they mean successfully completed requests) per second, and 1500 of these requests could be served in 5 minutes, then how do I get the response time for a single user? Is this sort of thing even possible with benchmarking? I have a lot of other data from them, including apache config settings, but I'm not sure how to do all the math.
Given the server setup they sent, I want to know how I can deduce the user response time. I have looked at other similar benchmarking tests, but I'm having trouble measuring requests to response time. What other data do I need to provide here to get that?
If only 1500 of these can be served per 5 minutes then:
1500 / 5 = 300 transactions per min can be served
300 / 60 = 5 transactions per second can be served
so how are they getting 17 completed transactions per second? Last time I checked 5 < 17 !
This doesn't seem to fit. Or am I looking at it wrongly?
I presume be user response time, you mean the time it takes to serve a single transaction:
If they can serve 5 per second than it takes 200ms (1/5) per transaction
If they can serve 17 per second than it takes 59ms (1/17) per transaction
That is all we can tell from the given data. Perhaps clarify how many transactions are being done per second.