Sign in to follow this  
  • entries
    557
  • comments
    1237
  • views
    420958

Untitled

Sign in to follow this  
Evil Steve

52 views

I like debug crap. I don't like the number of queries my forum requires though.

User registration:

Page required 9 database queries
Query 1: SELECT * FROM users WHERE username='Anonymous' LIMIT 1;
Query 2: SELECT * FROM config WHERE `key`='reuse_emails';
Query 3: SELECT username FROM users WHERE username='Steve' LIMIT 1;
Query 4: SELECT value FROM config WHERE `key`='register_type';
Query 5: DELETE users, user_activations from users, user_activations WHERE user_activations.expires <= 1181654020 AND users.username <> 'Anonymous'
Query 6: SELECT * FROM config WHERE `key`='forum_name' OR `key`='forum_addr';
Query 7: INSERT INTO users (`username`, `password`, `email`, `theme`, `active`, `register_time`, `register_ip`) VALUES ('Steve', 'a94a8fe5ccb19ba61c4c0873d391e987982fbbd3', 'test@test.com', 'default', '0', '1181654020', '1382862578');
Query 8: INSERT INTO user_activations (`id`, `key`, `expires`) VALUES ('10', '10f1a21ea75204aa3fde2b13155b022f', 1182258820);
Query 9: SELECT * FROM config WHERE `key`='email_from_addr' OR `key`='forum_name' OR `key`='mail_server_addr' OR `key`='mail_server_port' OR `key`='hostname';



That could be cut down a little if I read the entire "config" table at script startup, but that sounds like a bad idea. Suggestions?
Sign in to follow this  


3 Comments


Recommended Comments

You're trying to optimize at the wrong end. If your forum is ever going to be hammered by hits than it won't be the registration progress but rather the forum/thread listing or a single thread. You'd better take time to optimize the queries on those pages and to enable caching mechanisms than losing time optimizing something which will almost never be some kind of bottleneck.

Share this comment


Link to comment
Quote:
Original post by Gaheris
You're trying to optimize at the wrong end. If your forum is ever going to be hammered by hits than it won't be the registration progress but rather the forum/thread listing or a single thread. You'd better take time to optimize the queries on those pages and to enable caching mechanisms than losing time optimizing something which will almost never be some kind of bottleneck.
Yeah, I know the registration won't be a problem, but I mean in general. There's bound to be other times where I'll need to call a function that reads some settings from the config table. I suppose I could always do some sort of caching system if I need; fetch the most commonly used vars at the start, then fetch any additional ones as needed.

Share this comment


Link to comment
What trevorchan (7's backend) does is cache the generated board indexes and html for every thread, such that the only time it ever touches the database is when someone makes a post. Browsing the forums or a thread simply fetches the cached page. Works out pretty well.

phpbb2 keeps a lot of the user shit (which topics have been read, etc) in cookies. While, again, you're going to have to validate things like posts and user cp actions (lol cp), you can probably get away with caching all of the page generation stuff, which I think is the brunt of the load you'll be getting, since page requests are going to be far more common than posts.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now