Menu
▾
▴
openwebwork-devel — WeBWorK development discussion
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(16) |
Nov
(10) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(34) |
Feb
(12) |
Mar
(21) |
Apr
|
May
(5) |
Jun
(13) |
Jul
(50) |
Aug
(62) |
Sep
(72) |
Oct
(17) |
Nov
(16) |
Dec
(19) |
| 2006 |
Jan
(26) |
Feb
(9) |
Mar
|
Apr
(8) |
May
(5) |
Jun
(7) |
Jul
(21) |
Aug
(33) |
Sep
(17) |
Oct
(4) |
Nov
(9) |
Dec
|
| 2007 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(6) |
Jun
(16) |
Jul
(8) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(2) |
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(11) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2016 |
Jan
(4) |
Feb
(4) |
Mar
(3) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: John J. <jj...@as...> - 2005-03-10 19:07:29
|
Hi, In a previous e-mail I had found that the slowdown was due to case-sensitivity in the mysql index. The index is not case sensitive, so if you force key elements to treated as case sensitive, then the index is ignored and the whole thing slows to a crawl with big databases. Attached is a version of lib/WeBWorK/DB/Schema/SQL.pm which tries to adjust for this. If you are making a deletion of a database record, or putting something into the database, then those calls have to use case sensitive key elements, so they will remain slow. For select statements, the call can be not case sensitive, and then we filter out the records which we really want. I have tested this, but it would be better if other people tested it too. Unlike changes to other files, an error here can mess up an existing course. I thought about other ways to handle this. One I mentioned before was to try to change the data type of the key fields so that the indexing might end up case sensitive. I haven't found a way to do that yet. If the fact that inserting and deleting information from the database is still slow is a problem, then another possibility would be to add a unique numeric key to each table. Then when you want to delete rows from a table, you select (case insensitively), pick out the ones which match your favorite key fields (including case), then use the unique id number for those rows in the actual deletion statement. A similar strategy might work for put type statements. John |
|
From: John J. <jj...@as...> - 2005-03-04 05:55:25
|
Hi all, I was looking at mysql speed today during set assignment. It was slowing down mainly by having lots of calls asking if items exist in the database. So, I looked at the indexing again and I think that is where the problem lies after all. There are enough indexes being kept in mysql, but I don't think the queries get to use them. Because of another bug, the mysql select commands have the modifier "binary" added when specifying the key information (e.g., the set_id, etc.). This made that information checked in a case sensitive way. The problem is that the indexing in mysql seems to be case insensitive. So, when we try to look something up in mysql specifying case sensitive matches, I think it ignores the index and walkd linearly through all of the records. The bigger the course, the longer this takes, and it of course, will get worse. If you want to test this theory at home, login to your server (in a unix shell). Then connect to mysql (e.g., mysql -uroot -p). Then, do something like this: > mysql> use webwork; > Database changed > mysql> select count(*) from Jones_MAT_117_Spring_2005_problem_user > where user_id="jjones" and set_id="Homework_3" and problem_id="2"; > +----------+ > | COUNT(*) | > +----------+ > | 1 | > +----------+ > 1 row in set (0.00 sec) > > mysql> select count(*) from Jones_MAT_117_Spring_2005_problem_user > where BINARY user_id="jjones" and BINARY set_id="Homework_3" and > BINARY problem_id="2"; > +----------+ > | COUNT(*) | > +----------+ > | 1 | > +----------+ > 1 row in set (0.08 sec) The same query, but using the binary modifier goes from ~ 0 secs to 0.08 secs. I looked at the mysql documentation for the create index command, and did not see a way of specifying the entries so that they would be treated as binary. Maybe if the original database types where binary (if that is possible), it would work. Alternatively, webwork could remove the binary modifier, get its result, and then sift out the ones which match in a case sensitive way. I will look at doing that when I have a chance. All changes are probably just to the file DB/Schema/SQL.pm, which is nice. John Arnold Pizer wrote: > At 10:43 PM 3/2/2005, Sam Hathaway wrote: > >> \On Mar 2, 2005, at 10:20 PM, Arnold Pizer wrote: >> >>> At 09:45 PM 3/2/2005, Sam Hathaway wrote: >>> >>>> On Mar 2, 2005, at 10:35 AM, Arnold Pizer wrote: >>>> >>>>> My students in MTH 162 are seeing a significant slowdown in >>>>> WeBWorK this semester and I'm not sure what is going on. I'm >>>>> wondering if any of you have seen similar things or if the >>>>> symptoms bring to mind what the problem might be. >>>> >>>> >>>> If someone's feeling ambitious, they could write a custom version >>>> of DB.pm that makes SQL calls directly. I think we could get some >>>> savings if we avoided the "Schema" abstraction. >>>> -sam >>> >>> >>> Hi Sam, >>> >>> The slow downs I'm seeing are significant --- e.g. 40 times slower >>> than what we are used to. Could the "Schema" abstraction have that >>> great an overhead? >> >> >> It can't account for all of the slowdown, but I think there's room >> for significant improvement. I'll take a closer look once devel is >> back up. >> -sam > > > Thanks, > > Arnie > > >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> OpenWeBWorK-Devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel > > > > Prof. Arnold K. Pizer > Dept. of Mathematics > University of Rochester > Rochester, NY 14627 > (585) 275-7767 > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > OpenWeBWorK-Devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openwebwork-devel |
|
From: Michael G. <ga...@ma...> - 2005-03-03 12:53:24
|
On Mar 2, 2005, at 11:33 PM, Michael Gage wrote: > I also don't understand why the mth162 times were up by a factor of 40 > while the other courses were only up by a factor of 10 or less? What > could account for that difference? > I've thought of one possibility. The tables for mth162 are larger, since it is a bigger class. If we missed instituting an index in mth162, say in the user-problem table, then this might explain why the server would take more time to respond to a request from a large class member as opposed to a small class member. We might not notice the difference when there is no load. Take care, Mike |
|
From: Sam H. <sh...@ma...> - 2005-03-03 06:30:36
|
On Mar 2, 2005, at 10:35 AM, Arnold Pizer wrote: > My students in MTH 162 are seeing a significant slowdown in WeBWorK > this semester and I'm not sure what is going on. I'm wondering if any > of you have seen similar things or if the symptoms bring to mind what > the problem might be. If someone's feeling ambitious, they could write a custom version of DB.pm that makes SQL calls directly. I think we could get some savings if we avoided the "Schema" abstraction. -sam |
|
From: Arnold P. <ap...@ma...> - 2005-03-03 03:59:59
|
At 09:45 PM 3/2/2005, Sam Hathaway wrote: >On Mar 2, 2005, at 10:35 AM, Arnold Pizer wrote: > >>My students in MTH 162 are seeing a significant slowdown in WeBWorK this >>semester and I'm not sure what is going on. I'm wondering if any of you >>have seen similar things or if the symptoms bring to mind what the >>problem might be. > >If someone's feeling ambitious, they could write a custom version of DB.pm >that makes SQL calls directly. I think we could get some savings if we >avoided the "Schema" abstraction. >-sam Hi Sam, The slow downs I'm seeing are significant --- e.g. 40 times slower than what we are used to. Could the "Schema" abstraction have that great an overhead? Arnie Prof. Arnold K. Pizer Dept. of Mathematics University of Rochester Rochester, NY 14627 (585) 275-7767 |
|
From: Arnold P. <ap...@ma...> - 2005-03-03 03:50:32
|
At 10:43 PM 3/2/2005, Sam Hathaway wrote: >\On Mar 2, 2005, at 10:20 PM, Arnold Pizer wrote: > >>At 09:45 PM 3/2/2005, Sam Hathaway wrote: >>>On Mar 2, 2005, at 10:35 AM, Arnold Pizer wrote: >>> >>>>My students in MTH 162 are seeing a significant slowdown in WeBWorK >>>>this semester and I'm not sure what is going on. I'm wondering if any >>>>of you have seen similar things or if the symptoms bring to mind what >>>>the problem might be. >>> >>>If someone's feeling ambitious, they could write a custom version of >>>DB.pm that makes SQL calls directly. I think we could get some savings >>>if we avoided the "Schema" abstraction. >>>-sam >> >>Hi Sam, >> >>The slow downs I'm seeing are significant --- e.g. 40 times slower than >>what we are used to. Could the "Schema" abstraction have that great an >>overhead? > >It can't account for all of the slowdown, but I think there's room for >significant improvement. I'll take a closer look once devel is back up. >-sam Thanks, Arnie >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >OpenWeBWorK-Devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openwebwork-devel Prof. Arnold K. Pizer Dept. of Mathematics University of Rochester Rochester, NY 14627 (585) 275-7767 |
|
From: Sam H. <sh...@ma...> - 2005-03-03 03:44:04
|
\On Mar 2, 2005, at 10:20 PM, Arnold Pizer wrote: > At 09:45 PM 3/2/2005, Sam Hathaway wrote: >> On Mar 2, 2005, at 10:35 AM, Arnold Pizer wrote: >> >>> My students in MTH 162 are seeing a significant slowdown in WeBWorK >>> this semester and I'm not sure what is going on. I'm wondering if >>> any of you have seen similar things or if the symptoms bring to mind >>> what the problem might be. >> >> If someone's feeling ambitious, they could write a custom version of >> DB.pm that makes SQL calls directly. I think we could get some >> savings if we avoided the "Schema" abstraction. >> -sam > > Hi Sam, > > The slow downs I'm seeing are significant --- e.g. 40 times slower > than what we are used to. Could the "Schema" abstraction have that > great an overhead? It can't account for all of the slowdown, but I think there's room for significant improvement. I'll take a closer look once devel is back up. -sam |
|
From: John J. <jj...@as...> - 2005-03-02 18:48:43
|
After more looking, I recant my guess about table indexing. After figuring out how to have mysql report the indexing it is using, I found that webwork was putting in all the indexes I used last semester (and a few more). John Arnold Pizer wrote: > Hi John et al, > > My students in MTH 162 are seeing a significant slowdown in WeBWorK > this semester and I'm not sure what is going on. I'm wondering if any > of you have seen similar things or if the symptoms bring to mind what > the problem might be. What my students report is that "WeBWorK has > been getting progressively slower every week". I copied below a bit > of the timing log from last Sunday night (162 hw is due early Monday > morning) and it shows that 162 requests are taking 30 or 40 seconds! > The fewer number of requests form other courses were generally under10 > seconds. MTH 162 is the largest course this semester with about 275 > students. Also this semester all courses are using sql_single. Last > semester all but one course used gdbm (with WeBWorK 2) and 97% of > requests took 0 or 1 second. Also the fall courses are larger than > the spring courses. In particular, the largest course last semester > (161) was larger than 162 is now and it used gdbm. Early in the > semester we had a problem with the mysql log filling up the var > partition but that doesn't seem to be the problem now. 162 is using > exactly the same problem sets that have been used for the past 2 > years, so that's not the problem. Also the fact that students report > the problem is getting worst every week seems to rule out server > problems. I assume the table size for mth162 is increasing every week > --- could this be relevant? What else could cause the problem to get > progressively worst? When I looked at the output from top, I saw that > the load was about 1 (i.e. not excessive), mysql was taking almost 100 > % of the cpu, the http processes were taking very little cpu, and no > process was using a lot of memory (this is from memory --- I didn't > make a copy of the out put). > > If we are seeing this problem at Rochester, it hard to believe others > will not see it in the future. If others are not seeing it yet, > maybe it has to do with how mysql is configured here. Are we and > others using a "standard" mysql configuration? > > Below is a bit of the timing log. > > Arnie > > > [Sun Feb 27 21:17:47 2005] 71659 1109557067 - [/webwork2/mth162/6/3/] > [runTime = 46.0 sec sql_single] > [Sun Feb 27 21:17:50 2005] 71702 1109557070 - [/webwork2/mth162/6/2/] > [runTime = 17.0 sec sql_single] > [Sun Feb 27 21:17:53 2005] 71592 1109557073 - [/webwork2/mth161/5/] > [runTime = 5.0 sec sql_single] > [Sun Feb 27 21:17:55 2005] 71659 1109557075 - [/webwork2/mth161/6/14/] > [runTime = 3.0 sec sql_single] > [Sun Feb 27 21:17:56 2005] 71564 1109557076 - [/webwork2/mth162/6/3/] > [runTime = 46.0 sec sql_single] > [Sun Feb 27 21:17:56 2005] 70570 1109557076 - [/webwork2/mth162/6/5/] > [runTime = 49.0 sec sql_single] > [Sun Feb 27 21:17:57 2005] 71592 1109557077 - [/webwork2/mth161/5/8/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:17:57 2005] 70937 1109557077 - [/webwork2/mth162/6/3/] > [runTime = 49.0 sec sql_single] > [Sun Feb 27 21:18:03 2005] 71564 1109557083 - [/webwork2/mth165/7/14/] > [runTime = 3.0 sec sql_single] > [Sun Feb 27 21:18:08 2005] 71659 1109557088 - [/webwork2/ast105/04/9/] > [runTime = 1.0 sec sql_single] > [Sun Feb 27 21:18:11 2005] 70571 1109557091 - [/webwork2/mth162/6/1/] > [runTime = 34.0 sec sql_single] > [Sun Feb 27 21:18:11 2005] 71433 1109557091 - [/webwork2/mth162/6/5/] > [runTime = 36.0 sec sql_single] > [Sun Feb 27 21:18:15 2005] 71702 1109557095 - > [/webwork2/ast105/logout/] [runTime = 1.0 sec sql_single] > [Sun Feb 27 21:18:15 2005] 71628 1109557095 - [/webwork2/mth162/6/3/] > [runTime = 21.0 sec sql_single] > [Sun Feb 27 21:18:16 2005] 71137 1109557096 - [/webwork2/mth162/6/8/] > [runTime = 47.0 sec sql_single] > [Sun Feb 27 21:18:22 2005] 71666 1109557102 - [/webwork2/mth162/6/2/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:18:22 2005] 71479 1109557102 - [/webwork2/mth162/6/3/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:18:26 2005] 71433 1109557106 - [/webwork2/mth162/6/7/] > [runTime = 14.0 sec sql_single] > [Sun Feb 27 21:18:28 2005] 71239 1109557108 - [/webwork2/mth162/6/7/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:18:28 2005] 71161 1109557108 - [/webwork2/mth162/6/3/] > [runTime = 30.0 sec sql_single] > [Sun Feb 27 21:18:38 2005] 71628 1109557118 - [/webwork2/mth162/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:18:38 2005] 71258 1109557118 - [/webwork2/mth162/6/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:18:42 2005] 70570 1109557122 - [/webwork2/mth162/6/3/] > [runTime = 34.0 sec sql_single] > [Sun Feb 27 21:18:45 2005] 71433 1109557125 - [/webwork2/mth165/7/14/] > [runTime = 6.0 sec sql_single] > [Sun Feb 27 21:18:46 2005] 71479 1109557126 - [/webwork2/mth162/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:18:46 2005] 70937 1109557126 - [/webwork2/mth162/6/5/] > [runTime = 37.0 sec sql_single] > [Sun Feb 27 21:18:47 2005] 71659 1109557127 - [/webwork2/mth162/6/6/] > [runTime = 39.0 sec sql_single] > [Sun Feb 27 21:18:48 2005] 70937 1109557128 - [/webwork2/mth142/6/3/] > [runTime = 1.0 sec sql_single] > [Sun Feb 27 21:18:50 2005] 71592 1109557130 - [/webwork2/mth162/6/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:18:51 2005] 71702 1109557131 - [/webwork2/mth162/6/3/] > [runTime = 36.0 sec sql_single] > [Sun Feb 27 21:18:52 2005] 71564 1109557132 - [/webwork2/mth162/6/3/] > [runTime = 37.0 sec sql_single] > [Sun Feb 27 21:18:57 2005] 71479 1109557137 - [/webwork2/mth162/6/3/] > [runTime = 11.0 sec sql_single] > [Sun Feb 27 21:18:58 2005] 71788 1109557138 - [/webwork2/mth162/6/3/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:02 2005] 71592 1109557142 - [/webwork2/mth162/6/6/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:03 2005] 71702 1109557143 - [/webwork2/mth162/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:19:09 2005] 70937 1109557149 - [/webwork2/mth164/09/2/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:13 2005] 71659 1109557153 - [/webwork2/mth162/6/3/] > [runTime = 14.0 sec sql_single] > [Sun Feb 27 21:19:16 2005] 71592 1109557156 - [/webwork2/mth161/6/14/] > [runTime = 2.0 sec sql_single] > [Sun Feb 27 21:19:16 2005] 71239 1109557156 - [/webwork2/mth162/6/7/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:19:20 2005] 71788 1109557160 - [/webwork2/mth162/6/4/] > [runTime = 18.0 sec sql_single] > [Sun Feb 27 21:19:20 2005] 71137 1109557160 - [/webwork2/mth162/6/] > [runTime = 43.0 sec sql_single] > [Sun Feb 27 21:19:21 2005] 71161 1109557161 - [/webwork2/mth162/6/3/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:19:24 2005] 71258 1109557164 - [/webwork2/mth162/6/] > [runTime = 45.0 sec sql_single] > [Sun Feb 27 21:19:26 2005] 71666 1109557166 - [/webwork2/mth162/6/3/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:19:27 2005] 71628 1109557167 - [/webwork2/mth162/6/3/] > [runTime = 37.0 sec sql_single] > [Sun Feb 27 21:19:30 2005] 71702 1109557170 - [/webwork2/mth162/6/3/] > [runTime = 15.0 sec sql_single] > [Sun Feb 27 21:19:31 2005] 71433 1109557171 - [/webwork2/mth162/6/5/] > [runTime = 34.0 sec sql_single] > [Sun Feb 27 21:19:32 2005] 70570 1109557172 - [/webwork2/mth162/6/3/] > [runTime = 38.0 sec sql_single] > [Sun Feb 27 21:19:37 2005] 71258 1109557177 - [/webwork2/mth162/6/6/] > [runTime = 12.0 sec sql_single] > [Sun Feb 27 21:19:37 2005] 71564 1109557177 - [/webwork2/mth162/6/] > [runTime = 45.0 sec sql_single] > [Sun Feb 27 21:19:40 2005] 71788 1109557180 - [/webwork2/mth165/7/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:40 2005] 71479 1109557180 - [/webwork2/mth162/6/3/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:19:42 2005] 70937 1109557182 - [/webwork2/mth142/6/1/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:43 2005] 71666 1109557183 - [/webwork2/mth162/6/4/] > [runTime = 16.0 sec sql_single] > [Sun Feb 27 21:19:55 2005] 71258 1109557195 - [/webwork2/mth165/7/] > [runTime = 6.0 sec sql_single] > [Sun Feb 27 21:19:57 2005] 71666 1109557197 - [/webwork2/mth161/5/8/] > [runTime = 2.0 sec sql_single] > [Sun Feb 27 21:20:06 2005] 71161 1109557206 - [/webwork2/mth162/6/3/] > [runTime = 34.0 sec sql_single] > [Sun Feb 27 21:20:06 2005] 71161 1109557206 - [/webwork2/mth142/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:07 2005] 71137 1109557207 - [/webwork2/mth162/6/3/] > [runTime = 35.0 sec sql_single] > [Sun Feb 27 21:20:08 2005] 71666 1109557208 - [/webwork2/mth162/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:09 2005] 71659 1109557209 - [/webwork2/mth162/6/5/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:20:12 2005] 71592 1109557212 - [/webwork2/mth162/6/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:20:14 2005] 71239 1109557214 - [/webwork2/mth162/6/3/] > [runTime = 46.0 sec sql_single] > [Sun Feb 27 21:20:15 2005] 71564 1109557215 - [/webwork2/mth162/6/6/] > [runTime = 38.0 sec sql_single] > [Sun Feb 27 21:20:17 2005] 71161 1109557217 - [/webwork2/mth142/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:17 2005] 71628 1109557217 - [/webwork2/mth162/6/] > [runTime = 50.0 sec sql_single] > [Sun Feb 27 21:20:18 2005] 70570 1109557218 - [/webwork2/mth162/6/] > [runTime = 45.0 sec sql_single] > [Sun Feb 27 21:20:20 2005] 71788 1109557220 - [/webwork2/mth162/6/2/] > [runTime = 40.0 sec sql_single] > [Sun Feb 27 21:20:24 2005] 71666 1109557224 - [/webwork2/mth162/6/5/] > [runTime = 11.0 sec sql_single] > [Sun Feb 27 21:20:25 2005] 71659 1109557225 - [/webwork2/mth164/09/6/] > [runTime = 4.0 sec sql_single] > [Sun Feb 27 21:20:27 2005] 71137 1109557227 - [/webwork2/mth142/6/3/] > [runTime = 8.0 sec sql_single] > [Sun Feb 27 21:20:27 2005] 71564 1109557227 - [/webwork2/mth162] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:28 2005] 71161 1109557228 - [/webwork2/mth142/6/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:20:31 2005] 71592 1109557231 - [/webwork2/mth162/6/2/] > [runTime = 16.0 sec sql_single] > [Sun Feb 27 21:20:35 2005] 70570 1109557235 - [/webwork2/mth162/6/4/] > [runTime = 15.0 sec sql_single] > [Sun Feb 27 21:20:36 2005] 71161 1109557236 - [/webwork2/mth142/6/4/] > [runTime = 1.0 sec sql_single] > [Sun Feb 27 21:20:36 2005] 71659 1109557236 - > [/webwork2/mth165/logout/] [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:36 2005] 71702 1109557236 - [/webwork2/mth162/6/6/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:20:37 2005] 71258 1109557237 - [/webwork2/mth162/6/3/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:20:38 2005] 71479 1109557238 - [/webwork2/mth162/6/6/] > [runTime = 46.0 sec sql_single] > [Sun Feb 27 21:20:39 2005] 71564 1109557239 - > [/webwork2/mth162/logout/] [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:40 2005] 71433 1109557240 - [/webwork2/mth162/6/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:20:42 2005] 70937 1109557242 - [/webwork2/mth162/6/3/] > [runTime = 47.0 sec sql_single] > [Sun Feb 27 21:20:45 2005] 71592 1109557245 - [/webwork2/mth162/6/4/] > [runTime = 14.0 sec sql_single] > [Sun Feb 27 21:20:49 2005] 71137 1109557249 - [/webwork2/mth162/6/7/] > [runTime = 11.0 sec sql_single] > [Sun Feb 27 21:20:50 2005] 71161 1109557250 - [/webwork2/mth142/6/3/] > [runTime = 3.0 sec sql_single] > [Sun Feb 27 21:20:53 2005] 71659 1109557253 - [/webwork2/mth161/5/2/] > [runTime = 5.0 sec sql_single] > [Sun Feb 27 21:20:55 2005] 71628 1109557255 - [/webwork2/mth162/6/7/] > [runTime = 37.0 sec sql_single] > [Sun Feb 27 21:21:01 2005] 71258 1109557261 - [/webwork2/mth162/6/6/] > [runTime = 12.0 sec sql_single] > [Sun Feb 27 21:21:04 2005] 71788 1109557264 - [/webwork2/mth162/6/8/] > [runTime = 32.0 sec sql_single] > [Sun Feb 27 21:21:06 2005] 71239 1109557266 - [/webwork2/mth162/6/3/] > [runTime = 40.0 sec sql_single] > [Sun Feb 27 21:21:12 2005] 70570 1109557272 - [/webwork2/mth162/6/4/] > [runTime = 31.0 sec sql_single] > [Sun Feb 27 21:21:17 2005] 71666 1109557277 - [/webwork2/mth162/6/8/] > [runTime = 40.0 sec sql_single] > [Sun Feb 27 21:21:18 2005] 71479 1109557278 - [/webwork2/mth162/6/6/] > [runTime = 40.0 sec sql_single] > [Sun Feb 27 21:21:21 2005] 71788 1109557281 - [/webwork2/mth162/6/6/] > [runTime = 12.0 sec sql_single] > [Sun Feb 27 21:21:23 2005] 70937 1109557283 - [/webwork2/mth162/6/4/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:21:29 2005] 71433 1109557289 - [/webwork2/mth162/6/] > [runTime = 48.0 sec sql_single] > [Sun Feb 27 21:21:30 2005] 71702 1109557290 - [/webwork2/mth162/6/6/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:21:32 2005] 70570 1109557292 - [/webwork2/mth161/5/8/] > [runTime = 7.0 sec sql_single] > > > Prof. Arnold K. Pizer > Dept. of Mathematics > University of Rochester > Rochester, NY 14627 > (585) 275-7767 > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > OpenWeBWorK-Devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openwebwork-devel |
|
From: John J. <jj...@as...> - 2005-03-02 17:44:00
|
Hi Arnie, I haven't heard of student complaints, but I have had a couple from instructors. We used all "sql" last semester and "sql_single" this semester. I was just starting to look at this. My guess is that the difference for us is related to database indexing. Last semester, I had my own patch to index the tables. Some of them looked like they needed multiple indexes. Looking at the code, it looks like sql_single does one multi-index per table. For some tables, this is not going to be enough. In other cases, it is possible it isn't building the "right" multi-index. My understanding of the multi-indexes is like this. If you index off of fields user_id, set_id (in that order, it will basically build strings of the user_id and the set_id, possibly with a separator in between, and keeps a sorted list of them. It can then binary search this list. Then the lookups are fast if you provide the user_id, or if you provide the user_id and the set_id. But, if you only provide the set_id the index is not used, and mysql goes linearly through the table. The more entries in the table, of course, the longer it takes. To test this, I plan to redo the indexes on some tables by hand, and then see if operations in that course get faster. If this is right, then I think webwork will need to store information about what indexes to build, maybe in DB/Record/*.pm. John Arnold Pizer wrote: > Hi John et al, > > My students in MTH 162 are seeing a significant slowdown in WeBWorK > this semester and I'm not sure what is going on. I'm wondering if any > of you have seen similar things or if the symptoms bring to mind what > the problem might be. What my students report is that "WeBWorK has > been getting progressively slower every week". I copied below a bit > of the timing log from last Sunday night (162 hw is due early Monday > morning) and it shows that 162 requests are taking 30 or 40 seconds! > The fewer number of requests form other courses were generally under10 > seconds. MTH 162 is the largest course this semester with about 275 > students. Also this semester all courses are using sql_single. Last > semester all but one course used gdbm (with WeBWorK 2) and 97% of > requests took 0 or 1 second. Also the fall courses are larger than > the spring courses. In particular, the largest course last semester > (161) was larger than 162 is now and it used gdbm. Early in the > semester we had a problem with the mysql log filling up the var > partition but that doesn't seem to be the problem now. 162 is using > exactly the same problem sets that have been used for the past 2 > years, so that's not the problem. Also the fact that students report > the problem is getting worst every week seems to rule out server > problems. I assume the table size for mth162 is increasing every week > --- could this be relevant? What else could cause the problem to get > progressively worst? When I looked at the output from top, I saw that > the load was about 1 (i.e. not excessive), mysql was taking almost 100 > % of the cpu, the http processes were taking very little cpu, and no > process was using a lot of memory (this is from memory --- I didn't > make a copy of the out put). > > If we are seeing this problem at Rochester, it hard to believe others > will not see it in the future. If others are not seeing it yet, > maybe it has to do with how mysql is configured here. Are we and > others using a "standard" mysql configuration? > > Below is a bit of the timing log. > > Arnie > > > [Sun Feb 27 21:17:47 2005] 71659 1109557067 - [/webwork2/mth162/6/3/] > [runTime = 46.0 sec sql_single] > [Sun Feb 27 21:17:50 2005] 71702 1109557070 - [/webwork2/mth162/6/2/] > [runTime = 17.0 sec sql_single] > [Sun Feb 27 21:17:53 2005] 71592 1109557073 - [/webwork2/mth161/5/] > [runTime = 5.0 sec sql_single] > [Sun Feb 27 21:17:55 2005] 71659 1109557075 - [/webwork2/mth161/6/14/] > [runTime = 3.0 sec sql_single] > [Sun Feb 27 21:17:56 2005] 71564 1109557076 - [/webwork2/mth162/6/3/] > [runTime = 46.0 sec sql_single] > [Sun Feb 27 21:17:56 2005] 70570 1109557076 - [/webwork2/mth162/6/5/] > [runTime = 49.0 sec sql_single] > [Sun Feb 27 21:17:57 2005] 71592 1109557077 - [/webwork2/mth161/5/8/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:17:57 2005] 70937 1109557077 - [/webwork2/mth162/6/3/] > [runTime = 49.0 sec sql_single] > [Sun Feb 27 21:18:03 2005] 71564 1109557083 - [/webwork2/mth165/7/14/] > [runTime = 3.0 sec sql_single] > [Sun Feb 27 21:18:08 2005] 71659 1109557088 - [/webwork2/ast105/04/9/] > [runTime = 1.0 sec sql_single] > [Sun Feb 27 21:18:11 2005] 70571 1109557091 - [/webwork2/mth162/6/1/] > [runTime = 34.0 sec sql_single] > [Sun Feb 27 21:18:11 2005] 71433 1109557091 - [/webwork2/mth162/6/5/] > [runTime = 36.0 sec sql_single] > [Sun Feb 27 21:18:15 2005] 71702 1109557095 - > [/webwork2/ast105/logout/] [runTime = 1.0 sec sql_single] > [Sun Feb 27 21:18:15 2005] 71628 1109557095 - [/webwork2/mth162/6/3/] > [runTime = 21.0 sec sql_single] > [Sun Feb 27 21:18:16 2005] 71137 1109557096 - [/webwork2/mth162/6/8/] > [runTime = 47.0 sec sql_single] > [Sun Feb 27 21:18:22 2005] 71666 1109557102 - [/webwork2/mth162/6/2/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:18:22 2005] 71479 1109557102 - [/webwork2/mth162/6/3/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:18:26 2005] 71433 1109557106 - [/webwork2/mth162/6/7/] > [runTime = 14.0 sec sql_single] > [Sun Feb 27 21:18:28 2005] 71239 1109557108 - [/webwork2/mth162/6/7/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:18:28 2005] 71161 1109557108 - [/webwork2/mth162/6/3/] > [runTime = 30.0 sec sql_single] > [Sun Feb 27 21:18:38 2005] 71628 1109557118 - [/webwork2/mth162/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:18:38 2005] 71258 1109557118 - [/webwork2/mth162/6/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:18:42 2005] 70570 1109557122 - [/webwork2/mth162/6/3/] > [runTime = 34.0 sec sql_single] > [Sun Feb 27 21:18:45 2005] 71433 1109557125 - [/webwork2/mth165/7/14/] > [runTime = 6.0 sec sql_single] > [Sun Feb 27 21:18:46 2005] 71479 1109557126 - [/webwork2/mth162/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:18:46 2005] 70937 1109557126 - [/webwork2/mth162/6/5/] > [runTime = 37.0 sec sql_single] > [Sun Feb 27 21:18:47 2005] 71659 1109557127 - [/webwork2/mth162/6/6/] > [runTime = 39.0 sec sql_single] > [Sun Feb 27 21:18:48 2005] 70937 1109557128 - [/webwork2/mth142/6/3/] > [runTime = 1.0 sec sql_single] > [Sun Feb 27 21:18:50 2005] 71592 1109557130 - [/webwork2/mth162/6/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:18:51 2005] 71702 1109557131 - [/webwork2/mth162/6/3/] > [runTime = 36.0 sec sql_single] > [Sun Feb 27 21:18:52 2005] 71564 1109557132 - [/webwork2/mth162/6/3/] > [runTime = 37.0 sec sql_single] > [Sun Feb 27 21:18:57 2005] 71479 1109557137 - [/webwork2/mth162/6/3/] > [runTime = 11.0 sec sql_single] > [Sun Feb 27 21:18:58 2005] 71788 1109557138 - [/webwork2/mth162/6/3/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:02 2005] 71592 1109557142 - [/webwork2/mth162/6/6/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:03 2005] 71702 1109557143 - [/webwork2/mth162/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:19:09 2005] 70937 1109557149 - [/webwork2/mth164/09/2/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:13 2005] 71659 1109557153 - [/webwork2/mth162/6/3/] > [runTime = 14.0 sec sql_single] > [Sun Feb 27 21:19:16 2005] 71592 1109557156 - [/webwork2/mth161/6/14/] > [runTime = 2.0 sec sql_single] > [Sun Feb 27 21:19:16 2005] 71239 1109557156 - [/webwork2/mth162/6/7/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:19:20 2005] 71788 1109557160 - [/webwork2/mth162/6/4/] > [runTime = 18.0 sec sql_single] > [Sun Feb 27 21:19:20 2005] 71137 1109557160 - [/webwork2/mth162/6/] > [runTime = 43.0 sec sql_single] > [Sun Feb 27 21:19:21 2005] 71161 1109557161 - [/webwork2/mth162/6/3/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:19:24 2005] 71258 1109557164 - [/webwork2/mth162/6/] > [runTime = 45.0 sec sql_single] > [Sun Feb 27 21:19:26 2005] 71666 1109557166 - [/webwork2/mth162/6/3/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:19:27 2005] 71628 1109557167 - [/webwork2/mth162/6/3/] > [runTime = 37.0 sec sql_single] > [Sun Feb 27 21:19:30 2005] 71702 1109557170 - [/webwork2/mth162/6/3/] > [runTime = 15.0 sec sql_single] > [Sun Feb 27 21:19:31 2005] 71433 1109557171 - [/webwork2/mth162/6/5/] > [runTime = 34.0 sec sql_single] > [Sun Feb 27 21:19:32 2005] 70570 1109557172 - [/webwork2/mth162/6/3/] > [runTime = 38.0 sec sql_single] > [Sun Feb 27 21:19:37 2005] 71258 1109557177 - [/webwork2/mth162/6/6/] > [runTime = 12.0 sec sql_single] > [Sun Feb 27 21:19:37 2005] 71564 1109557177 - [/webwork2/mth162/6/] > [runTime = 45.0 sec sql_single] > [Sun Feb 27 21:19:40 2005] 71788 1109557180 - [/webwork2/mth165/7/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:40 2005] 71479 1109557180 - [/webwork2/mth162/6/3/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:19:42 2005] 70937 1109557182 - [/webwork2/mth142/6/1/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:19:43 2005] 71666 1109557183 - [/webwork2/mth162/6/4/] > [runTime = 16.0 sec sql_single] > [Sun Feb 27 21:19:55 2005] 71258 1109557195 - [/webwork2/mth165/7/] > [runTime = 6.0 sec sql_single] > [Sun Feb 27 21:19:57 2005] 71666 1109557197 - [/webwork2/mth161/5/8/] > [runTime = 2.0 sec sql_single] > [Sun Feb 27 21:20:06 2005] 71161 1109557206 - [/webwork2/mth162/6/3/] > [runTime = 34.0 sec sql_single] > [Sun Feb 27 21:20:06 2005] 71161 1109557206 - [/webwork2/mth142/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:07 2005] 71137 1109557207 - [/webwork2/mth162/6/3/] > [runTime = 35.0 sec sql_single] > [Sun Feb 27 21:20:08 2005] 71666 1109557208 - [/webwork2/mth162/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:09 2005] 71659 1109557209 - [/webwork2/mth162/6/5/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:20:12 2005] 71592 1109557212 - [/webwork2/mth162/6/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:20:14 2005] 71239 1109557214 - [/webwork2/mth162/6/3/] > [runTime = 46.0 sec sql_single] > [Sun Feb 27 21:20:15 2005] 71564 1109557215 - [/webwork2/mth162/6/6/] > [runTime = 38.0 sec sql_single] > [Sun Feb 27 21:20:17 2005] 71161 1109557217 - [/webwork2/mth142/] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:17 2005] 71628 1109557217 - [/webwork2/mth162/6/] > [runTime = 50.0 sec sql_single] > [Sun Feb 27 21:20:18 2005] 70570 1109557218 - [/webwork2/mth162/6/] > [runTime = 45.0 sec sql_single] > [Sun Feb 27 21:20:20 2005] 71788 1109557220 - [/webwork2/mth162/6/2/] > [runTime = 40.0 sec sql_single] > [Sun Feb 27 21:20:24 2005] 71666 1109557224 - [/webwork2/mth162/6/5/] > [runTime = 11.0 sec sql_single] > [Sun Feb 27 21:20:25 2005] 71659 1109557225 - [/webwork2/mth164/09/6/] > [runTime = 4.0 sec sql_single] > [Sun Feb 27 21:20:27 2005] 71137 1109557227 - [/webwork2/mth142/6/3/] > [runTime = 8.0 sec sql_single] > [Sun Feb 27 21:20:27 2005] 71564 1109557227 - [/webwork2/mth162] > [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:28 2005] 71161 1109557228 - [/webwork2/mth142/6/] > [runTime = 9.0 sec sql_single] > [Sun Feb 27 21:20:31 2005] 71592 1109557231 - [/webwork2/mth162/6/2/] > [runTime = 16.0 sec sql_single] > [Sun Feb 27 21:20:35 2005] 70570 1109557235 - [/webwork2/mth162/6/4/] > [runTime = 15.0 sec sql_single] > [Sun Feb 27 21:20:36 2005] 71161 1109557236 - [/webwork2/mth142/6/4/] > [runTime = 1.0 sec sql_single] > [Sun Feb 27 21:20:36 2005] 71659 1109557236 - > [/webwork2/mth165/logout/] [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:36 2005] 71702 1109557236 - [/webwork2/mth162/6/6/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:20:37 2005] 71258 1109557237 - [/webwork2/mth162/6/3/] > [runTime = 42.0 sec sql_single] > [Sun Feb 27 21:20:38 2005] 71479 1109557238 - [/webwork2/mth162/6/6/] > [runTime = 46.0 sec sql_single] > [Sun Feb 27 21:20:39 2005] 71564 1109557239 - > [/webwork2/mth162/logout/] [runTime = 0.0 sec sql_single] > [Sun Feb 27 21:20:40 2005] 71433 1109557240 - [/webwork2/mth162/6/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:20:42 2005] 70937 1109557242 - [/webwork2/mth162/6/3/] > [runTime = 47.0 sec sql_single] > [Sun Feb 27 21:20:45 2005] 71592 1109557245 - [/webwork2/mth162/6/4/] > [runTime = 14.0 sec sql_single] > [Sun Feb 27 21:20:49 2005] 71137 1109557249 - [/webwork2/mth162/6/7/] > [runTime = 11.0 sec sql_single] > [Sun Feb 27 21:20:50 2005] 71161 1109557250 - [/webwork2/mth142/6/3/] > [runTime = 3.0 sec sql_single] > [Sun Feb 27 21:20:53 2005] 71659 1109557253 - [/webwork2/mth161/5/2/] > [runTime = 5.0 sec sql_single] > [Sun Feb 27 21:20:55 2005] 71628 1109557255 - [/webwork2/mth162/6/7/] > [runTime = 37.0 sec sql_single] > [Sun Feb 27 21:21:01 2005] 71258 1109557261 - [/webwork2/mth162/6/6/] > [runTime = 12.0 sec sql_single] > [Sun Feb 27 21:21:04 2005] 71788 1109557264 - [/webwork2/mth162/6/8/] > [runTime = 32.0 sec sql_single] > [Sun Feb 27 21:21:06 2005] 71239 1109557266 - [/webwork2/mth162/6/3/] > [runTime = 40.0 sec sql_single] > [Sun Feb 27 21:21:12 2005] 70570 1109557272 - [/webwork2/mth162/6/4/] > [runTime = 31.0 sec sql_single] > [Sun Feb 27 21:21:17 2005] 71666 1109557277 - [/webwork2/mth162/6/8/] > [runTime = 40.0 sec sql_single] > [Sun Feb 27 21:21:18 2005] 71479 1109557278 - [/webwork2/mth162/6/6/] > [runTime = 40.0 sec sql_single] > [Sun Feb 27 21:21:21 2005] 71788 1109557281 - [/webwork2/mth162/6/6/] > [runTime = 12.0 sec sql_single] > [Sun Feb 27 21:21:23 2005] 70937 1109557283 - [/webwork2/mth162/6/4/] > [runTime = 41.0 sec sql_single] > [Sun Feb 27 21:21:29 2005] 71433 1109557289 - [/webwork2/mth162/6/] > [runTime = 48.0 sec sql_single] > [Sun Feb 27 21:21:30 2005] 71702 1109557290 - [/webwork2/mth162/6/6/] > [runTime = 44.0 sec sql_single] > [Sun Feb 27 21:21:32 2005] 70570 1109557292 - [/webwork2/mth161/5/8/] > [runTime = 7.0 sec sql_single] > > > Prof. Arnold K. Pizer > Dept. of Mathematics > University of Rochester > Rochester, NY 14627 > (585) 275-7767 > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > OpenWeBWorK-Devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openwebwork-devel |
|
From: Arnold P. <ap...@ma...> - 2005-03-02 15:34:23
|
Hi John et al, My students in MTH 162 are seeing a significant slowdown in WeBWorK this semester and I'm not sure what is going on. I'm wondering if any of you have seen similar things or if the symptoms bring to mind what the problem might be. What my students report is that "WeBWorK has been getting progressively slower every week". I copied below a bit of the timing log from last Sunday night (162 hw is due early Monday morning) and it shows that 162 requests are taking 30 or 40 seconds! The fewer number of requests form other courses were generally under10 seconds. MTH 162 is the largest course this semester with about 275 students. Also this semester all courses are using sql_single. Last semester all but one course used gdbm (with WeBWorK 2) and 97% of requests took 0 or 1 second. Also the fall courses are larger than the spring courses. In particular, the largest course last semester (161) was larger than 162 is now and it used gdbm. Early in the semester we had a problem with the mysql log filling up the var partition but that doesn't seem to be the problem now. 162 is using exactly the same problem sets that have been used for the past 2 years, so that's not the problem. Also the fact that students report the problem is getting worst every week seems to rule out server problems. I assume the table size for mth162 is increasing every week --- could this be relevant? What else could cause the problem to get progressively worst? When I looked at the output from top, I saw that the load was about 1 (i.e. not excessive), mysql was taking almost 100 % of the cpu, the http processes were taking very little cpu, and no process was using a lot of memory (this is from memory --- I didn't make a copy of the out put). If we are seeing this problem at Rochester, it hard to believe others will not see it in the future. If others are not seeing it yet, maybe it has to do with how mysql is configured here. Are we and others using a "standard" mysql configuration? Below is a bit of the timing log. Arnie [Sun Feb 27 21:17:47 2005] 71659 1109557067 - [/webwork2/mth162/6/3/] [runTime = 46.0 sec sql_single] [Sun Feb 27 21:17:50 2005] 71702 1109557070 - [/webwork2/mth162/6/2/] [runTime = 17.0 sec sql_single] [Sun Feb 27 21:17:53 2005] 71592 1109557073 - [/webwork2/mth161/5/] [runTime = 5.0 sec sql_single] [Sun Feb 27 21:17:55 2005] 71659 1109557075 - [/webwork2/mth161/6/14/] [runTime = 3.0 sec sql_single] [Sun Feb 27 21:17:56 2005] 71564 1109557076 - [/webwork2/mth162/6/3/] [runTime = 46.0 sec sql_single] [Sun Feb 27 21:17:56 2005] 70570 1109557076 - [/webwork2/mth162/6/5/] [runTime = 49.0 sec sql_single] [Sun Feb 27 21:17:57 2005] 71592 1109557077 - [/webwork2/mth161/5/8/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:17:57 2005] 70937 1109557077 - [/webwork2/mth162/6/3/] [runTime = 49.0 sec sql_single] [Sun Feb 27 21:18:03 2005] 71564 1109557083 - [/webwork2/mth165/7/14/] [runTime = 3.0 sec sql_single] [Sun Feb 27 21:18:08 2005] 71659 1109557088 - [/webwork2/ast105/04/9/] [runTime = 1.0 sec sql_single] [Sun Feb 27 21:18:11 2005] 70571 1109557091 - [/webwork2/mth162/6/1/] [runTime = 34.0 sec sql_single] [Sun Feb 27 21:18:11 2005] 71433 1109557091 - [/webwork2/mth162/6/5/] [runTime = 36.0 sec sql_single] [Sun Feb 27 21:18:15 2005] 71702 1109557095 - [/webwork2/ast105/logout/] [runTime = 1.0 sec sql_single] [Sun Feb 27 21:18:15 2005] 71628 1109557095 - [/webwork2/mth162/6/3/] [runTime = 21.0 sec sql_single] [Sun Feb 27 21:18:16 2005] 71137 1109557096 - [/webwork2/mth162/6/8/] [runTime = 47.0 sec sql_single] [Sun Feb 27 21:18:22 2005] 71666 1109557102 - [/webwork2/mth162/6/2/] [runTime = 42.0 sec sql_single] [Sun Feb 27 21:18:22 2005] 71479 1109557102 - [/webwork2/mth162/6/3/] [runTime = 42.0 sec sql_single] [Sun Feb 27 21:18:26 2005] 71433 1109557106 - [/webwork2/mth162/6/7/] [runTime = 14.0 sec sql_single] [Sun Feb 27 21:18:28 2005] 71239 1109557108 - [/webwork2/mth162/6/7/] [runTime = 42.0 sec sql_single] [Sun Feb 27 21:18:28 2005] 71161 1109557108 - [/webwork2/mth162/6/3/] [runTime = 30.0 sec sql_single] [Sun Feb 27 21:18:38 2005] 71628 1109557118 - [/webwork2/mth162/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:18:38 2005] 71258 1109557118 - [/webwork2/mth162/6/] [runTime = 44.0 sec sql_single] [Sun Feb 27 21:18:42 2005] 70570 1109557122 - [/webwork2/mth162/6/3/] [runTime = 34.0 sec sql_single] [Sun Feb 27 21:18:45 2005] 71433 1109557125 - [/webwork2/mth165/7/14/] [runTime = 6.0 sec sql_single] [Sun Feb 27 21:18:46 2005] 71479 1109557126 - [/webwork2/mth162/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:18:46 2005] 70937 1109557126 - [/webwork2/mth162/6/5/] [runTime = 37.0 sec sql_single] [Sun Feb 27 21:18:47 2005] 71659 1109557127 - [/webwork2/mth162/6/6/] [runTime = 39.0 sec sql_single] [Sun Feb 27 21:18:48 2005] 70937 1109557128 - [/webwork2/mth142/6/3/] [runTime = 1.0 sec sql_single] [Sun Feb 27 21:18:50 2005] 71592 1109557130 - [/webwork2/mth162/6/] [runTime = 42.0 sec sql_single] [Sun Feb 27 21:18:51 2005] 71702 1109557131 - [/webwork2/mth162/6/3/] [runTime = 36.0 sec sql_single] [Sun Feb 27 21:18:52 2005] 71564 1109557132 - [/webwork2/mth162/6/3/] [runTime = 37.0 sec sql_single] [Sun Feb 27 21:18:57 2005] 71479 1109557137 - [/webwork2/mth162/6/3/] [runTime = 11.0 sec sql_single] [Sun Feb 27 21:18:58 2005] 71788 1109557138 - [/webwork2/mth162/6/3/] [runTime = 9.0 sec sql_single] [Sun Feb 27 21:19:02 2005] 71592 1109557142 - [/webwork2/mth162/6/6/] [runTime = 9.0 sec sql_single] [Sun Feb 27 21:19:03 2005] 71702 1109557143 - [/webwork2/mth162/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:19:09 2005] 70937 1109557149 - [/webwork2/mth164/09/2/] [runTime = 9.0 sec sql_single] [Sun Feb 27 21:19:13 2005] 71659 1109557153 - [/webwork2/mth162/6/3/] [runTime = 14.0 sec sql_single] [Sun Feb 27 21:19:16 2005] 71592 1109557156 - [/webwork2/mth161/6/14/] [runTime = 2.0 sec sql_single] [Sun Feb 27 21:19:16 2005] 71239 1109557156 - [/webwork2/mth162/6/7/] [runTime = 41.0 sec sql_single] [Sun Feb 27 21:19:20 2005] 71788 1109557160 - [/webwork2/mth162/6/4/] [runTime = 18.0 sec sql_single] [Sun Feb 27 21:19:20 2005] 71137 1109557160 - [/webwork2/mth162/6/] [runTime = 43.0 sec sql_single] [Sun Feb 27 21:19:21 2005] 71161 1109557161 - [/webwork2/mth162/6/3/] [runTime = 41.0 sec sql_single] [Sun Feb 27 21:19:24 2005] 71258 1109557164 - [/webwork2/mth162/6/] [runTime = 45.0 sec sql_single] [Sun Feb 27 21:19:26 2005] 71666 1109557166 - [/webwork2/mth162/6/3/] [runTime = 41.0 sec sql_single] [Sun Feb 27 21:19:27 2005] 71628 1109557167 - [/webwork2/mth162/6/3/] [runTime = 37.0 sec sql_single] [Sun Feb 27 21:19:30 2005] 71702 1109557170 - [/webwork2/mth162/6/3/] [runTime = 15.0 sec sql_single] [Sun Feb 27 21:19:31 2005] 71433 1109557171 - [/webwork2/mth162/6/5/] [runTime = 34.0 sec sql_single] [Sun Feb 27 21:19:32 2005] 70570 1109557172 - [/webwork2/mth162/6/3/] [runTime = 38.0 sec sql_single] [Sun Feb 27 21:19:37 2005] 71258 1109557177 - [/webwork2/mth162/6/6/] [runTime = 12.0 sec sql_single] [Sun Feb 27 21:19:37 2005] 71564 1109557177 - [/webwork2/mth162/6/] [runTime = 45.0 sec sql_single] [Sun Feb 27 21:19:40 2005] 71788 1109557180 - [/webwork2/mth165/7/] [runTime = 9.0 sec sql_single] [Sun Feb 27 21:19:40 2005] 71479 1109557180 - [/webwork2/mth162/6/3/] [runTime = 42.0 sec sql_single] [Sun Feb 27 21:19:42 2005] 70937 1109557182 - [/webwork2/mth142/6/1/] [runTime = 9.0 sec sql_single] [Sun Feb 27 21:19:43 2005] 71666 1109557183 - [/webwork2/mth162/6/4/] [runTime = 16.0 sec sql_single] [Sun Feb 27 21:19:55 2005] 71258 1109557195 - [/webwork2/mth165/7/] [runTime = 6.0 sec sql_single] [Sun Feb 27 21:19:57 2005] 71666 1109557197 - [/webwork2/mth161/5/8/] [runTime = 2.0 sec sql_single] [Sun Feb 27 21:20:06 2005] 71161 1109557206 - [/webwork2/mth162/6/3/] [runTime = 34.0 sec sql_single] [Sun Feb 27 21:20:06 2005] 71161 1109557206 - [/webwork2/mth142/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:20:07 2005] 71137 1109557207 - [/webwork2/mth162/6/3/] [runTime = 35.0 sec sql_single] [Sun Feb 27 21:20:08 2005] 71666 1109557208 - [/webwork2/mth162/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:20:09 2005] 71659 1109557209 - [/webwork2/mth162/6/5/] [runTime = 44.0 sec sql_single] [Sun Feb 27 21:20:12 2005] 71592 1109557212 - [/webwork2/mth162/6/] [runTime = 44.0 sec sql_single] [Sun Feb 27 21:20:14 2005] 71239 1109557214 - [/webwork2/mth162/6/3/] [runTime = 46.0 sec sql_single] [Sun Feb 27 21:20:15 2005] 71564 1109557215 - [/webwork2/mth162/6/6/] [runTime = 38.0 sec sql_single] [Sun Feb 27 21:20:17 2005] 71161 1109557217 - [/webwork2/mth142/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:20:17 2005] 71628 1109557217 - [/webwork2/mth162/6/] [runTime = 50.0 sec sql_single] [Sun Feb 27 21:20:18 2005] 70570 1109557218 - [/webwork2/mth162/6/] [runTime = 45.0 sec sql_single] [Sun Feb 27 21:20:20 2005] 71788 1109557220 - [/webwork2/mth162/6/2/] [runTime = 40.0 sec sql_single] [Sun Feb 27 21:20:24 2005] 71666 1109557224 - [/webwork2/mth162/6/5/] [runTime = 11.0 sec sql_single] [Sun Feb 27 21:20:25 2005] 71659 1109557225 - [/webwork2/mth164/09/6/] [runTime = 4.0 sec sql_single] [Sun Feb 27 21:20:27 2005] 71137 1109557227 - [/webwork2/mth142/6/3/] [runTime = 8.0 sec sql_single] [Sun Feb 27 21:20:27 2005] 71564 1109557227 - [/webwork2/mth162] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:20:28 2005] 71161 1109557228 - [/webwork2/mth142/6/] [runTime = 9.0 sec sql_single] [Sun Feb 27 21:20:31 2005] 71592 1109557231 - [/webwork2/mth162/6/2/] [runTime = 16.0 sec sql_single] [Sun Feb 27 21:20:35 2005] 70570 1109557235 - [/webwork2/mth162/6/4/] [runTime = 15.0 sec sql_single] [Sun Feb 27 21:20:36 2005] 71161 1109557236 - [/webwork2/mth142/6/4/] [runTime = 1.0 sec sql_single] [Sun Feb 27 21:20:36 2005] 71659 1109557236 - [/webwork2/mth165/logout/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:20:36 2005] 71702 1109557236 - [/webwork2/mth162/6/6/] [runTime = 41.0 sec sql_single] [Sun Feb 27 21:20:37 2005] 71258 1109557237 - [/webwork2/mth162/6/3/] [runTime = 42.0 sec sql_single] [Sun Feb 27 21:20:38 2005] 71479 1109557238 - [/webwork2/mth162/6/6/] [runTime = 46.0 sec sql_single] [Sun Feb 27 21:20:39 2005] 71564 1109557239 - [/webwork2/mth162/logout/] [runTime = 0.0 sec sql_single] [Sun Feb 27 21:20:40 2005] 71433 1109557240 - [/webwork2/mth162/6/] [runTime = 44.0 sec sql_single] [Sun Feb 27 21:20:42 2005] 70937 1109557242 - [/webwork2/mth162/6/3/] [runTime = 47.0 sec sql_single] [Sun Feb 27 21:20:45 2005] 71592 1109557245 - [/webwork2/mth162/6/4/] [runTime = 14.0 sec sql_single] [Sun Feb 27 21:20:49 2005] 71137 1109557249 - [/webwork2/mth162/6/7/] [runTime = 11.0 sec sql_single] [Sun Feb 27 21:20:50 2005] 71161 1109557250 - [/webwork2/mth142/6/3/] [runTime = 3.0 sec sql_single] [Sun Feb 27 21:20:53 2005] 71659 1109557253 - [/webwork2/mth161/5/2/] [runTime = 5.0 sec sql_single] [Sun Feb 27 21:20:55 2005] 71628 1109557255 - [/webwork2/mth162/6/7/] [runTime = 37.0 sec sql_single] [Sun Feb 27 21:21:01 2005] 71258 1109557261 - [/webwork2/mth162/6/6/] [runTime = 12.0 sec sql_single] [Sun Feb 27 21:21:04 2005] 71788 1109557264 - [/webwork2/mth162/6/8/] [runTime = 32.0 sec sql_single] [Sun Feb 27 21:21:06 2005] 71239 1109557266 - [/webwork2/mth162/6/3/] [runTime = 40.0 sec sql_single] [Sun Feb 27 21:21:12 2005] 70570 1109557272 - [/webwork2/mth162/6/4/] [runTime = 31.0 sec sql_single] [Sun Feb 27 21:21:17 2005] 71666 1109557277 - [/webwork2/mth162/6/8/] [runTime = 40.0 sec sql_single] [Sun Feb 27 21:21:18 2005] 71479 1109557278 - [/webwork2/mth162/6/6/] [runTime = 40.0 sec sql_single] [Sun Feb 27 21:21:21 2005] 71788 1109557281 - [/webwork2/mth162/6/6/] [runTime = 12.0 sec sql_single] [Sun Feb 27 21:21:23 2005] 70937 1109557283 - [/webwork2/mth162/6/4/] [runTime = 41.0 sec sql_single] [Sun Feb 27 21:21:29 2005] 71433 1109557289 - [/webwork2/mth162/6/] [runTime = 48.0 sec sql_single] [Sun Feb 27 21:21:30 2005] 71702 1109557290 - [/webwork2/mth162/6/6/] [runTime = 44.0 sec sql_single] [Sun Feb 27 21:21:32 2005] 70570 1109557292 - [/webwork2/mth161/5/8/] [runTime = 7.0 sec sql_single] Prof. Arnold K. Pizer Dept. of Mathematics University of Rochester Rochester, NY 14627 (585) 275-7767 |
|
From: Davide P.C. <dp...@un...> - 2005-02-07 00:33:47
|
> With float and zoom commented out, I see the basic peekaboo bug. > > With float commented out, use of true OL with Davide's suggestions and > zoom still in place I don't see the basic peekaboo, but the OL labels > disappear again. That suggests that it is not the float that is triggering the peekaboo bug, and that the zoom is still the part that is fixing it. I'd be tempted to try to determine whether adding the zoom to a specific DIV could solve the peekaboo without damaging the OL list. For example, perhaps adding zoom only to the div.problem CSS class would do it? The peekaboo bug is also supposed to be fixable you specifying explicit dimensions on the affected boxes. So perhaps adding "height: 1%" to the div.problem class would do it (MSIE will incorrectly enlarge the box to fit its contents) provided this doesn't screw up any other browsers that correctly interpret the dimension. If I have the time during the week, I'll try some of this out myself, but I don't have access to PC's during the weekend. Davide |
|
From: John J. <jj...@as...> - 2005-02-06 23:51:40
|
Arnold Pizer wrote: > At 04:02 PM 2/5/2005, Davide P.Cervone wrote: > > Hi Mike, following Davide's suggestion, commented out the zoom and > float statements in ur.css (and uploaded the changes to the CVS). > This definitely fixed the OL bug with MSIE. > > Also I don't see the peek-a-boo bug in prob 1 of set 0 (where John > said to look) but I didn't see it there before with zoom commented > out. Maybe someone who sees the peek-a-boo bug on a regular basis can > test this. With float and zoom commented out, I see the basic peekaboo bug. With float commented out, use of true OL with Davide's suggestions and zoom still in place I don't see the basic peekaboo, but the OL labels disappear again. John >>>> Is this in comparison to other browsers, or is the server in >>>> generating the page? >>> >>> This is in comparison to other browsers. When I used the Library >>> Browser to check the OL bug on the Mac IE >>> it took many tens of seconds for the full table to come up ** using >>> jsMath mode**. >> >> >> This is jsMath's fault. The Mac version of MSIE just barely runs >> jsMath as it is, and there are some hacks in there to make it work at >> all. One of them is that if you update the page too fast, MSIE >> crashes, so I had to slow it down. The screen flashes because the >> pauses let the browser get around to redrawing the screen in between >> the updates. >> >> Since MicroSoft is no longer supporting MSIE on the Mac, I see no >> reason to work too hard to support it. Safari is superior to MSIE on >> the Mac, anyway. MSIE is pretty crippled on the Mac. I was amazed I >> could get jsMath to run on it at all. >> >> Davide >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> OpenWeBWorK-Devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel > > > > Prof. Arnold K. Pizer > Dept. of Mathematics > University of Rochester > Rochester, NY 14627 > (585) 275-7767 > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > OpenWeBWorK-Devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openwebwork-devel |
|
From: Arnold P. <ap...@ma...> - 2005-02-06 21:14:10
|
At 04:02 PM 2/5/2005, Davide P.Cervone wrote: Hi Mike, following Davide's suggestion, commented out the zoom and float statements in ur.css (and uploaded the changes to the CVS). This definitely fixed the OL bug with MSIE. Also I don't see the peek-a-boo bug in prob 1 of set 0 (where John said to look) but I didn't see it there before with zoom commented out. Maybe someone who sees the peek-a-boo bug on a regular basis can test this. Arnie >>>Is this in comparison to other browsers, or is the server in generating >>>the page? >>This is in comparison to other browsers. When I used the Library Browser >>to check the OL bug on the Mac IE >>it took many tens of seconds for the full table to come up ** using >>jsMath mode**. > >This is jsMath's fault. The Mac version of MSIE just barely runs jsMath >as it is, and there are some hacks in there to make it work at all. One >of them is that if you update the page too fast, MSIE crashes, so I had to >slow it down. The screen flashes because the pauses let the browser get >around to redrawing the screen in between the updates. > >Since MicroSoft is no longer supporting MSIE on the Mac, I see no reason >to work too hard to support it. Safari is superior to MSIE on the Mac, >anyway. MSIE is pretty crippled on the Mac. I was amazed I could get >jsMath to run on it at all. > >Davide > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >Tool for open source databases. Create drag-&-drop reports. Save time >by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >Download a FREE copy at http://www.intelliview.com/go/osdn_nl >_______________________________________________ >OpenWeBWorK-Devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openwebwork-devel Prof. Arnold K. Pizer Dept. of Mathematics University of Rochester Rochester, NY 14627 (585) 275-7767 |
|
From: Davide P.C. <dp...@un...> - 2005-02-05 21:02:59
|
>> Is this in comparison to other browsers, or is the server in >> generating the page? >> > This is in comparison to other browsers. When I used the Library > Browser to check the OL bug on the Mac IE > it took many tens of seconds for the full table to come up ** using > jsMath mode**. This is jsMath's fault. The Mac version of MSIE just barely runs jsMath as it is, and there are some hacks in there to make it work at all. One of them is that if you update the page too fast, MSIE crashes, so I had to slow it down. The screen flashes because the pauses let the browser get around to redrawing the screen in between the updates. Since MicroSoft is no longer supporting MSIE on the Mac, I see no reason to work too hard to support it. Safari is superior to MSIE on the Mac, anyway. MSIE is pretty crippled on the Mac. I was amazed I could get jsMath to run on it at all. Davide |
|
From: Michael G. <ga...@ma...> - 2005-02-05 16:30:25
|
On Feb 5, 2005, at 1:22 AM, John Jones wrote:
> Michael Gage wrote:
>
>> This change may be our best bet -- although I admit I'm rather
>> irritated at the thought of reinventing
>> an HTML concept -- the ordered list -- in order to keep our problems
>> compatible with IE. Can
>> anyone get Davide's suggestion to work? adding </li> at the ends of
>> the lines. That is even better
>> conformance to HTML standards, so that would be a better fix.
>> Otherwise lets go with your change John.
>
> I just tried Davide's suggestion and it didn't work with IE.
>
(sigh) oh well. The only variable I can think of is fooling around
with the {zoom} command in the CSS, according
to Arnie if that is not there then the OL lists work ok. Is there
another way to fix the peekaboo bug?
Also it seems that using OL lists without specifying the letters
works OK, so perhaps there is an alternate way to specify letters
instead of numbers in OL lists that works with MSIE?
I'd really like to use the existing HTML structures if at all possible
-- reinventing them is not a good long term principle,
but for our limited needs of the construct we may need to do it anyway.
One other comment, if we do change the current code, or even if we
don't, I think we should factor out the second stretch of code
that redefines an OL list and call the original OL subroutine instead.
What ever we decide I don't see any reason why the
code needs to appear in two places.
Thanks for looking into this, John.
>> For what it's worth the Mac IE doesn't seem to have a problem with
>> this ordered list structure. It does
>> have other problems however -- it takes for every to render a long
>> list of problems in the Library browser
>> for example.
>
> Is this in comparison to other browsers, or is the server in
> generating the page?
>
This is in comparison to other browsers. When I used the Library
Browser to check the OL bug on the Mac IE
it took many tens of seconds for the full table to come up ** using
jsMath mode**. It kept coming up in jerks, blanking
out completely and then coming back. I think the screen blanks as the
javaScript is rendered. It takes a while to
load in image mode, but you don't get the disconcerting effect of
having the browser blank out and then come back.
In other browsers the blanking effect doesn't occur, but it takes a
while for the javaScript to run down the page and change the
raw TeX into symbols. This is only apparent on long HTML pages -- on a
typical one problem page both the Mac IE and
the other browsers perform fine -- at least on my hardware.
All of this is browser related, it has little if anything to do with
the server.
Take care,
Mike
> John
>
|
|
From: Davide P.C. <dp...@un...> - 2005-02-05 15:42:29
|
> Thanks for the bug report.=A0 Your analysis of this bug agrees with=20=
> ours.=A0 The problem is that
> WeBWorK 2 uses style sheets and without the
>
> * {zoom: 1;}
>
> MSIE's peekaboo bug=A0 (which causes text to sometimes disappear) =
comes=20
> up sometimes.
> We just recently discovered that using the above hack causes the bug=20=
> you report.
I did a little reading about this bug, and apparently it is triggered=20
by floating elements. The only float I can see in the webwork output=20
is the float for div.problemHeader. Has anyone tried removing that=20
float to see if it eliminated the problem? I never understood why that=20=
float was there anyway, and I had removed it from my server long ago=20
(as it triggers another obscure bug in Safari). No one has reported=20
missing list item labels here, but that could be coincidence. Could=20
someone try removing that float specification and see if that helps? I=20=
REALLY hate to lose the ordered-list entries because of MSIE stupidity.
Davide
|
|
From: William H. W. <wh...@in...> - 2005-02-04 23:19:59
|
Dear Arnie (et al), Thanks for your message. I can provide some important information about gdbm, but I can't help with timing comparisons to sql_single and sql, because I'm using BerkeleyDB instead of MySQL. Last semester, I used gdbm for all of our courses. That was not successful, because gdbm locks the entire database when it needs to write a record. Although that locking strategy was not a problem in WeBWorK1 (because there were only 2 accesses to webwork-database per student submission), that locking strategy is impractical in WeBWork2 where webwork-database is used to simulate several tables. At periods of peak demand last semester, the wait time in the queue to access webwork-database would exceed 60 seconds, Apache children would proliferate, RAM memory would be exhausted, and the server would slow to a crawl as it spent most of its time swapping memory pages. So this semester, I swapped to BerkeleyDB. There has been a big, sometimes painful learning curve, but now things are running smoothly. The execution times are somewhat less than wth GDBM. But the crucial improvement is that BerkeleyDB does page locking rather than file locking. So there are no queues to access webwork-database even at peak demand. I've also grown to appreciate and like BerkeleyDB's logging and recovery procedures and its tuning features. There are some subtleties to using BerkeleyDB in the WeBWorK environment (not least because the documentation for BerkeleyDB.pm has many holes). On several occasions, after making mistakes with the BerkeleyDB utilities, I had to rebuild a few webwork-databases from the transaction.log files. But things are going smoothly now. Best wishes. Sincerely, Bill -------------------------------------------------------------------------------- On Fri, 4 Feb 2005, Arnold Pizer wrote: > Date: Fri, 04 Feb 2005 13:50:13 -0500 > From: Arnold Pizer <ap...@ma...> > To: ga...@ma..., sh...@ma..., jj...@as..., > wh...@in..., ope...@li... > Cc: ap...@ma... > Subject: relative speed of sql_single and gdbm > > Hi, > > I'm trying to get some idea of the relative speed of sql_single and gdbm and > have been looking at our timing log. This is prompted by some of my students > reaction that WeBWorK is slower this semester than last. Last semester all > courses (except MTH 162 which used sql) used gdbm. This semester all courses > are using sql_single. It seems gdbm is the fastest, then sql_single, and then > sql. Also sql and sql_single have many more times that are long compared to > gdbm. The details are below but here is a snap shot: > > For gdbm > > 68% of the gdbm entires took 0.0 seconds (the log rounds to 1 second) > 29% of the gdbm entires took 1.0 seconds > 0.01% of the gdbm entires took 10.0 seconds > > For sql_single the percentages were: > > 52% > 34% > 1.7% > > and for sql > > 40% > 31% > 3% > > This data came from our timing log which covers Oct 16, 2004 through Feb 3, > 2005 > (data before Oct 16 were in a different format) > > I'm not sure what we can do with this data but we should be aware of > it. Also I > don't know how BerkelyDB would compare. Bill Wheeler is using that for both > WW1.9 and WW2 at Indiana. > > Arnie > > Here's the actual data: > > There were 702291 total timings for gdbm, 441585 for sql and > 290963 for sql_single. > > grep '0.0 sec gdbm' timing.02_03_05 | wc -l gives the first entry, etc. > > 476652 0.0 sec gdbm > 205360 1.0 sec gdbm > 10644 2.0 sec gdbm > 4936 3.0 sec gdbm > 1058 4.0 sec gdbm > 1177 5.0 sec gdbm > 1784 6.0 sec gdbm > 404 7.0 sec gdbm > 153 8.0 sec gdbm > 123 9.0 sec gdbm > 69 10.0 sec gdbm > 58 11.0 sec gdbm > 26 12.0 sec gdbm > 20 13.0 sec gdbm > 23 14.0 sec gdbm > 46 15.0 sec gdbm > 24 16.0 sec gdbm > 14 17.0 sec gdbm > 12 18.0 sec gdbm > 5 19.0 sec gdbm > 14 20.0 sec gdbm > > > grep '0.0 sec sql_single' timing.02_03_05 | wc -l gives the first entry, etc. > > 150926 0.0 sec sql_single > 100426 1.0 sec sql_single > 22972 2.0 sec sql_single > 7179 3.0 sec sql_single > 3358 4.0 sec sql_single > 2082 5.0 sec sql_single > 1486 6.0 sec sql_single > 1053 7.0 sec sql_single > 840 8.0 sec sql_single > 641 9.0 sec sql_single > 484 10.0 sec sql_single > 374 11.0 sec sql_single > 289 12.0 sec sql_single > 207 13.0 sec sql_single > 190 14.0 sec sql_single > 162 15.0 sec sql_single > 145 16.0 sec sql_single > 129 17.0 sec sql_single > 129 18.0 sec sql_single > 89 19.0 sec sql_single > 94 20.0 sec sql_single > > > grep '0.0 sec sql' timing.02_03_05 | wc -l gives the first entry, etc. > > > 175395 0.0 sec sql > 135452 1.0 sec sql > 35487 2.0 sec sql > 35450 3.0 sec sql > 30331 4.0 sec sql > 12301 5.0 sec sql > 6750 6.0 sec sql > 4583 7.0 sec sql > 3286 8.0 sec sql > 2550 9.0 sec sql > 1657 10.0 sec sql > 1306 11.0 sec sql > 992 12.0 sec sql > 758 13.0 sec sql > 682 14.0 sec sql > 565 15.0 sec sql > 530 16.0 sec sql > 479 17.0 sec sql > 397 18.0 sec sql > 325 19.0 sec sql > 271 20.0 sec sql > > > Prof. Arnold K. Pizer > Dept. of Mathematics > University of Rochester > Rochester, NY 14627 > (585) 275-7767 > > > |
|
From: Michael G. <ga...@ma...> - 2005-02-04 20:58:16
|
Sounds good to me. The underpinnings are pretty solid at this point. There are lots of specialized extras that aren't in place, as Arnie points out. We have a pretty uniform user interface in place and as long as we don't undo the underlying uniformity, we can add the specialized features that are being requested. #######corrected###. You guys should come to some agreement of how the advanced operations should work and add them in to the user interface. My one worry is that if something is being done "automatically" that it can also be disabled in those cases where it isn't needed -- but I expect that you are aware of that also. Take care, Mike On Feb 4, 2005, at 1:09 PM, Arnold Pizer wrote: > At 12:35 PM 2/4/2005, John Jones wrote: > > At 12:35 PM 2/4/2005, you wrote: > > I think something like this would be good. Maybe having an "advanced > operations" link that brings up a new advanced page (sort of like > Google's advanced search). I think there are other placed for an > "advanced operations" links such as when importing classlists (WW 1.9 > has many options where as WW2 has only 2 --- Gavin remarked about > this) or when adding students (WW 1.9 sets up reasonable default times > giving students 2 weeks to do assignments --- a prof here just > complained about this in WW2). > > Arnie > >> Yes, creating directories on the fly fixes part of this problem. The >> "add problem to" feature addresses something else. But, a reasonable >> question is whether there should be more file manager type operations >> available when doing a save as. >> >> One possibility would be to have the "save as" become "save as ..." >> with no entry spot for the new name. Clicking on it brings up a file >> manager type screen when you can see existing directories and >> navigate to where you want the file to go. >> >> John >> >> >> >> >> Arnold Pizer wrote: >> >>> At 11:01 AM 2/3/2005, Michael Gage wrote: >>> >>> Thanks Mike, >>> >>> I didn't realize you could create directories using "save as" . >>> >>> Arnie >>> >>>> Hi Mike, >>>> >>>> Arnie's method seems a bit complicated to me although I it should >>>> work. You might want to try this: >>>> >>>> Say I want a new version of by problem 2 in set 1 which resides >>>> in the file templates/set1/ur_1_1.pg. >>>> >>>> Then start by editing problem2 and use "save as" to save it as >>>> set1/ur_1_1a.pg (notice that the templates directory is assumed) >>>> You can also choose a completely different file name. >>>> >>>> Now use the "add problem to" button and pop down menu to add this >>>> problem to set1 (it will be added to the end of the set) >>>> >>>> Edit the problem as you wish. >>>> >>>> Once you are done you can get rid of the old problem 2 from set 1 >>>> and to rearrange the order of the problems in set 1 you use the >>>> link from the Homework Sets Editor (the link that tells you how >>>> many problems are in the set) >>>> >>>> >>>> >>>> If you want a problem that has associate gifs, follow the same >>>> procedure but when you "save as" save to the path >>>> set1/ur_1_1a/ur_1_1a.pg >>>> >>>> This will create the directory set1/ur_1_1a as well as the .pg >>>> file inside it. >>>> >>>> You use the File Manager to upload the .gif files into the >>>> directory. >>>> >>>> Hope this helps. Let us know how it goes. >>>> >>>> Take care, >>>> >>>> Mike >>>> >>>> On Feb 3, 2005, at 10:32 AM, Arnold Pizer wrote: >>>> >>>>> At 04:51 PM 2/2/2005, you wrote: >>>>> >>>>> Hi Mike, >>>>> >>>>> I don't think it is easy to do what you want. It should be. If >>>>> you save a problem using the editor with the button "Save as", it >>>>> puts the problem (e.g. test.pg) directly under the templates >>>>> directory (not in any subdirectory there of). You can see such >>>>> problems with the Library Browser under Local Problems under the >>>>> so called subdirectory "My Problems" --- this isn't a subdirectory >>>>> at all --- the name is not intuitive but I don't know what name >>>>> would be. The "add problem to" does not copy the problem to a >>>>> subdirectory (which would be the intuitive thing to do from that >>>>> page) but rather adds it to an already assigned set. >>>>> >>>>> You should be able to do what you want by using the File Manager >>>>> to create a new folder, saving the edited problem, the downloading >>>>> the edited problem from the templates directory, uploading it to >>>>> your new directory, then deleting the original problem. If we >>>>> have a problem (say test5.pg in the directory settestproblems) >>>>> with images what we do is to create a directory >>>>> .../settestproblems/test5/ and under the directory test5 we put >>>>> test5.pg and all the image files. >>>>> prob4 in set0 is an example of this. >>>>> >>>>> Arnie >>>>> >>>>> >>>>> >>>>>> Hi Arnie, >>>>>> >>>>>> I have a webwork question for you. I'm trying to write a few >>>>>> problems for my linear algebra class, on webwork as >>>>>> LOYOLA-MA301, and I'm having two difficulties. First, I'm trying >>>>>> to >>>>>> write them by modifying existing problems, and if I modify an >>>>>> existing >>>>>> problem and save and replace it, then it seems to work. But it >>>>>> doesn't >>>>>> seem to want me to save problems with all new problem names. (It >>>>>> says >>>>>> that it is letting me do this, but then when I go to the library >>>>>> browser, the names of the directories I'm making up to put the >>>>>> problems >>>>>> in don't appear.) The other problem that I'm having is that these >>>>>> problems are going to use pictures, and I don't know where I >>>>>> should put >>>>>> my .gif files and can't find any feature on the web interface to >>>>>> add >>>>>> problems using graphics. >>>>>> >>>>>> Thanks for any help you can give me with this. Most likely >>>>>> I'm >>>>>> just doing something stupid. To make sure I'm being clear, I'm >>>>>> *not* >>>>>> asking for help writing the problem code or anything like that. >>>>>> Just >>>>>> how to make a directory and save problems and picture files to it >>>>>> and >>>>>> retrieve them later. >>>>>> >>>>>> Thanks, >>>>>> Mike >>>>> >>>>> >>>>> Prof. Arnold K. Pizer >>>>> Dept. of Mathematics >>>>> University of Rochester >>>>> Rochester, NY 14627 >>>>> (585) 275-7767 >>> >>> Prof. Arnold K. Pizer >>> Dept. of Mathematics >>> University of Rochester >>> Rochester, NY 14627 >>> (585) 275-7767 >> >> > > Prof. Arnold K. Pizer > Dept. of Mathematics > University of Rochester > Rochester, NY 14627 > (585) 275-7767 > > ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ OpenWeBWorK-Devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openwebwork-devel |
|
From: Michael G. <ga...@ma...> - 2005-02-04 20:26:50
|
Sounds good to me. The underpinnings are pretty solid at this point. There are lots of specialized extras that aren't in place, as Arnie points out. We have a pretty uniform user interface in place and as long as we don't undo the underlying uniformity, we can add the specialized features that are being corrected. You guys should come to some agreement of how the advanced operations should work and add them in to the user interface. My one worry is that if something is being done "automatically" that it can also be disabled in those cases where it isn't needed -- but I expect that you are aware of that also. Take care, Mike On Feb 4, 2005, at 1:09 PM, Arnold Pizer wrote: > At 12:35 PM 2/4/2005, John Jones wrote: > > At 12:35 PM 2/4/2005, you wrote: > > I think something like this would be good. Maybe having an "advanced > operations" link that brings up a new advanced page (sort of like > Google's advanced search). I think there are other placed for an > "advanced operations" links such as when importing classlists (WW 1.9 > has many options where as WW2 has only 2 --- Gavin remarked about > this) or when adding students (WW 1.9 sets up reasonable default times > giving students 2 weeks to do assignments --- a prof here just > complained about this in WW2). > > Arnie > >> Yes, creating directories on the fly fixes part of this problem. The >> "add problem to" feature addresses something else. But, a reasonable >> question is whether there should be more file manager type operations >> available when doing a save as. >> >> One possibility would be to have the "save as" become "save as ..." >> with no entry spot for the new name. Clicking on it brings up a file >> manager type screen when you can see existing directories and >> navigate to where you want the file to go. >> >> John >> >> >> >> >> Arnold Pizer wrote: >> >>> At 11:01 AM 2/3/2005, Michael Gage wrote: >>> >>> Thanks Mike, >>> >>> I didn't realize you could create directories using "save as" . >>> >>> Arnie >>> >>>> Hi Mike, >>>> >>>> Arnie's method seems a bit complicated to me although I it should >>>> work. You might want to try this: >>>> >>>> Say I want a new version of by problem 2 in set 1 which resides >>>> in the file templates/set1/ur_1_1.pg. >>>> >>>> Then start by editing problem2 and use "save as" to save it as >>>> set1/ur_1_1a.pg (notice that the templates directory is assumed) >>>> You can also choose a completely different file name. >>>> >>>> Now use the "add problem to" button and pop down menu to add this >>>> problem to set1 (it will be added to the end of the set) >>>> >>>> Edit the problem as you wish. >>>> >>>> Once you are done you can get rid of the old problem 2 from set 1 >>>> and to rearrange the order of the problems in set 1 you use the >>>> link from the Homework Sets Editor (the link that tells you how >>>> many problems are in the set) >>>> >>>> >>>> >>>> If you want a problem that has associate gifs, follow the same >>>> procedure but when you "save as" save to the path >>>> set1/ur_1_1a/ur_1_1a.pg >>>> >>>> This will create the directory set1/ur_1_1a as well as the .pg >>>> file inside it. >>>> >>>> You use the File Manager to upload the .gif files into the >>>> directory. >>>> >>>> Hope this helps. Let us know how it goes. >>>> >>>> Take care, >>>> >>>> Mike >>>> >>>> On Feb 3, 2005, at 10:32 AM, Arnold Pizer wrote: >>>> >>>>> At 04:51 PM 2/2/2005, you wrote: >>>>> >>>>> Hi Mike, >>>>> >>>>> I don't think it is easy to do what you want. It should be. If >>>>> you save a problem using the editor with the button "Save as", it >>>>> puts the problem (e.g. test.pg) directly under the templates >>>>> directory (not in any subdirectory there of). You can see such >>>>> problems with the Library Browser under Local Problems under the >>>>> so called subdirectory "My Problems" --- this isn't a subdirectory >>>>> at all --- the name is not intuitive but I don't know what name >>>>> would be. The "add problem to" does not copy the problem to a >>>>> subdirectory (which would be the intuitive thing to do from that >>>>> page) but rather adds it to an already assigned set. >>>>> >>>>> You should be able to do what you want by using the File Manager >>>>> to create a new folder, saving the edited problem, the downloading >>>>> the edited problem from the templates directory, uploading it to >>>>> your new directory, then deleting the original problem. If we >>>>> have a problem (say test5.pg in the directory settestproblems) >>>>> with images what we do is to create a directory >>>>> .../settestproblems/test5/ and under the directory test5 we put >>>>> test5.pg and all the image files. >>>>> prob4 in set0 is an example of this. >>>>> >>>>> Arnie >>>>> >>>>> >>>>> >>>>>> Hi Arnie, >>>>>> >>>>>> I have a webwork question for you. I'm trying to write a few >>>>>> problems for my linear algebra class, on webwork as >>>>>> LOYOLA-MA301, and I'm having two difficulties. First, I'm trying >>>>>> to >>>>>> write them by modifying existing problems, and if I modify an >>>>>> existing >>>>>> problem and save and replace it, then it seems to work. But it >>>>>> doesn't >>>>>> seem to want me to save problems with all new problem names. (It >>>>>> says >>>>>> that it is letting me do this, but then when I go to the library >>>>>> browser, the names of the directories I'm making up to put the >>>>>> problems >>>>>> in don't appear.) The other problem that I'm having is that these >>>>>> problems are going to use pictures, and I don't know where I >>>>>> should put >>>>>> my .gif files and can't find any feature on the web interface to >>>>>> add >>>>>> problems using graphics. >>>>>> >>>>>> Thanks for any help you can give me with this. Most likely >>>>>> I'm >>>>>> just doing something stupid. To make sure I'm being clear, I'm >>>>>> *not* >>>>>> asking for help writing the problem code or anything like that. >>>>>> Just >>>>>> how to make a directory and save problems and picture files to it >>>>>> and >>>>>> retrieve them later. >>>>>> >>>>>> Thanks, >>>>>> Mike >>>>> >>>>> >>>>> Prof. Arnold K. Pizer >>>>> Dept. of Mathematics >>>>> University of Rochester >>>>> Rochester, NY 14627 >>>>> (585) 275-7767 >>> >>> Prof. Arnold K. Pizer >>> Dept. of Mathematics >>> University of Rochester >>> Rochester, NY 14627 >>> (585) 275-7767 >> >> > > Prof. Arnold K. Pizer > Dept. of Mathematics > University of Rochester > Rochester, NY 14627 > (585) 275-7767 > > |
|
From: Arnold P. <ap...@ma...> - 2005-02-04 18:49:27
|
Hi,
I'm trying to get some idea of the relative speed of sql_single and gdbm and
have been looking at our timing log. This is prompted by some of my students
reaction that WeBWorK is slower this semester than last. Last semester all
courses (except MTH 162 which used sql) used gdbm. This semester all courses
are using sql_single. It seems gdbm is the fastest, then sql_single, and then
sql. Also sql and sql_single have many more times that are long compared to
gdbm. The details are below but here is a snap shot:
For gdbm
68% of the gdbm entires took 0.0 seconds (the log rounds to 1 second)
29% of the gdbm entires took 1.0 seconds
0.01% of the gdbm entires took 10.0 seconds
For sql_single the percentages were:
52%
34%
1.7%
and for sql
40%
31%
3%
This data came from our timing log which covers Oct 16, 2004 through Feb 3,
2005
(data before Oct 16 were in a different format)
I'm not sure what we can do with this data but we should be aware of
it. Also I
don't know how BerkelyDB would compare. Bill Wheeler is using that for both
WW1.9 and WW2 at Indiana.
Arnie
Here's the actual data:
There were 702291 total timings for gdbm, 441585 for sql and
290963 for sql_single.
grep '0.0 sec gdbm' timing.02_03_05 | wc -l gives the first entry, etc.
476652 0.0 sec gdbm
205360 1.0 sec gdbm
10644 2.0 sec gdbm
4936 3.0 sec gdbm
1058 4.0 sec gdbm
1177 5.0 sec gdbm
1784 6.0 sec gdbm
404 7.0 sec gdbm
153 8.0 sec gdbm
123 9.0 sec gdbm
69 10.0 sec gdbm
58 11.0 sec gdbm
26 12.0 sec gdbm
20 13.0 sec gdbm
23 14.0 sec gdbm
46 15.0 sec gdbm
24 16.0 sec gdbm
14 17.0 sec gdbm
12 18.0 sec gdbm
5 19.0 sec gdbm
14 20.0 sec gdbm
grep '0.0 sec sql_single' timing.02_03_05 | wc -l gives the first entry, etc.
150926 0.0 sec sql_single
100426 1.0 sec sql_single
22972 2.0 sec sql_single
7179 3.0 sec sql_single
3358 4.0 sec sql_single
2082 5.0 sec sql_single
1486 6.0 sec sql_single
1053 7.0 sec sql_single
840 8.0 sec sql_single
641 9.0 sec sql_single
484 10.0 sec sql_single
374 11.0 sec sql_single
289 12.0 sec sql_single
207 13.0 sec sql_single
190 14.0 sec sql_single
162 15.0 sec sql_single
145 16.0 sec sql_single
129 17.0 sec sql_single
129 18.0 sec sql_single
89 19.0 sec sql_single
94 20.0 sec sql_single
grep '0.0 sec sql' timing.02_03_05 | wc -l gives the first entry, etc.
175395 0.0 sec sql
135452 1.0 sec sql
35487 2.0 sec sql
35450 3.0 sec sql
30331 4.0 sec sql
12301 5.0 sec sql
6750 6.0 sec sql
4583 7.0 sec sql
3286 8.0 sec sql
2550 9.0 sec sql
1657 10.0 sec sql
1306 11.0 sec sql
992 12.0 sec sql
758 13.0 sec sql
682 14.0 sec sql
565 15.0 sec sql
530 16.0 sec sql
479 17.0 sec sql
397 18.0 sec sql
325 19.0 sec sql
271 20.0 sec sql
Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767
|
|
From: Arnold P. <ap...@ma...> - 2005-02-04 18:09:05
|
At 12:35 PM 2/4/2005, John Jones wrote: At 12:35 PM 2/4/2005, you wrote: I think something like this would be good. Maybe having an "advanced operations" link that brings up a new advanced page (sort of like Google's advanced search). I think there are other placed for an "advanced operations" links such as when importing classlists (WW 1.9 has many options where as WW2 has only 2 --- Gavin remarked about this) or when adding students (WW 1.9 sets up reasonable default times giving students 2 weeks to do assignments --- a prof here just complained about this in WW2). Arnie >Yes, creating directories on the fly fixes part of this problem. The "add >problem to" feature addresses something else. But, a reasonable question >is whether there should be more file manager type operations available >when doing a save as. > >One possibility would be to have the "save as" become "save as ..." with >no entry spot for the new name. Clicking on it brings up a file manager >type screen when you can see existing directories and navigate to where >you want the file to go. > >John > > > > >Arnold Pizer wrote: > >>At 11:01 AM 2/3/2005, Michael Gage wrote: >> >>Thanks Mike, >> >>I didn't realize you could create directories using "save as" . >> >>Arnie >> >>>Hi Mike, >>> >>>Arnie's method seems a bit complicated to me although I it should >>>work. You might want to try this: >>> >>>Say I want a new version of by problem 2 in set 1 which resides in the >>>file templates/set1/ur_1_1.pg. >>> >>>Then start by editing problem2 and use "save as" to save it as >>>set1/ur_1_1a.pg (notice that the templates directory is assumed) >>>You can also choose a completely different file name. >>> >>>Now use the "add problem to" button and pop down menu to add this >>>problem to set1 (it will be added to the end of the set) >>> >>>Edit the problem as you wish. >>> >>>Once you are done you can get rid of the old problem 2 from set 1 and to >>>rearrange the order of the problems in set 1 you use the link from the >>>Homework Sets Editor (the link that tells you how many problems are in the set) >>> >>> >>> >>>If you want a problem that has associate gifs, follow the same procedure >>>but when you "save as" save to the path >>>set1/ur_1_1a/ur_1_1a.pg >>> >>>This will create the directory set1/ur_1_1a as well as the .pg file >>>inside it. >>> >>>You use the File Manager to upload the .gif files into the directory. >>> >>>Hope this helps. Let us know how it goes. >>> >>>Take care, >>> >>>Mike >>> >>>On Feb 3, 2005, at 10:32 AM, Arnold Pizer wrote: >>> >>>>At 04:51 PM 2/2/2005, you wrote: >>>> >>>>Hi Mike, >>>> >>>>I don't think it is easy to do what you want. It should be. If you >>>>save a problem using the editor with the button "Save as", it puts the >>>>problem (e.g. test.pg) directly under the templates directory (not in >>>>any subdirectory there of). You can see such problems with the Library >>>>Browser under Local Problems under the so called subdirectory "My >>>>Problems" --- this isn't a subdirectory at all --- the name is not >>>>intuitive but I don't know what name would be. The "add problem to" >>>>does not copy the problem to a subdirectory (which would be the >>>>intuitive thing to do from that page) but rather adds it to an already >>>>assigned set. >>>> >>>>You should be able to do what you want by using the File Manager to >>>>create a new folder, saving the edited problem, the downloading the >>>>edited problem from the templates directory, uploading it to your new >>>>directory, then deleting the original problem. If we have a problem >>>>(say test5.pg in the directory settestproblems) with images what we do >>>>is to create a directory .../settestproblems/test5/ and under the >>>>directory test5 we put test5.pg and all the image files. >>>>prob4 in set0 is an example of this. >>>> >>>>Arnie >>>> >>>> >>>> >>>>> Hi Arnie, >>>>> >>>>> I have a webwork question for you. I'm trying to write a few >>>>>problems for my linear algebra class, on webwork as >>>>>LOYOLA-MA301, and I'm having two difficulties. First, I'm trying to >>>>>write them by modifying existing problems, and if I modify an existing >>>>>problem and save and replace it, then it seems to work. But it doesn't >>>>>seem to want me to save problems with all new problem names. (It says >>>>>that it is letting me do this, but then when I go to the library >>>>>browser, the names of the directories I'm making up to put the problems >>>>>in don't appear.) The other problem that I'm having is that these >>>>>problems are going to use pictures, and I don't know where I should put >>>>>my .gif files and can't find any feature on the web interface to add >>>>>problems using graphics. >>>>> >>>>> Thanks for any help you can give me with this. Most likely I'm >>>>>just doing something stupid. To make sure I'm being clear, I'm *not* >>>>>asking for help writing the problem code or anything like that. Just >>>>>how to make a directory and save problems and picture files to it and >>>>>retrieve them later. >>>>> >>>>>Thanks, >>>>>Mike >>>> >>>> >>>>Prof. Arnold K. Pizer >>>>Dept. of Mathematics >>>>University of Rochester >>>>Rochester, NY 14627 >>>>(585) 275-7767 >> >>Prof. Arnold K. Pizer >>Dept. of Mathematics >>University of Rochester >>Rochester, NY 14627 >>(585) 275-7767 > > Prof. Arnold K. Pizer Dept. of Mathematics University of Rochester Rochester, NY 14627 (585) 275-7767 |
|
From: John J. <jj...@as...> - 2005-02-04 17:35:58
|
Yes, creating directories on the fly fixes part of this problem. The "add problem to" feature addresses something else. But, a reasonable question is whether there should be more file manager type operations available when doing a save as. One possibility would be to have the "save as" become "save as ..." with no entry spot for the new name. Clicking on it brings up a file manager type screen when you can see existing directories and navigate to where you want the file to go. John Arnold Pizer wrote: > At 11:01 AM 2/3/2005, Michael Gage wrote: > > Thanks Mike, > > I didn't realize you could create directories using "save as" . > > Arnie > >> Hi Mike, >> >> Arnie's method seems a bit complicated to me although I it should >> work. You might want to try this: >> >> Say I want a new version of by problem 2 in set 1 which resides in >> the file templates/set1/ur_1_1.pg. >> >> Then start by editing problem2 and use "save as" to save it as >> set1/ur_1_1a.pg (notice that the templates directory is assumed) >> You can also choose a completely different file name. >> >> Now use the "add problem to" button and pop down menu to add this >> problem to set1 (it will be added to the end of the set) >> >> Edit the problem as you wish. >> >> Once you are done you can get rid of the old problem 2 from set 1 and >> to rearrange the order of the problems in set 1 you use the link from >> the Homework Sets Editor (the link that tells you how many problems >> are in the set) >> >> >> >> If you want a problem that has associate gifs, follow the same >> procedure but when you "save as" save to the path >> set1/ur_1_1a/ur_1_1a.pg >> >> This will create the directory set1/ur_1_1a as well as the .pg >> file inside it. >> >> You use the File Manager to upload the .gif files into the directory. >> >> Hope this helps. Let us know how it goes. >> >> Take care, >> >> Mike >> >> On Feb 3, 2005, at 10:32 AM, Arnold Pizer wrote: >> >>> At 04:51 PM 2/2/2005, you wrote: >>> >>> Hi Mike, >>> >>> I don't think it is easy to do what you want. It should be. If you >>> save a problem using the editor with the button "Save as", it puts >>> the problem (e.g. test.pg) directly under the templates directory >>> (not in any subdirectory there of). You can see such problems with >>> the Library Browser under Local Problems under the so called >>> subdirectory "My Problems" --- this isn't a subdirectory at all --- >>> the name is not intuitive but I don't know what name would be. The >>> "add problem to" does not copy the problem to a subdirectory (which >>> would be the intuitive thing to do from that page) but rather adds >>> it to an already assigned set. >>> >>> You should be able to do what you want by using the File Manager to >>> create a new folder, saving the edited problem, the downloading the >>> edited problem from the templates directory, uploading it to your >>> new directory, then deleting the original problem. If we have a >>> problem (say test5.pg in the directory settestproblems) with images >>> what we do is to create a directory .../settestproblems/test5/ and >>> under the directory test5 we put test5.pg and all the image files. >>> prob4 in set0 is an example of this. >>> >>> Arnie >>> >>> >>> >>>> Hi Arnie, >>>> >>>> I have a webwork question for you. I'm trying to write a few >>>> problems for my linear algebra class, on webwork as >>>> LOYOLA-MA301, and I'm having two difficulties. First, I'm trying to >>>> write them by modifying existing problems, and if I modify an existing >>>> problem and save and replace it, then it seems to work. But it >>>> doesn't >>>> seem to want me to save problems with all new problem names. (It says >>>> that it is letting me do this, but then when I go to the library >>>> browser, the names of the directories I'm making up to put the >>>> problems >>>> in don't appear.) The other problem that I'm having is that these >>>> problems are going to use pictures, and I don't know where I should >>>> put >>>> my .gif files and can't find any feature on the web interface to add >>>> problems using graphics. >>>> >>>> Thanks for any help you can give me with this. Most likely I'm >>>> just doing something stupid. To make sure I'm being clear, I'm *not* >>>> asking for help writing the problem code or anything like that. Just >>>> how to make a directory and save problems and picture files to it and >>>> retrieve them later. >>>> >>>> Thanks, >>>> Mike >>> >>> >>> Prof. Arnold K. Pizer >>> Dept. of Mathematics >>> University of Rochester >>> Rochester, NY 14627 >>> (585) 275-7767 >>> >> > > Prof. Arnold K. Pizer > Dept. of Mathematics > University of Rochester > Rochester, NY 14627 > (585) 275-7767 |
|
From: Sam H. <sh...@ma...> - 2005-01-29 16:37:04
|
On Jan 29, 2005, at 10:04 AM, Michael Gage wrote:
> Should global.conf.dist include entries for $guest (which is set to
> -1 by default) in version rel-2-1-patches?
>
> The HEAD version of global.conf.dist has this extra permission level.
> I don't know if it is used in rel-2-1-patches.
Supporting guest doesn't require any changes in the code, since I've
already backported the "login" privilege. I'll go ahead and backport
guest support as well (although $guest should be set to -5 -- my
mistake).
webwork2: new default classlist file. (sh002i)
courses/defaultClasslist.lst
webwork2: made similar changes to default admin-course classlist.
admin's password is "admin". (sh002i)
courses/adminClasslist.lst
webwork2: fixed headers (sh002i)
courses/{adminClasslist.lst,defaultClasslist.lst}
webwork2: added $guest to permissionLevels hash (sh002i)
conf/global.conf.dist
At this point, an instructor will be able to manually change the
permission level of existing practice users to -5 to prevent them from
changing email, password, sending feedback, etc., and practice users
imported from the default and admin classlist files will have the
reduced permission level.
-sam
|
|
From: Michael G. <ga...@ma...> - 2005-01-29 15:04:23
|
Hi, Should global.conf.dist include entries for $guest (which is set to -1 by default) in version rel-2-1-patches? The HEAD version of global.conf.dist has this extra permission level. I don't know if it is used in rel-2-1-patches. Take care, Mike |
|
From: Sam H. <sh...@ma...> - 2005-01-28 21:49:30
|
I'm posting this to the development list in hopes that someone will=20
have some insight.
-sam
Begin forwarded message:
> From: Arnold Pizer <ap...@ma...>
> Date: January 28, 2005 2:16:43 PM EST
> To: John Jones <jj...@as...>, Arnold Pizer <ap...@ma...>
> Cc: Sam Hathaway <sh...@ma...>, ga...@ma...
> Subject: Re: bug using <OL> with MSIE in WW2
>
> At 01:51 PM 1/28/2005, John Jones wrote:
>
> Thanks John,
>
> Arnie
>
>
> Arnold Pizer wrote:
>
> At 10:02 AM 1/28/2005, John Jones wrote:
>
> Hi John,
>
> Substituting
>
> /* Hides from IE5-mac \*/
> * html .buggybox {height: 1%;}
> /* End hide from IE5-mac */
>
> (see http://www.positioniseverything.net/articles/hollyhack.html )
>
> for the zoom:1 fix=A0 fixes the problem with labels in MSIE.=A0 Can =
you=20
> test quickly if this fixes the peekaboo bug?=A0 I don't recall where=20=
> this was appearing, so I don't know how to test it quickly.=A0 Sam is=20=
> adding a number of bug fixes to rel-2-1-patches and the zoom:1 fix is=20=
> one of them:
>
> webwork2: Add hack to get around MSIE peekaboo bug. (apizer)
> =A0=A0=A0=A0=A0=A0=A0=A0conf/templates/ur.template
>
> so it would be good if we can get this done before he finalized that.
> Just tried replacing the zoom line with the one above and it does not=20=
> fix the bug.=A0 =46rom my meager understanding of css, that's because =
the=20
> fix above only applies to css elements which are declared as=20
> buggybox.=A0 So, some other part(s) of the template have to declare=20
> themselves as being buggyboxes.=A0 I am not sure on which ones should =
be=20
> so declared, and how best to do that.=A0 I did try putting a div of=20
> class buggybox inside the div for body (and also just outside of it),=20=
> and neither worked.
>
> It is easiest to see the peekaboo bug on the first problem of set0,=20=
> especially if you reload the page.=A0 You may have to be logged in as =
a=20
> student to see it because triggering the bug is related to the length=20=
> of the content in the left panel vs. the content in the main panel=20
> containing the problem.=A0 Narrowing your browser window may also help=20=
> in triggering it.
>
> John
>
>
>
>
> Arnie
>
>
>
>
> Hi,
>
> We have encountered this bug, but we don't have a fix yet.=A0 I =
didn't=20
> realize it was caused by the zoom:1 fix.=A0 My recollection is that I=20=
> tried "position: relative" in various spots instead of the zoom fix=20
> without success.=A0 But, I was basically blindly putting it in places=20=
> without much understanding of what's going on.
>
> I'll let you know if I find a more universal fix.=A0 For now I tell=20=
> people that it is an explorer bug, and they should use netscape,=20
> mozilla, or some other browser.
>
> John
>
>
> Arnold Pizer wrote:
>
> At 07:05 PM 1/26/2005, Sam Hathaway wrote:
>
> Hi Sam and John,
>
> The thing that causes the problem is
>
> /* hack to get around MSIE peekaboo bug */
> * {zoom: 1;}
>
> When this is removed, the labels appear with the original TYPE=3D"A"=20=
> VALUE=3D"1" and also with TYPE=3D"A" or
> STYLE=3D"list-style:upper-alpha".=A0 When this hack is present, the=20=
> labels disappear under all the above options.
>
> Is there a better bug fix for the peekaboo bug that doesn't cause=20
> other problems (at least other problems that appear in WeBWorK?).=A0 =
For=20
> example on the web I found:
>
>
> I have usually used position: relative; to get rid of the bug, but it=20=
> appears there's a much better solution. It seems that if the container=20=
> that holds the float* is given an assigned 'line-height' (any assigned=20=
> line-height) the bug vanishes. Cool. Testing shows that 'line-height:=20=
> 1.2em;' generally works well, but in the case of child elements with=20=
> differing font sizes, it may be necessary to also give them their own=20=
> line-heights to avoid problems in IE.
>
>
>
> John, I think you are the expert on this.=A0 Any ideas?
>
> Arnie
>
>
>
> On Jan 26, 2005, at 2:56 PM, Arnold Pizer wrote:
>
>
> Hi Sam,
>
> If you look at prob 1 in set 1 in=20
> http://webwork.rochester.edu/webwork2/mth141 with MSIE 6, the letters=20=
> A,B, etc in the ordered list do not appear.=A0 It works OK with other=20=
> browsers. The relevant code in the problem is
>
> =A0=A0=A0=A0=A0=A0=A0=A0 <OL TYPE=3D"A" VALUE=3D"1">
> ...
> =A0=A0=A0=A0=A0=A0=A0 </OL>
>
> which is generated by &match_questions_list.
>
> =A0<OL TYPE=3D"A" VALUE=3D"1"> is deprecated but supposed to work =
with=20
> transitional 4.*.
>
> If you comment out the style commands in the source (i.e. <style>=20
> .... </style>) then the ordered list looks fine with MSIE so something=20=
> within the style is causing MSIE not to use the deprecated commands.=A0
> Do you have any idea what may be the problem.?=A0 Of course we can =
say=20
> don't use MSIE but that doesn't help students.=A0 I assume one =
solution=20
> would be to rewrite &match_questions_list so that it uses CSS and=20
> modify <style> .... </style> accordingly.=A0 Do you know of another=20
> solution?
>
> I don't have access to IE 6, but I'm not sure that this is happening=20=
> because deprecated attributes are being ignored. But lets see if we=20
> can work around it:
>
> First of all, does the VALUE attribute in the <OL> tag actually do=20
> anything? According to the HTML 4.01 specification, VALUE is only=20
> valid for <LI>, not for <UL> and <OL>. Does removing VALUE change IE's=20=
> behavior?
>
> What happens if you remove the TYPE attribute as well? Do the default=20=
> numeric labels appear, or is it still blank?
>
> Also try replacing TYPE with STYLE=3D"list-style:upper-alpha". Any=20
> difference?
> -sam
> Prof. Arnold K. Pizer
> Dept. of Mathematics
> University of Rochester
> Rochester, NY 14627
> (585) 275-7767
>
> Prof. Arnold K. Pizer
> Dept. of Mathematics
> University of Rochester
> Rochester, NY 14627
> (585) 275-7767
>
> Prof. Arnold K. Pizer
> Dept. of Mathematics
> University of Rochester
> Rochester, NY 14627
> (585) 275-7767
>
|
32 messages has been excluded from this view by a project administrator.
