Re: [PERFORM] Sun performance - Major discovery!
On Wed, Oct 08, 2003 at 08:36:56AM -0400, Jeff wrote: > > So here's the results using my load tester (single connection per beater, > repeats the query 1000 times with different input each time (we'll get > ~20k rows back), the query is a common query around here. My worry about this test is that it gives us precious little knowledge about concurrent connection slowness, which is where I find the most significant problems. When we tried a Sunsoft cc vs gcc 2.95 on Sol 7 about 1 1/2 years ago, we found more or less no difference once we added more than 5 connections (and we always have more than 5 connections). It might be worth trying again, though, since we moved to Sol 8. Thanks for the result. -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] Sun performance - Major discovery!
On Wed, 2003-10-08 at 08:36, Jeff wrote: > So here's the results using my load tester (single connection per beater, > repeats the query 1000 times with different input each time (we'll get > ~20k rows back), the query is a common query around here. What is the query? > Linux - 1x - 35 seconds, 20x - 180 seconds "20x" means 20 concurrent testing processes, right? > Sun - gcc - 1x 60 seconds 20x 245 seconds > Sun - sunsoft defaults - 1x 52 seonds 20x [similar to gcc most likely] > Sun - sunsoft -fast - 1x 28 seconds 20x 164 seconds Interesting (and surprising that the performance differential is that large, to me at least). Can you tell if the performance gain comes from an improvement in a particular subsystem? (i.e. could you get a profile of Sun/gcc and compare it with Sun/sunsoft). -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] Sun performance - Major discovery!
On Wed, 8 Oct 2003, Andrew Sullivan wrote: > My worry about this test is that it gives us precious little > knowledge about concurrent connection slowness, which is where I find > the most significant problems. When we tried a Sunsoft cc vs gcc 2.95 > on Sol 7 about 1 1/2 years ago, we found more or less no difference > once we added more than 5 connections (and we always have more than 5 > connections). It might be worth trying again, though, since we moved > to Sol 8. > The 20x column are the results when I fired up 20 beater concurrently. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] Sun performance - Major discovery!
On Wed, 8 Oct 2003, Neil Conway wrote: > What is the query? > It retrieves an index listing for our boards. The boards are flat (not threaded) and messages are numbered starting at 1 for each board. If you pass in 0 for the start_from it assumes the latest 60. And it should be noted - in some cases some boards have nearly 2M posts. Index on board_name, number. I cannot give out too too much stuff ;) create or replace function get_index2(integer, varchar, varchar) returns setof snippet as ' DECLARE p_start alias for $1; p_board alias for $2; v_start integer; v_num integer; v_body text; v_sender varchar(35); v_time timestamptz; v_finish integer; v_row record; v_ret snippet; BEGIN v_start := p_start; if v_start = 0 then select * into v_start from get_high_msg(p_board); v_start := v_start - 59; end if; v_finish := v_start + 60; for v_row in select number, substr(body, 0, 50) as snip, member_handle, timestamp from posts where board_name = p_board and number >= v_start and number < v_finish order by number desc LOOP return next v_row; END LOOP; return; END; ' language 'plpgsql'; > Interesting (and surprising that the performance differential is that > large, to me at least). Can you tell if the performance gain comes from > an improvement in a particular subsystem? (i.e. could you get a profile > of Sun/gcc and compare it with Sun/sunsoft). > I'll get these later today. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PERFORM] Sun performance - Major discovery!
On Wed, 8 Oct 2003, Neil Conway wrote: > Interesting (and surprising that the performance differential is that > large, to me at least). Can you tell if the performance gain comes from > an improvement in a particular subsystem? (i.e. could you get a profile > of Sun/gcc and compare it with Sun/sunsoft). > Yeah - like I expected it was able to generate much better code for _bt_checkkeys which was the #1 function in gcc on both sun & linux. and as you can see, suncc was just able to generate much nicer code. I'd look at the assembler output but that won't be useful since I am very unfamiliar with the [ultra]sparc instruction set.. Here's the prof and gprof output for the latest run: GCC: % cumulative self self total time seconds secondscalls ms/call ms/call name 31.52 19.4419.44 internal_mcount 20.28 31.9512.51 8199466 0.00 0.00 _bt_checkkeys 5.61 35.41 3.46 8197422 0.00 0.00 _bt_step 5.01 38.50 3.09 24738620 0.00 0.00 FunctionCall2 3.00 40.35 1.85 8194186 0.00 0.00 varchareq 2.61 41.96 1.6124309 0.07 0.28 _bt_next 2.42 43.45 1.49 1003 1.49 1.51 AtEOXact_Buffers 2.37 44.91 1.4612642 0.12 0.12 _read 2.33 46.35 1.44 16517771 0.00 0.00 pg_detoast_datum 2.08 47.63 1.28 8193186 0.00 0.00 int4lt 1.35 48.46 0.83 8237204 0.00 0.00 BufferGetBlockNumber 1.35 49.29 0.83 8193888 0.00 0.00 int4ge 1.35 50.12 0.83 _mcount SunCC -pg -fast. %Time Seconds Cumsecs #Calls msec/call Name 23.24.274.27108922056 0. _mcount 20.73.828.09 8304052 0.0005 _bt_checkkeys 13.72.53 10.6225054788 0.0001 FunctionCall2 5.10.94 11.56 24002 0.0392 _bt_next 4.40.81 12.37 8301867 0.0001 _bt_step 3.40.63 13.00 8298219 0.0001 varchareq 2.70.50 13.5016726855 0. pg_detoast_datum 2.40.45 13.95 8342464 0.0001 BufferGetBlockNumber 2.40.44 14.39 8297941 0.0001 int4ge 2.20.41 14.801003 0.409 AtEOXact_Buffers 2.00.37 15.17 4220349 0.0001 lc_collate_is_c 2.00.37 15.54 8297219 0. int4lt 1.60.29 15.83 26537 0.0109 AllocSetContextCreate 0.90.16 15.991887 0.085 pglz_decompress 0.70.13 16.12 159966 0.0008 nocachegetattr 0.70.13 16.25 4220349 0. varstr_cmp 0.60.11 16.36 937576 0.0001 MemoryContextAlloc 0.50.09 16.45 150453 0.0006 hash_search > -Neil > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PERFORM] Sun performance - Major discovery!
On Wed, 2003-10-08 at 10:48, Andrew Sullivan wrote: > My worry about this test is that it gives us precious little > knowledge about concurrent connection slowness, which is where I find > the most significant problems. As Jeff points out, the second set of results is for 20 concurrent connections. Note that the advantage sunsoft cc has over gcc decreases as the number of connections increases (which makes sense, as the 20x workload is likely to be more I/O bound). -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
