Originally posted by notjoe
The reason why Search is down is because of the Board Leech sites.
Collapse
X
-
He would have not started the other thread now would he?Originally posted by holographI dont think he has a problem with STB being banned by GFY
Comment
-
Sounds like fun.Originally posted by notjoeWhy dont you go take a walk beyond the israel border while screaming "I'm a jew I'm a jew"


NAKED HOSTING FTW!11 I'm On The INSANE PLAN $9.95/mo!
| The Alien Blog Adult News Worth Reading Updated Daily
| Content For Sale! 641 PICS 216 MINUTES OF VIDEO $350.00 |ICQ: 78943384 |Comment
-
if you want to keep them then you should keep them to yourselfOriginally posted by AlienQWhen I type and express my words and thoughts they are my words and thoughts. Mine.
when you post them here on a public forum you are giving them away. Consult with an attorney before you reply back please, before you choke on that foot.
ICQ: 86364801 Email: will [at] innovativeassets [dot] com
Comment
-
-
One thing I must add. You're looking at this issue from the wrong perspective, IMHO. I'm not referring specifically to the problems you are having with the search due to various service abuses, but to the overall mentality I'm sensing here.
GFY has become a major resource in this industry, and while it attracts many users on a daily (read: hourly) basis, it's also an opportunity for others with some entrepreneurial spirit to further enhance the board for the benefit of everyone else.
Those who seek to do so for legitimate purposes do not try to steal your traffic or content. It is simply an opportunity to make a buck while introducing useful utilities that are not currently available directly from GFY. STBoards with their tracking capabilities and the GFYStats project BlueWire is working on are only two examples.
Do you think eBay was crying when people developed various APIs and stand-alone services to remotely search items, image uploads/storage, or more advanced auction monitoring features? Nope. Because they were looking at the big picture. The same goes for Amazon. That's why those companies are still here.Comment
-
I'm just curious if GFY's tech have tried yet to convert the board tables into InnoDB. It's quick and painless to do, and is built exactly for millions of rows of data and providing speed.
I would assume they are already using row-level locking even with INNODB (if not, there's 99% of your problem right there), but InnoDB can still provide immediate advantages without touching the vb code at all.
They should atleast try a benchmark: copy their largest table and make it InnoDB, then run a few searches on the current version versus the InnoDB version and see what your results look like.
Small tables have been proven faster in INNODB from my experience, but once you get past 500,000 rows or so, InnoDB outperforms it. With 5-10 million rows or more, it outperforms it drastically.
Anyhow, if they want to try, "ALTER TABLE tbl_name TYPE=InnoDB" is all you need
Skype variuscr - Email varius AT gmailComment
-
Originally posted by VariusI'm just curious if GFY's tech have tried yet to convert the board tables into InnoDB. It's quick and painless to do, and is built exactly for millions of rows of data and providing speed.
Last time I checked...
INNODB = faster reads (use for read-heavy tables)
InnoDB = faster writes (use for write-heavy tables)
Maybe it's different now?... I initially got this information from a guy running one of the largest forums on the net. That was basically his nutshell response. He does use InnoDB, but only for write-heavy tables. The guy has a cluster of like... 40 servers or something.Last edited by goBigtime; 05-21-2005, 04:40 PM.Comment
-
From my experience with it, I've found that for selects, InnoDB is faster when the table in question is larger and is written to often. When the table is smaller or not frequently modified, then myisam is faster. Ofcourse InnoDB has other advantages like recovery features, transaction support, etc...Originally posted by goBigtimeLast time I checked...
INNODB = faster reads (use for read-heavy tables)
InnoDB = faster writes (use for write-heavy tables)
Maybe it's different now?... I initially got this information from a guy running one of the largest forums on the net. That was basically his nutshell response. He does use InnoDB, but only for write-heavy tables. The guy has a cluster of like... 40 servers or something.
Right now though we're checking out NDB type for use with MySQL Cluster.....hopefully it outperforms all the other types by leaps and bounds
Skype variuscr - Email varius AT gmailComment
-
mysql clusters can be awesome if you feed them lots of money for ramOriginally posted by VariusRight now though we're checking out NDB type for use with MySQL Cluster.....hopefully it outperforms all the other types by leaps and bounds
Comment
-
Don't be a monkey, you think you can teach the admins something? As if they 're newbs?Originally posted by VariusI'm just curious if GFY's tech have tried yet to convert the board tables into InnoDB. It's quick and painless to do, and is built exactly for millions of rows of data and providing speed.
I would assume they are already using row-level locking even with INNODB (if not, there's 99% of your problem right there), but InnoDB can still provide immediate advantages without touching the vb code at all.
They should atleast try a benchmark: copy their largest table and make it InnoDB, then run a few searches on the current version versus the InnoDB version and see what your results look like.
Small tables have been proven faster in INNODB from my experience, but once you get past 500,000 rows or so, InnoDB outperforms it. With 5-10 million rows or more, it outperforms it drastically.
Anyhow, if they want to try, "ALTER TABLE tbl_name TYPE=InnoDB" is all you need
Last edited by fireorange; 05-21-2005, 06:37 PM.Comment
-
Good to know what is going down I look forward to a faster stronger GFY soon as you take care of the issues.Comment
-
I'd like to know if our upcoming GFY stats project applies to this...
We are trying to provide this as a service to be something 'fun' for board members and we thought it would be useful for the sig market...
Our script doesnt provide search function or anything like that. Just gives stats on posters and only spiders once per week at an obscure time...
Here's the prototype..any thoughts?
http://www.bluewiredevelopment.com/w...=weekly&week=3Comment
-
Of course it applies, but it's an interesting idea, and maybe we can do something officially together.Originally posted by BlueWireI'd like to know if our upcoming GFY stats project applies to this...
We are trying to provide this as a service to be something 'fun' for board members and we thought it would be useful for the sig market...
Our script doesnt provide search function or anything like that. Just gives stats on posters and only spiders once per week at an obscure time...
Here's the prototype..any thoughts?
http://www.bluewiredevelopment.com/w...=weekly&week=3Comment
-
I would like to speak with you sometime Lensman. You're a hard time to get a hold ofOriginally posted by LensmanOf course it applies, but it's an interesting idea, and maybe we can do something officially together.
I had mentioned the idea to Eric because we're doing some design work for you guys right now....He said i'd need to talk to you.
Hopefully we can talk sometime on icq or phone. Thanks
Comment
-
BlueWire I hope you guys can get this up and going, I love the concept of your little side project. I've been a stats guy for years and get enjoyment from them. Keep up the great work.Comment
-
Originally posted by xclusiveBlueWire I hope you guys can get this up and going, I love the concept of your little side project. I've been a stats guy for years and get enjoyment from them. Keep up the great work.
Thanks
I hope so too. I really thought it would be cool ....AND i have even more ideas for stats we can track based off having the info that our spider currently collects....They would be able to show the cross between # of posts and quality of each post...
...of course...it'd be that much more effective if it was plugged right into the database *cough*
Comment
-
I believe the last few versions of mysql, myisam does support row-level locking now though....Originally posted by notjoeI believe the (main) difference between innodb and myisam is that there is row locking support with innodb and not with myisam. Multiple rows can be updated concurrently where as with myisam a thread needs exclusive access to the table.Skype variuscr - Email varius AT gmailComment
-
Doesn't require them being newbs...I just know I've had a ton of experience now with MySQL and large tables/database-intensive search queries, have already consulted with top developers and people who helped develop MySQL, etc...Originally posted by fireorangeDon't be a monkey, you think you can teach the admins something? As if they 're newbs?
Anyhow was just something I already offered to them to try awhile ago, was wondering if they ever got around to trying it out...Skype variuscr - Email varius AT gmailComment
-
I dont think so, atleast not in the production code they release...Googling for it seems to show noting which says myisam supports row locking.Originally posted by VariusI believe the last few versions of mysql, myisam does support row-level locking now though....
"Currently, MySQL supports table-level locking for ISAM, INNODB, and MEMORY (HEAP) tables, page-level locking for BDB tables, and row-level locking for InnoDB tables. "
http://dev.mysql.com/doc/mysql/en/internal-locking.htmlComment
-
Hrmm, I may have seen it in beta versions then perhaps of MySQL 5.....or maybe not. In any case, we prefer using InnoDB ourselves for the row-locking, transactions and performance on large tables. I only use myisam still on very small, static tables (like say a table with categories, statuses, etc...that have < 100 rows and barely ever change). I've also found myisam tables have a much greater chance for corruption than InnoDB tables do.Originally posted by notjoeI dont think so, atleast not in the production code they release...Googling for it seems to show noting which says myisam supports row locking.
"Currently, MySQL supports table-level locking for ISAM, INNODB, and MEMORY (HEAP) tables, page-level locking for BDB tables, and row-level locking for InnoDB tables. "
http://dev.mysql.com/doc/mysql/en/internal-locking.htmlSkype variuscr - Email varius AT gmailComment
-
Nice project you have there, all the best regarding its developmentOriginally posted by BlueWireI'd like to know if our upcoming GFY stats project applies to this...
We are trying to provide this as a service to be something 'fun' for board members and we thought it would be useful for the sig market...
Our script doesnt provide search function or anything like that. Just gives stats on posters and only spiders once per week at an obscure time...
Here's the prototype..any thoughts?
http://www.bluewiredevelopment.com/w...=weekly&week=3
Comment
-
Thanks...I hope we get to release itOriginally posted by RuiNice project you have there, all the best regarding its development

..also, if i might have a blatent plug right now. One of the Bluewire programming teams is opening up and we're accepting custom projects for them right now....PHP, PERL/CGI, MYSQL, FlashCom Server, Flash Remoting
Comment


Comment