chrometweaks.org

How can I post a Youtube clip using iPage and Wordpress?

Click Here To View All Answers...


Got a quick question: How can I post a Youtube clip using iPage and Wordpress? Thanks for any comment. Second question.. Seeing as there's not yet too many shows of interest in my proposal, I thought I'd get some code done and do some quick benchmarking..

And I've thrown in a catchy title this time, just for good measure :-).

I have reworked the database parts of the category box to get some these benchmarks done..

I hope these ideas find their way into osC as I think it would help tremendously with performance. If this is not the right channel to get these ideas across to the dev team please let me know where I should post this instead..

I expect there are similar gains to be made with several other parts of the code, there are more places where there are queries inside loops..

Ok, on to the benchmarks, the first results look.

Really.

Promising:.

All results in seconds are averages over 10 runs, using the same database and server, doing requests for.

Http://osc-cvs.denet...dex.php?cPath=1.

On an (almost) stock osC install. With default number of categories..

With SHOW_COUNTS 'true':.

Avg parse time*:.

Old code:  .9087.

New code:  .6598  (27% faster).

Avg query time**:.

Old code:  .3445.

New code:  .1907***    ( 45% faster ).

With SHOW_COUNTS 'false':.

Avg parse time:.

Old code:  .6921.

New code:  .6159  (11% faster).

Avg query time**:.

Old code:  .2043.

New code:  .1755  (14% faster).

The code literally reduces the number of database queries with dozens per page. This is especially true when SHOW_COUNTS is enabled. As you can see the new code is faster (In terms of query time) with SHOW_COUNTS enabled than the old code was without!.

