Performance Tuning
- Thursday, December 20 2001 @ 06:13 AM EST
-
- Contributed by:
- Tony
-
- Views:
- 5,375
Tomorrow I am planning on releasing Geeklog 1.3.1 which will be nothing more than a bunch of minor bug fixes. I'd like to see the release after that really get after improving performance in Geeklog. I can categorize Geeklog's performance problems into two categories: 1) Database-related and 2) Template-related.
I know some of you Geeklog Admins have good PHP Kung-fu so I'd like to see what some of you are capable of doing to help boost Geeklog's performance. It doesn't matter how big or small the change is as long as it speeds things up. Take a page or two (or however many) and see if you can squeeze out some speed. If you can get something that impoves the speed by at least 0.1 of a second then post here how you did it. Any posted suggestions will be looked at and possibly added to the first post 1.3.1 release. To help, you can use the timer class in your /path/to/geeklog/system/classes/ directory or you can simply use the time output at the bottom of every page.
Let's see if we can't speed this bad-boy up!
The following comments are owned by whomever posted them. This site is not responsible for what they say.
(IMO, this should be the featured article)
That should speed things up for you.
Here are a few things that may help:
1. ob_start("ob_gzhandler"); - gzip's script output. The only problem is that it's incompatible with ancient browsers also it can be an issue if your server doesnt have a lot of cpu power.
2. zend optimizer. nuff said.
3. http://apc.communityconnect.com/. for debian users 'apt-get install php4-apc'. An alternative to zend cache and free as in beer.
4. If using postgres implement stored procedures/views etc.
5. Don't rely on tony to speed your hardware up he's not a magician, invest in new gear or look into hosting packages with more power.
-- matt
-----
.:Matrix9180:.
[Customize.org Admin]
[DeskMod.com - It\'s BACK!]
--matt
NOT IF THE CODE IS OPTIMIZED! UNOPTIMIZED CODE IS HARDER ON HARDWARE/SOFTWARE. IT DOESN\'T MATTER WHAT DATABASE YOU\'RE USING. NOT EVERYONE HAS THEIR OWN SERVER THEY CAN SET UP HOWEVER THEY WANT. OFF.
-----
.:Matrix9180:.
[Customize.org Admin]
[DeskMod.com - It\'s BACK!]
HAVE A NICE DAY.
-----
.:Matrix9180:.
[Customize.org Admin]
[DeskMod.com - It\'s BACK!]
Neither of you can really sway Tony\'s opinion of what he sees fit for Geeklog, so stop it. I\'m sure he\'s already been thinking about SQL optimizing, but is also giving you, the users, a chance to toss in your 2 cents. Something I believe both of you did about 4 replies ago.
I appreciate it if you could both take your argument somewhere else, where it can better be resolved and we can get back to what matters here, the optimization of geeklog.
Merry Christmas
See ya \'round, guys...
Ya gotta love the GPL.
latez
-----
boufdot.org - powered by Geeklog!
-----
.:Matrix9180:.
[Customize.org Admin]
[DeskMod.com - It\'s BACK!]
I forgot to login ;)
.:Matrix9180:.
[Customize.org Admin]
[DeskMod.com - It\'s BAAACK!!!]
I\'m sorry I\'ve been so hidden for so long, but my life is, er, weird! :-) Been working on my new column and my first novel! Not too mention politics are work are keeping me QUITE busy (but I find it fun, is that wrong?).
My suggestions are 1) don\'t let religous arguments rule the day (ie. MySQL vs Postrges, etc..) and 2) keep doing what your doing.!
Refining the SQL calls is the best way to improve profomance. Optimize tables and rework things if necessary.
Geeklog is looking great! My many thanks to all of you for carrying the torch!
God bless and Merry Chirstmas!
- Jason
the performance boost/ advanced features I have in mind might be what is needed to put GeekLog on top among the other CMSs.
-----
.:Matrix9180:.
[Customize.org Admin]
[DeskMod.com - It\\\'s BACK!]
A couple of things I know that can help is a) zend optimizer b) sql modifications and c) reevaluating indexes/keys
Also, I\'m still a big fan of caching the SQL calls using some of the tools. I\'m a bit hesitant to use something like APC just because it would make Geeklog harder to install.
I\'ll start with the Zend Optimizer and then post my findings here. After that I\'ll look at adding some new indexes and see if that doesn\'t help
Keep the ideas coming!!!
thanks.
CREATE INDEX stories_tid ON stories(tid(20))
FYI, I don't think you'll see major performance issues with Geeklog until you get a lot of data in your database. I'll be researching more indexes that might help.
Ok, this one is a bit more complicated but this ended up saving me .7 of second. I wanted to analyze all the SQL queries being executed by Geeklog to see if anything would stand out at me. To do this I created a simple table called sql_queries with two fields: 1) sql_id (auto increment) 2) sql_query (the actual sql executed) . I then added a mysql_query call to mysql.class.php to insert all sql in the table and what I found was a bit of a surprise.
The following SQL query was executed 53 times:
SELECT ug_main_grp_id,grp_name FROM group_assignments,groups WHERE grp_id = ug_main_grp_id AND ug_uid = **my_user_id**;
Obviously that alarmed me. I found out the culprit was SEC_inGroup() in lib-security. That function is called all over the place and it calls itself recursively compounding the number of SQL queries. I then noticed that the function above it SEC_getUserGroup() could be called once early on for the user and could server as a sort of cache for SEC_inGroup. So to fix this in lib-common.php after this line:
$_RIGHTS = explode(',',SEC_getUserPermissions());
I added this: // Cache the groups this user belongs to (saves us time later) $_GROUPS = SEC_getUserGroups($_USER['uid']);
The I changed SEC_inGroup() to use $_GROUPS like this.
Now that query only gets executed once! If you need to have the performance gain now then great, you can edit the files accordingly. Needless to say this enhancement will be in 1.3.1
SELECT ug_main_grp_id,grp_name FROM group_assignments,groups WHERE grp_id = ug_main_grp_id AND ug_grp_id = <some_group_id>
This query can be improved by adding an index on ug_grp_id:
CREATE INDEX group_assignments_ug_grp_id ON group_assignments(ug_grp_id);
This shaved about .26 of a second off.