• entries
557
1237
• views
420958

Untitled

52 views

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

User registration:
Page required 9 database queriesQuery 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?

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.

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.

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.

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