The Real Cause Of High Load For My Server Using PLigg 9.9 and Was 9.8.2

[argh2xxx]

The problem I have with mod_gzip is that the last time I move the pligg database and location, the ajax failed to function correctly. Should I enabled? lolz

[bbrian017]

Originally Posted by argh2xxx

I have over 140,000 articles, maybe that is why it is slow?

That is a lot of article haha great work !

[argh2xxx]

cough * cough * cron cron crond
hehehe

[argh2xxx]

I'm improving the speed now! How? Empty all 140,000 articles. Yep I did that. But only one problem though, how can I get the bottom navigation menu to clear out 6190 empty pages? I should show only the page that contain pligg_links only you know... Any idea anyone?

By the way index pligg_links doesn't help when you got 140,000 links...

Also pligg is all dynamic, meaning pulling everything from mysql, and this is not a joke.

[moonomo]

Originally Posted by argh2xxx

I'm improving the speed now! How? Empty all 140,000 articles. Yep I did that. But only one problem though, how can I get the bottom navigation menu to clear out 6190 empty pages? I should show only the page that contain pligg_links only you know... Any idea anyone?

By the way index pligg_links doesn't help when you got 140,000 links...

Also pligg is all dynamic, meaning pulling everything from mysql, and this is not a joke.

Please, you did some test that only few others able, your post helped a lot to take a deep look where it's demand. Pligg devs are doing great jobs, if you can return something back, do that, if can't, getting away could be good idea... [Sorry, if it hurts you!]

It may sound rough but actually if someone got fire on their tail they should use shower immediately instead of waiting for firemen [meant: they should hire some pro to done jobs within their time line]. You ask for it, they promises to do something while they can. This kind of optimization take times, even sometime needs something more like a test environment with such huge stories.

In the meantime, yes, emptying stories is the best solution congrats, till you get such amount of stories again, there would be some good solution available, I am sure about that.

My 2 cents.

[bbrian017]

yeah because I will never delete my stories!

[HelloKitty]

Same problem too!

I had 45000 news in my database and my hoster mail me daily with my cpu load....

Big problems!

[richrf]

Hi,

I use to optimize database design and database performance for a living. In fact, I was a consultant to Oracle and Microsoft during the early years of SQL development. :-) The good ole days.

Anyway, there are four important steps toward performance optimization:


1) Database design to maximize maintainability, flexibility, and usability. This is the logical design.

2) Database schema design that minimizes I/O overhead (physical design) while maximizing database maintainability (logical design).

3) Index design (part of physical design) to support queries.

4) This is really important: SQL design so that the SQL query can make use of the indexes. This is different for each database engine since each engine has different algorithms for optimization. Most importantly, the SQL commands have to be sargable. That is, they have to be written in such a way that the SQL optimizer can make use of indexes. If the SQL is not sargable, then the optimizer will default into a full table scan, which can kill performance. In fact, with a join, it might continuously scan a table, which is really the kiss of death in a shared enviornment, since the tables are continually being moved out of cache.


Often a designer needs to find a balance between physical and logical design, because they are often in conflict.

Of the four, the logical database design is most important. If this is wrong, then there is little you can do from a physical design. This may be the core problem for Pligg. I can't know, until I spend a bit of time analyzing it, which I may do, if I proceed with Pligg. However, there are things that can be done on the physical implementation (indexes and SQL), to tune the system. If nothing else, certain functions can be turned off or eliminated to address certain performance problems. Clearly, there are some major issues, since MySQL can handle millions of rows of data if the database design is done correctly (there are many Wordpress blogs with tens of thousands of rows in their tables).

If someone wants to provide me with a schema, and sample queries that are crawling, I might be able to provide some feedback.

Rich

[argh2xxx]

Also for whom on linux/apache/php/mysql environment can install/compile eaccelerator or APC to provide faster response time for page loading and etc...

If Pligg creator can create Pligg in a way that allow pligg's owner to turn on multiple database option, where user can actually apply pligg's data throughout multiple database locally or remotely. This will help spreading the load. Wordpress-mu has this option at wpmudev.org. Wordpress-mu is also a very heavy resources hogging piece of software.