Eric Butera wrote:
Wouldn't you (probably) loose sessions in /tmp if the box crashed
also?
No, that wouldn't be the default behaviour. /tmp is typically on the
filesystem, and it's not cleared on every reboot (unless your system
has been configured to do so).
/Per Jessen, Zürich
--
PHP
Philip Thompson wrote:
Ok, so I've implemented this in several places where information
basically does not change from page to page. Jumping to the point/
question... when does it become more inefficient to store lots of
information in SESSION variables than to run several more queries?
Per Jessen a écrit :
No, that wouldn't be the default behaviour. /tmp is typically on the
filesystem, and it's not cleared on every reboot (unless your system
has been configured to do so).
In Debian based, it is the default behaviour. i hope it is the same
in other major distributions.
Lupus Michaelis wrote:
Per Jessen a écrit :
No, that wouldn't be the default behaviour. /tmp is typically on the
filesystem, and it's not cleared on every reboot (unless your system
has been configured to do so).
In Debian based, it is the default behaviour. i hope it is the same
in
On Sep 20, 2008, at 7:28 AM, Ashley Sheridan wrote:
On Fri, 2008-09-19 at 10:17 -0500, Philip Thompson wrote:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed up our application, we want to implement using SESSIONs
Philip Thompson schreef:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed up our application, we want to implement using SESSIONs in some
locations. Beforehand, on every page, we would run approximately 30-40
On Sun, Sep 21, 2008 at 6:48 PM, Jochem Maas [EMAIL PROTECTED] wrote:
Philip Thompson schreef:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed up our application, we want to implement using SESSIONs in some
On Fri, 2008-09-19 at 10:17 -0500, Philip Thompson wrote:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed up our application, we want to implement using SESSIONs in
some locations. Beforehand, on every page,
At 5:00 PM -0400 9/19/08, Robert Cummings wrote:
On Fri, 2008-09-19 at 21:31 +0100, Stut wrote:
I can modify this:
http://webbytedd.com/bb/pdf/
He said EXPENSIVE you insensitive clod!
Ahh, mood swings from ink poisoning?
Tedd: Charge $100 per certificate, Rob'll buy one, maybe
At 9:31 PM +0100 9/19/08, Stut wrote:
On 19 Sep 2008, at 21:22, Robert Cummings wrote:
On Fri, 2008-09-19 at 16:15 -0400, tedd wrote:
At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings
[EMAIL PROTECTED] wrote:
4. lack of industry adoption
There
At 4:53 PM -0400 9/19/08, Jason Pruim wrote:
Time's off by an hour :)
That's probably a day-light saving thing -- doesn't matter anyway.
I could have my graphic designer whip something up hehee :)
The problem is not designing the form, but rather programming it.
Each form takes a lot of
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed up our application, we want to implement using SESSIONs in
some locations. Beforehand, on every page, we would run approximately
30-40 queries just to get the page
Philip Thompson [EMAIL PROTECTED] wrote:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed up our application, we want to implement using SESSIONs in
some locations. Beforehand, on every page, we would
On Sep 19, 2008, at 10:54 AM, Wolf wrote:
Philip Thompson [EMAIL PROTECTED] wrote:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed up our application, we want to implement using SESSIONs in
some locations.
On 19 Sep 2008, at 17:05, Philip Thompson wrote:
On Sep 19, 2008, at 10:54 AM, Wolf wrote:
Philip Thompson [EMAIL PROTECTED] wrote:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed up our application, we want
On Fri, Sep 19, 2008 at 12:05 PM, Philip Thompson [EMAIL PROTECTED]wrote:
On Sep 19, 2008, at 10:54 AM, Wolf wrote:
Philip Thompson [EMAIL PROTECTED] wrote:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed
On Fri, Sep 19, 2008 at 12:05 PM, Philip Thompson
[EMAIL PROTECTED] wrote:
On Sep 19, 2008, at 10:54 AM, Wolf wrote:
Philip Thompson [EMAIL PROTECTED] wrote:
Hi all.
Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.
To speed
Use memcached based session handler
Regards
Sancar
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Sep 19, 2008, at 11:10 AM, Eric Butera wrote:
On Fri, Sep 19, 2008 at 12:05 PM, Philip Thompson
[EMAIL PROTECTED] wrote:
On Sep 19, 2008, at 10:54 AM, Wolf wrote:
Philip Thompson [EMAIL PROTECTED] wrote:
Hi all.
Let me start out by saying, I have STFW and read through the list
On Fri, 2008-09-19 at 12:47 -0500, Philip Thompson wrote:
Why do you have so many queries? Perhaps we can attack this issue
from another angle.
I've narrowed it down to 10 initial queries...
1. Grab system config data (that's used in lots of places)
Why not use some form of cache
On 19 Sep 2008, at 18:47, Philip Thompson wrote:
I've narrowed it down to 10 initial queries...
1. Grab system config data (that's used in lots of places)
Does it change often? No? Then cache it in a PHP script. Use
var_export to create a file that you can include which will create the
On Fri, 2008-09-19 at 19:12 +0100, Stut wrote:
Oh, and by scale I don't necessarily mean to tens of millions of page
views a month.
Someone needs to take away your coder badge if you make a site that
can't handle 1000 views a day :)
Not withstanding extreme edge cases doing unlikely
On 19 Sep 2008, at 19:20, Robert Cummings wrote:
On Fri, 2008-09-19 at 19:12 +0100, Stut wrote:
Oh, and by scale I don't necessarily mean to tens of millions of page
views a month.
Someone needs to take away your coder badge if you make a site that
can't handle 1000 views a day :)
Not
On Fri, 2008-09-19 at 19:32 +0100, Stut wrote:
On 19 Sep 2008, at 19:20, Robert Cummings wrote:
On Fri, 2008-09-19 at 19:12 +0100, Stut wrote:
Oh, and by scale I don't necessarily mean to tens of millions of page
views a month.
Someone needs to take away your coder badge if you make a
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote:
4. lack of industry adoption
There needs to be some sort of expensive test to certify one may wear
the badge. Then it will have higher adoption rates.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe,
On 19 Sep 2008, at 19:50, Robert Cummings wrote:
On Fri, 2008-09-19 at 19:32 +0100, Stut wrote:
Anyways, where can I get a coder badge, they sound cool!! ;)
I just draw one with a pen on my chest to show interviewers. So far it
really hasn't worked out well but I've narrowed the problem down
On Sep 19, 2008, at 1:12 PM, Stut wrote:
On 19 Sep 2008, at 18:47, Philip Thompson wrote:
I've narrowed it down to 10 initial queries...
1. Grab system config data (that's used in lots of places)
Does it change often? No? Then cache it in a PHP script. Use
var_export to create a file that
At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote:
4. lack of industry adoption
There needs to be some sort of expensive test to certify one may wear
the badge. Then it will have higher adoption rates.
I can modify
On Fri, 2008-09-19 at 16:15 -0400, tedd wrote:
At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote:
4. lack of industry adoption
There needs to be some sort of expensive test to certify one may wear
the badge. Then it
On 19 Sep 2008, at 21:22, Robert Cummings wrote:
On Fri, 2008-09-19 at 16:15 -0400, tedd wrote:
At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED]
wrote:
4. lack of industry adoption
There needs to be some sort of expensive
On Fri, Sep 19, 2008 at 4:31 PM, Stut [EMAIL PROTECTED] wrote:
On 19 Sep 2008, at 21:22, Robert Cummings wrote:
On Fri, 2008-09-19 at 16:15 -0400, tedd wrote:
At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED]
wrote:
4. lack
I have more questions/responses throughout...
On Sep 19, 2008, at 1:12 PM, Stut wrote:
On 19 Sep 2008, at 18:47, Philip Thompson wrote:
I've narrowed it down to 10 initial queries...
1. Grab system config data (that's used in lots of places)
Does it change often? No? Then cache it in a PHP
Time's off by an hour :)
I could have my graphic designer whip something up hehee :)
On Sep 19, 2008, at 4:15 PM, tedd wrote:
At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED]
wrote:
4. lack of industry adoption
There
On Fri, 2008-09-19 at 21:31 +0100, Stut wrote:
I can modify this:
http://webbytedd.com/bb/pdf/
He said EXPENSIVE you insensitive clod!
Ahh, mood swings from ink poisoning?
Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!!
I've managed to avoid getting the
On 19 Sep 2008, at 21:44, Philip Thompson wrote:
On Sep 19, 2008, at 1:12 PM, Stut wrote:
On 19 Sep 2008, at 18:47, Philip Thompson wrote:
4. Grab user privs
IMHO you should only grab these when you need them.
I will need these on most pages anyway. Because of the architecture,
the
On Sep 19, 2008, at 4:01 PM, Stut wrote:
On 19 Sep 2008, at 21:44, Philip Thompson wrote:
On Sep 19, 2008, at 1:12 PM, Stut wrote:
On 19 Sep 2008, at 18:47, Philip Thompson wrote:
4. Grab user privs
IMHO you should only grab these when you need them.
I will need these on most pages
On 19 Sep 2008, at 22:33, Philip Thompson wrote:
On Sep 19, 2008, at 4:01 PM, Stut wrote:
On 19 Sep 2008, at 21:44, Philip Thompson wrote:
On Sep 19, 2008, at 1:12 PM, Stut wrote:
On 19 Sep 2008, at 18:47, Philip Thompson wrote:
6. Begin transaction
7. Lock user session row
8. Update user
Alberto García Gómez wrote:
I'm seeking for some class to work with sessions against a mysql DB,
please examples are welcome.
http://php.stut.net/104-mysql_sessions.html
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
I'm seeking for some class to work with sessions against a mysql DB, please
examples are welcome.
Este correo ha sido enviado desde el Politécnico de Informática Carlos Marx
de Matanzas.
La gran batalla se librará en el campo de las ideas
--
PHP General Mailing List (http://www.php.net/)
To
I've recently begun work on a web-based RPG game with some friends, and have
recently been thinking about the best solution for loading and saving
persistent variables like player life/stats and other information. I am both
familiar with sessions and mysql for saving and loading variables, and
On Wed, May 30, 2007 4:00 am, Matt Fielding wrote:
I've recently begun work on a web-based RPG game with some friends,
and have
recently been thinking about the best solution for loading and saving
persistent variables like player life/stats and other information. I
am both
familiar with
As far as scalability goes, there's actually a game we're referencing a lot
to help us make it work at the get go called Kingdom of Loathing (
http://www.kingdomofloathing.com ). This game seems to have on average
around 1,000-1,500 users on at any given time. I've noticed when visiting
the page
I have an application where I want users to only be allowed 5 searches
per day unless they create an account.
There may not be a simple answer to this, but in general, would it be
preferred to do this with 24-hour session variables, or by writing a
MySQL record for each visitor with the date
On Wednesday 04 February 2004 00:05, Brian Dunning wrote:
I have an application where I want users to only be allowed 5 searches
per day unless they create an account.
Unless you require that a user logs in before they can perform a search then
there is no meaningful way to track how many
Hi,
By sessions i assume you mean cookies (session information can be stored
in other places such as a mysql database). If you do store the
information in a cookie, your visitors can easily delete the cooky and
get past your protection mechanism.
Having said that opting for a mysql table that
On Tue, 2004-02-03 at 11:05, Brian Dunning wrote:
I have an application where I want users to only be allowed 5 searches
per day unless they create an account.
There may not be a simple answer to this, but in general, would it be
preferred to do this with 24-hour session variables, or by
46 matches
Mail list logo