Keep in mind that these results where for a default install of osC. (I have been playing around with it, so it's not a complete virgin database, there are some reviews and purchases done).

However if you have more categories in your database the performance gain will most likely be even bigger..

The display code for these results is really sloppy, I just wanted to hack something into osC to get the database timings. So take the overall timing benchmarks with a big grain of salt, I have not tried to implement this code efficiently, or functionally equivalent to the orignal code..

P.S.:.

For those of you who read my previous post, I made a mistake there..

The number of queries for the category box are:.

SHOW_COUNTS = 'true'.

- one query per category that has subcategories..

SHOW_COUNTS = 'false'.

- one query per displayed category contaiing subcategories..

Rob.

=======.

The usual disclaimers apply; These are results on my box not yours, using my data not yours!.

* These are of limited value I did not finish the layout code, the code currently constructs a multidimensional array with the category info..

** These are measured by timing each tep_db_query(). So this is.

Excluding.

Any time setting up the connections..

*** Sadly there was one .22 result the others were all in the .18 -.19 range..

Comments (188)

I'm stumped. I'm not so sure what is the answer to that question. I'll do some investigation and get back to you if I got an decent answer. You should email the people at iPage as they probably could give you an answer..

Comment #1

Seeing as there were some downloads of my code, but no replies yet I uploaded a new version of the benchmark code..

The download is bigger, but testing should be much easier, just unpack adjust the configure.php and you're done..

To everyone that downloaded the previous code and decided it was too much of a hassle, give this a try..

And for your viewing pleasure, a pretty graph of the improvements on an osC demo database...

Comment #2

Sorry I forgot:.

The old code benchmark code download is still available as:.

Http://www.cryp2nite...alog-0.1.tar.gz.

New download:.

Http://www.cryp2nite..._catalog.tar.gz..

Comment #3

This looks interesting, it would be great to hear what the developers think..

Would like to help but definitely out of my depth.

Dave..

Comment #4

Anyone who has a osC server to play around with can do the benchmarks. I would just like some confirmation of my results..

And some indication of how well this works on setups other than my own..

If it really works as well as I think it will, I'd like to get this on the radar for the dev team as well..

Cheers,.

Rob..

Comment #5

I just downloaded your improved version and will give it a try. I have a few sites that I can test it on. I will post the results later tonight...

Comment #6

Hi all,.

I noticed a number of you have downloaded the tests, but I don't see any results (yet)..

If you have downloaded the code, but are having problems doing the benchmarks please let me know so I can maybe help out..

I would really like some benchmark data other than my own..

Cheers,.

Rob..

Comment #7

Hi Rob.

I have not had a chance to install and use your code..

I am booked up today but will try to give it a shot tonight or tomorrow..

I will let you know the results as soon as I am able to get some time to do it...

Comment #8

NP,.

Whenever you have the time..

It's just that I registered about dozen downloads and got no response. And because english is not my native language, I figured maybe the included instructions are not as clear as they could be :?.

Cheers,.

Rob..

Comment #9

Linux,Konqueror, XS4all,....

Hmm,.. care to help a fellow countryman out?.

Sorry, OT, couldn't resist :oops: ..

Rob..

Comment #10

I tried this and it screwed up my navigation... probaby because I custom coded that a while back.

It loads fairly fast for me with it true. and I like the fact that it shows the number of products in each category.

I guess it's personal preference..

Comment #11

I know it messes up the navigation, it's in the readme. I just need some benchmark figures on setups other than my own. If it is significantly faster than the regular menu, I will finish it so you don't see the difference with the old wrt to output. But I would first like to know I'm not wasting my time on this before spending any more time on this..

It prints out numbers for 'Parse time' and 'Query time' at the bottom of each page. Could you give me some numbers for the catalog_ori and the catalog_new versions?.

What would also be helpful is some figures regarding the number of categories and products in your setup..

Or is there any way I can access you setup online, so I could check these myself?.

Thanks for taking the time installing this..

Cheers,.

Rob..

Comment #12

Where does it print out parse time and query time? maybe you have a newer version of osc than I do...

I'll post both catalog files once I know how to add those times in... i'd like to know myself too. this store I'm working with has about 5000 items online right now..

Comment #13

Did you download the second file that extracts to two directories named 'catalog_ori' and 'catalog_new' ?

Comment #14

No I didnt download anything... i'll do it later, I'm busy now..

Comment #15

I just realised:.

Did you read this in the readme?.

2. Make sure 'Display The Page Parse Time' is set to 'true' in admin ->.

Configuration -> logging..

It should display timing data on the bottom of the page..

Comment #16

Sorry, I misinterpreted your earlier post. I thought you meant you downloaded and tried my new category code..

Sorry about the confusion,.

Rob..

Comment #17

I don't know exactly what you mean, but as I said the code is not ready to be considered including into osC..

I'm just trying to get some benchmarks, to see if I am on the right track with this approach..

If I get back some favourable benchmark results I'll finish it, tidy up the code and get some more testing done, after that I'll try and get it on the radar for the core team..

So far I do see some interest, I am logging some downloads of the code, but I have only one person promising to post some results to the thread. Which is kinda disappointing..

Cheers,.

Rob..

Comment #18

I owe everyone an apology.

I am a moron, I am sorry.

So there, with that out of the way: The last tarball some of you downloaded was doing everything it should do except reporting the benchmark figures, unless you turned on sql query logging. :oops:.

To make up for this stupidity I have uploaded a new version of the code and have setup a demonstration server online..

So, for the downloads.

The new code:.

Http://www.cryp2nite..._catalog.tar.gz.

Previous version:.

Http://www.cryp2nite...alog-0.2.tar.gz.

This code is the same (except for the SQL connection settings) as the demo links below..

Demo links:.

Original code (Today's CVS).

Http://www.cryp2nite...emo/catalog_ori.

New code.

Http://www.cryp2nite...emo/catalog_new.

For the performance improvement look at the reported, number of queries and the total time spent doing these queries..

Parse time is probably not a very useful, as I have paid no particular attention to performance for the rendering code and the generated page is showing too much information, but as you can see all required information to construct a decent menu is there..

I hope I can still convince some of you to give it another shot and try the code on their setups..

Cheers,.

Rob.

P.S.: For anyone not downloading the code, there's a README with some instructions on how to compare the two versions of the code. It might be useful because the category box of the new code is not functional and navigation is not possible, it's also avalable online:.

Http://www.cryp2nite...demo/README.TXT.

Most should be pretty obvious though...

Comment #19

I forgot:.

If this version does not work for you the way the demo links do, or you can't get it to work, just let me know and post to the thread..

Just tell me I messed up again, I'm a big boy I can take it..

Cheers,.

Rob..

Comment #20

Your demo times look fairly accurate compared to the limited testing I have done so far.

It is an amazing speed difference.

Now what will it take to make navigation work?..

Comment #21

Thanks for taking the time to look at this..

Great, I am/was hoping someone with a big store to give this code a try and report back..

Could you give me an idea what size store your setup has and maybe some info on your hardware config?.

That is kind of what I expected, I did some (really fast and probably not too accurate) tests on a stock install with maybe 9 extra categories and products nested three levels deep. And the performance gain went up to well over 60% on some pages.

Well, probably for me to finish the code. To do that I would have to be convinced someone is going use this..

But, as I said in an other thread it's of limited use to me as I am not expecting any performance issues for the sites I am likely to setup in the near future..

My thought is that it would have to be included in osC proper, as this is not a change in functionality but a dfiferent aproach for standard osC functonaity..

But I don't know what the right approach is. What I.

Do.

Know that I haven't been around long enough to earn enough brownie points to have my claim taken at face value.

That's why I am trying to get some favourable performance numbers, to make sure I am not wasting everybodies time. And then to ask someone in the core team to have a look at this thread and ask for their thoughts..

Cheers,.

Rob..

Comment #22

Your in luck.

I decided to give it one last try and finish some code to do the layout. It's not the most efficient way of doing it, but it works..

Seeing as I have logged over 50 downloads of the code, I take it there are people interested in this code. Still there are nearly no responses in this thread. The only feedback I get in private messages is along the lines of: "The menus look all messed up in your new code". So I hope this helps..

I am still looking for some people to do their own benchmarks with this code. Especially if you have a shop with a large number of categories and products I would be.

Very.

Interested in the results on your setup. If you decide to download this and cannot get it to work, let me know and I'll do what I can to makke it work..

Please let me know if anyone is interested in this code, because as I said before, I probably won't benefit from it my self all that much in the shops I am to set up any time soon..

If noone wants it, or thinks it's a bad idea to begin with, that's fine with me, I'll just give it a rest then..

As usual:.

Code download.

New version:.

Http://www.cryp2nite..._catalog.tar.gz.

Previous version:.

Http://www.cryp2nite...alog-0.3.tar.gz.

Demo links:.

Original code:.

Http://www.cryp2nite...emo/catalog_ori.

Improved code:.

Http://www.cryp2nite...emo/catalog_new.

Benchmark scores at the bottom of each page, be sure to browse to some of the categories for greater improvements..

Have fun,.

Rob..

Comment #23

Well since there's new code, I had to do some new benchmarks:.

The results below are for a stock install of osC on a clean database..

Siege runs concurrent requests to the site, with urls randomly picked from a list of URL's..

All tests were run for 120 seconds..

Before each set of runs both apache and mysql were stopped and started again..

The tests were run on the demo server from the previous post..

Attention:.

These times are.

Overall page performance results.

, not just the improved parts, so this gives a pretty good idea of the overall impact of the improvements on osC performance..

With SHOW_COUNTS = 'true'.

Both connection rate and response times improved consistently by.

13-15%.

..

I was surprised by the numbers here, I didn't expect it to show so well on a small database..

With SHOW_COUNTS = 'false'.

Both connection rate and response times improved marginally consistently.

2-3%.

..

Even with a larger database the difference will not be too great here, there are simply less queries to be done away with..

And because a picture says more than a thousand words, these numbers looks something like this with SHOW_COUNTS = 'true':.

Notes.

1. I tried testing this on a development machine, but was unable to get results for 50 connections for the old code because the webserver went unresponsive..

2. I still would like to see how this performs on a database with more catageories and products, because that is were I am expecting the real peformance gain..

3. The layout code isn't very good wrt performance, I'm convinced I can gain another couple percentage points there due to unnesessary copying of and looping over large arrays..

Hope you guys like it,.

Rob..

Comment #24

Just tested this on my internal server. Just a couple of quick checks..

Below is the info from the pages I tested (with a bit of info of what that page contains)..

Show Category Counts = false.

Sessions = mysql.

Will try this again later with differant Show Category Counts = true..

Also, I have made MAJOR changes to my tables, so my iPage site is not standard by anymeans shape or form..

Anyways here are the results from 8 differant pages:.

Index.php.

OLD CODE.

Parse Time: 2.543 s.

Queries (count/total time/avg time):.

53.

2.296159863472 s.

0.043323771008905 s.

NEW CODE.

Parse Time: 2.518 s.

Queries (count/total time/avg time):.

44.

2.3764452934265 s.

0.054010120305148 s.

Product_info.php/products_id/16633 (just a random product I picked).

OLD CODE.

Parse Time: 0.171 s.

Queries (count/total time/avg time):.

56.

0.033632636070251 s.

0.00060058278696878 s.

NEW CODE.

Parse Time: 0.256 s.

Queries (count/total time/avg time):.

39.

0.12348258495331 s.

0.0031662201270079 s.

Index.php/cPath/21 (cat with no products).

OLD CODE.

Parse Time: 1.954 s.

Queries (count/total time/avg time):.

43.

1.7235897779465 s.

0.040083483208057 s.

NEW CODE.

Parse Time: 1.913 s.

Queries (count/total time/avg time):.

32.

1.7882061004639 s.

0.055881440639496 s.

Shopping_cart.php (adding product).

OLD CODE.

Parse Time: 1.859 s.

Queries (count/total time/avg time):.

46.

1.7272621393204 s.

0.037549176941747 s.

NEW CODE.

Parse Time: 1.854 s.

Queries (count/total time/avg time):.

36.

1.722837805748 s.

0.047856605715222 s.

Index.php/cPath/22 (four sub cats no products).

OLD CODE.

Parse Time: 2.006 s.

Queries (count/total time/avg time):.

75.

1.7455425262451 s.

0.023273900349935 s.

NEW CODE.

Parse Time: 2.014 s.

Queries (count/total time/avg time):.

61.

1.760552406311 s.

0.028861514857558 s.

Index.php/cPath/22_32 (one sub cat no products).

OLD CODE.

Parse Time: 2.372 s.

Queries (count/total time/avg time):.

72.

2.2015860080719 s.

0.030577583445443 s.

NEW CODE.

Parse Time: 2.298 s.

Queries (count/total time/avg time):.

56.

2.04907310009 s.

0.036590591073036 s.

Index.php/cPath/22_32_54 (no sub cats 7074 products).

OLD CODE.

Parse Time: 2.788 s.

Queries (count/total time/avg time):.

73.

2.4281200170517 s.

0.033261918041804 s.

NEW CODE.

Parse Time: 2.883 s.

Queries (count/total time/avg time):.

56.

2.6896396875381 s.

0.04802928013461 s.

Index.php/cPath/22_32_54/sort/2a/page/6 (items 101 - 120).

OLD CODE.

Parse Time: 2.807 s.

Queries (count/total time/avg time):.

73.

2.503071308136 s.

0.034288648056657 s.

NEW CODE.

Parse Time: 2.796 s.

Queries (count/total time/avg time):.

56.

2.5014184713364 s.

0.044668186988149 s.

Hope this helps out, will post again with the results from other tests..

Also, sorry this is so long, but wanted the info to be easily readable..

Nicky..

Comment #25

First of all:.

Thank you for takeing the time!.

If you get a chance to test with category counts enabled and post hrere, could you include some machine specs? And maybe some info on the no of categories/ products?.

I am somewhat surprised the total query time is worse (allthough I don't expect too much of a performance gain with counts disabled)..

I know the queries are a little more complex, but there quite a few less of them..

Thanks,.

Rob..

Comment #26

OK, ran it with Show Category Counts = true..

Site evironment firstly though:.

Apache 1.3.26.

PHP 4.2.3.

MySQL 3.23.39.

Mod_ssl 2.8.10.

OpenSSL 0.9.6g.

Red Hat Linux 7.1 (Seawolf).

In this test environment I have 16,637 products residing inside 38 categories..

Same 8 pages tested as before:.

Index.php.

OLD PAGE.

Parse Time: 3.065 s.

Queries (count/total time/avg time):.

129.

2.7980867624283 s.

0.021690595057584 s.

NEWPAGE.

Parse Time: 2.959 s.

Queries (count/total time/avg time):.

62.

2.8077870607376 s.

0.045286888076413 s.

Product_info.php/products_id/16633 (just a random product I picked).

OLDPAGE.

Parse Time: 0.953 s.

Queries (count/total time/avg time):.

148.

0.79794108867645 s.

0.0053914938424085 s.

NEWPAGE.

Parse Time: 0.667 s.

Queries (count/total time/avg time):.

57.

0.42388212680817 s.

0.0074365285404941 s.

Index.php/cPath/21 (cat with no products).

OLD PAGE.

Parse Time: 2.476 s.

Queries (count/total time/avg time):.

121.

2.2291589975357 s.

0.018422801632526 s.

NEW PAGE.

Parse Time: 2.346 s.

Queries (count/total time/avg time):.

50.

2.1092392206192 s.

0.042184784412384 s.

Shopping_cart.php (adding product).

OLD CODE.

Parse Time: 2.378 s.

Queries (count/total time/avg time):.

121.

2.2336277961731 s.

0.01845973385267 s.

NEW CODE.

Parse Time: 2.255 s.

Queries (count/total time/avg time):.

61.

2.1152994632721 s.

0.03467704038151 s.

Index.php/cPath/22 (four sub cats).

OLD CODE.

Parse Time: 2.918 s.

Queries (count/total time/avg time):.

163.

2.6479508876801 s.

0.01624509747043 s.

NEW CODE.

Parse Time: 2.381 s.

Queries (count/total time/avg time):.

79.

2.2278785705566 s.

0.028200994564008 s.

Index.php/cPath/22_32 (one sub cat).

OLD CODE.

Parse Time: 3.454 s.

Queries (count/total time/avg time):.

162.

3.2893352508545 s.

0.020304538585522 s.

NEW CODE.

Parse Time: 2.699 s.

Queries (count/total time/avg time):.

74.

2.4421941041946 s.

0.033002623029657 s.

Index.php/cPath/22_32_54 (7074 products).

OLD CODE.

Parse Time: 3.823 s.

Queries (count/total time/avg time):.

163.

3.5041168928146 s.

0.02149764964917 s.

NEW CODE.

Parse Time: 3.173 s.

Queries (count/total time/avg time):.

74.

2.8674243688583 s.

0.038748977957545 s.

Index.php/cPath/22_32_54/sort/2a/page/6 (items 101 - 120).

OLD CODE.

Parse Time: 3.948 s.

Queries (count/total time/avg time):.

163.

3.5201981067657 s.

0.021596307403471 s.

NEW CODE.

Parse Time: 3.196 s.

Queries (count/total time/avg time):.

74.

2.7829014062881 s.

0.037606775760651 s.

Hope this helps you out. Great job!.

Nicky..

Comment #27

Thanks a lot, if your interested in your own results in a somewhat more easily digestible format, go to.

Http://www.cryp2nite.nl/oscbench/.

For the data and pretty pictures..

I am still a bit puzzled about the HSOW_COUNTS='false' results, they seem to be all over the place:(.

I would expect the results to be more consistent..

Anyway, the highlights of your data:.

Category Pages.

5.25 - 21%.

Faster parse time!.

Average performance increase:.

19.08%.

Product Page.

30.01%.

Faster parse time!.

This is where most visitors spend most of the time in the shop, so this is excellent news!.

If any of the osC devs (or anyone else knowledgeable ) read this:.

- Is there any way this can be incorporated into osC?.

- Or do you think this should go in a contribution?.

- Should I file as an RFE in the bug reporter?.

Cheers,.

Rob..

Comment #28

I'am interesting to make my iPage website more fast, and also to know how to develop a good database structure and learn everything..

I downloaded the file and will install it soon..

Regards,.

Zaenal..

Comment #29

I've tested those two sites a few times now, and for me, the "catalog_ori" variant is always faster, parses faster, does queries faster, even though it has about twice the numer of quaries to do. I tried it with both Mozilla and IE browser, the result being the same. :?.

Greets,.

Peter..

Comment #30

Also tested demo links and got the same results as Peter, with the Catalog_Ori iPage site being consistantly faster even though it is making 40 or so more queries. :?.

Not sure what's going on there....

Tony..

Comment #31

Hmm,...

I didn't get a topic reply notification, so I hadn't seen your replies before..

I must say I'm surprised the new code is slower at the moment, but I checked and you are right..

The strange thing is that I didn't make these numbers in the rest of the thread up, so something must cause it to deteriorate..

Anyhow, I have given up on it for now as there doesn't seem to be much interest in this. If interest picks up again or I run out of other things to do I might revisit this..

There are some things that could be done to my new code that would speed it up a bit more, the rendering code is pretty inefficient right now. I could also look into why the numbers have deteriorated over the past week. That is puzzling..

Cheers,.

Rob..

Comment #32

I'm not entirely sure what the proposal here is, but I got a substantial performance gain on the categories box just by adding an index to osc_categories.x_categories_parent_id.

This turned an unusably slow shop with 100+ categories into a shop with the same speed as 10 categories..

An index on osc_products_to_categories.categories_id (can't remember if that is one I added, or is part of the base install) also helps performance..

Jason..

Comment #33

Hi,.

I have litle TIP & TRICK for infobox categories here:.

Http://forums.oscomm...showtopic=59402.

I think it's more fast and simple..

Best,.

Zaenal..

Comment #34

This looks promissing.....

Not sure if this is an appropriate thread, but I have a customer catalog that contains literaly THOUSANDS of Category - Subcategories with over 15,000 products..

It appears that the categories block is attempting to load every one of the thousands of categoris into memory and of course is timeing out..

I have searched the threads looking for someone with a similar issue and this is by far the closest.

Any suggestions.....

Great Product with Great Contributions... Keep it Up!..

Comment #35

Put a limit on how many categories show (perhaps only show the most clicked...but that would take some time to make)..

Consider adding more levels of categories so your products have a tighter niche..

Provide a search for categories.

To name off a few...

Comment #36

Admin > Configuration > My Store > Display Product Counts; set to false. It should only load the top-level categories and those opened by browsing without that..

Hth,.

Matt..

Comment #37

Seeing as there's not yet too many shows of interest in my proposal, I thought I'd get some code done and do some quick benchmarking..

And I've thrown in a catchy title this time, just for good measure :-).

I have reworked the database parts of the category box to get some these benchmarks done..

I hope these ideas find their way into osC as I think it would help tremendously with performance. If this is not the right channel to get these ideas across to the dev team please let me know where I should post this instead..

I expect there are similar gains to be made with several other parts of the code, there are more places where there are queries inside loops..

Ok, on to the benchmarks, the first results look.

Really.

Promising:.

All results in seconds are averages over 10 runs, using the same database and server, doing requests for.

Http://osc-cvs.denet...dex.php?cPath=1.

On an (almost) stock osC install. With default number of categories..

With SHOW_COUNTS 'true':.

Avg parse time*:.

Old code:  .9087.

New code:  .6598  (27% faster).

Avg query time**:.

Old code:  .3445.

New code:  .1907***    ( 45% faster ).

With SHOW_COUNTS 'false':.

Avg parse time:.

Old code:  .6921.

New code:  .6159  (11% faster).

Avg query time**:.

Old code:  .2043.

New code:  .1755  (14% faster).

The code literally reduces the number of database queries with dozens per page. This is especially true when SHOW_COUNTS is enabled. As you can see the new code is faster (In terms of query time) with SHOW_COUNTS enabled than the old code was without!.

Keep in mind that these results where for a default install of osC. (I have been playing around with it, so it's not a complete virgin database, there are some reviews and purchases done).

However if you have more categories in your database the performance gain will most likely be even bigger..

The display code for these results is really sloppy, I just wanted to hack something into osC to get the database timings. So take the overall timing benchmarks with a big grain of salt, I have not tried to implement this code efficiently, or functionally equivalent to the orignal code..

P.S.:.

For those of you who read my previous post, I made a mistake there..

The number of queries for the category box are:.

SHOW_COUNTS = 'true'.

- one query per category that has subcategories..

SHOW_COUNTS = 'false'.

- one query per displayed category contaiing subcategories..

Rob.

=======.

The usual disclaimers apply; These are results on my box not yours, using my data not yours!.

* These are of limited value I did not finish the layout code, the code currently constructs a multidimensional array with the category info..

** These are measured by timing each tep_db_query(). So this is.

Excluding.

Any time setting up the connections..

*** Sadly there was one .22 result the others were all in the .18 -.19 range..

Comment #38

I'm looking for people willing to test/ benchmark my changes on their setup..

What would be extra useful is testing on actual store data..

I've uploaded an archive with instructions to:.

Http://www.cryp2nite..._catalog.tar.gz.

This is also in the included README, but to avoid confusion:.

DO NOT use this on your production site!.

It is proof-of-concept code, it will make your iPage site look really, really bad!.

Any feedback greatly appreciated..

Rob..

Comment #39


This question was taken from a support group/message board and re-posted here so others can learn from it.