Menu
▾
▴
ids-devel — IDS developers use this list
You can subscribe to this list here.
| 2001 |
Jan
(2) |
Feb
(48) |
Mar
(16) |
Apr
(14) |
May
(42) |
Jun
(36) |
Jul
(57) |
Aug
(13) |
Sep
(2) |
Oct
(23) |
Nov
(17) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
|
Mar
(10) |
Apr
(1) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(12) |
Oct
(26) |
Nov
(11) |
Dec
(37) |
| 2003 |
Jan
(11) |
Feb
(27) |
Mar
(5) |
Apr
(21) |
May
(11) |
Jun
(38) |
Jul
(8) |
Aug
(29) |
Sep
(2) |
Oct
|
Nov
(7) |
Dec
(5) |
| 2004 |
Jan
(5) |
Feb
(2) |
Mar
(19) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(8) |
|
From: Jeff M. <jef...@vi...> - 2003-02-08 21:29:26
|
Hi, I tend to put any perl modules a program requires into that program's own perl library. I then add the library path to my perl program. When I install the program I do this: perl -I /path/program/perllib Makefile.PL PREFIX=3D/path/program/perllib LI= B=3D/path/program/perllib The program then has this: #!/bin/perl use FindBin qw($Bin); use lib "$Bin/perllib"; <rest of program> Why do I do this? This helps prevents an accidental update of perl modules affecting the program. I also put the source of the modules (the tar files) into CVS, as you can not depend on CPAN to have that version of the module handy. Ashley's recent problems with Image-Info-1.12 reminded me of this method. Perhaps we should also include the modules IDS requires as part if the total package. This should lessen support headaches. I'll send my makefile that compiles/installs the modules at a later date (having trouble with ImageMagick at the moment). What are everyone else's thoughts? --=20 Jeff Macdonald <jef...@vi...> Into birding? Check out http://www.migratus.com |
|
From: Ashley M. K. <as...@pc...> - 2003-02-04 21:46:35
|
As I work on 0.82 and get it prepped for CVS, I noticed that Image::Info 1.12 was causing serious errors, forcing me to roll back to 1.11. Has anyone else noticed problems with it? -- W | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. |
|
From: Jeff M. <jef...@vi...> - 2003-02-02 17:59:40
|
Hi, Don't mean to be a pain, but maybe if I just mention the word (FORK) something will happen. :-) Looking for the code to be in CVS. I'm a sourceforge member, user id is remle, so if I'm part of the project I don't mind putting the code into CVS. --=20 Jeff Macdonald <jef...@vi...> Into birding? Check out http://www.migratus.com |
|
From: <sw...@cy...> - 2003-01-29 20:56:24
|
Bruno,
Thank you.
I have added a wrapper test of "if (-r $file) { }" inside the foreach loop. It looked like putting an invalid filename (or bad relative location) in one of these tags would result in a server error. Other than that, it looks good.
|
|
From: Bruno T. <ba...@ip...> - 2003-01-24 20:38:30
|
Just add the following code to the "processVarTags" function in idsShared.pm
------ begin -------
my @files_to_include = ($pageContent =~
/<![- ]*file:(.*?)[- ]*>/sg);
foreach my $file (@files_to_include) {
open(FTI, "<$file");
my $file_content;
while(<FTI>) { $file_content .= $_; }
close(FTI);
$pageContent =~ s/<![- ]*file:$file[- ]*>/$file_content/sg;
}
---- end ---
Hope you find it usefull
----- Original Message -----
From: "Thierry Benita" <tb...@fr...>
To: "Bruno Tavares" <ba...@ip...>
Sent: Thursday, January 23, 2003 4:53 PM
Subject: Re: [Ids-devel] Feature
> On 22 Jan 2003 18:45:31 +0000, Bruno Tavares wrote
> > Hello,
> Hi,
>
> >
> > I've been using ids for some time now and recently i needed to port ids
> > to a new layout site. The template engine works just fine but, in my
> > particular case, the header, footer and menus for this site where stored
> > in files. The desing of the site should be the same in any area so i
> > had to find a way to read this files into a ids theme.
> >
> > I changed ids code to recognize one more html tag "<!-- file:<filename>
> > -->". This causes ids to include in the tag place the contents of the
> > specified tag. I don't now if anyone else thinks this is usefull, if
> > so i can post the code.
> Of course yes !
>
> >
> > Thanks.
> Thanks to you :)
>
>
|
|
From: Bruno T. <ba...@ip...> - 2003-01-22 18:45:37
|
Hello, I've been using ids for some time now and recently i needed to port ids to a new layout site. The template engine works just fine but, in my particular case, the header, footer and menus for this site where stored in files. The desing of the site should be the same in any area so i had to find a way to read this files into a ids theme. I changed ids code to recognize one more html tag "<!-- file:<filename> -->". This causes ids to include in the tag place the contents of the specified tag. I don't now if anyone else thinks this is usefull, if so i can post the code. Thanks. |
|
From: Jeff M. <jef...@vi...> - 2003-01-21 17:31:40
|
Hopefully the next step is for the code to be available via CVS! :-) On Tue, 2003-01-21 at 09:12, sw...@cy... wrote: > This is a test and a greeting. I believe that I signed up for this list last week, but have seen nothing since then. The fact that this appears to be a low activity list (from my reading of the archives) is a good thing. Please accept my apologies for wasting everyone's time with this test. > > On the other hand, I did want to say hello, and ask for pointers as to which task you folks would like to foist off on a newbie. For instance, since I am still familiarizing myself with the code and structure of your package, is there a documentation need that I could take on? > > I read (although not studied) the 388 messages in the ids-devel archives this past weekend. I have also sent a request to Ashley to join the project. > > What's the next step? > > Barry Swift > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > IDS-devel mailing list > IDS...@li... > https://lists.sourceforge.net/lists/listinfo/ids-devel -- Jeff Macdonald <jef...@vi...> |
|
From: <sw...@cy...> - 2003-01-21 14:12:36
|
This is a test and a greeting. I believe that I signed up for this list last week, but have seen nothing since then. The fact that this appears to be a low activity list (from my reading of the archives) is a good thing. Please accept my apologies for wasting everyone's time with this test. On the other hand, I did want to say hello, and ask for pointers as to which task you folks would like to foist off on a newbie. For instance, since I am still familiarizing myself with the code and structure of your package, is there a documentation need that I could take on? I read (although not studied) the 388 messages in the ids-devel archives this past weekend. I have also sent a request to Ashley to join the project. What's the next step? Barry Swift |
|
From: Kevin P. <pfe...@iu...> - 2003-01-02 21:49:32
|
Hi all, Though only a short time on the list, I'm saying good-bye. I've found a very nice image server (php-based) that is racing along on my 'sparc running linux' and I've pulled the plug on ids. On my set-up (probably something I misconfigured) it never did get up to speed, and the new server is so fast I can't keep up). Thanks for your help, tips, and advice. -K -- Kevin Pfeiffer <pfe...@iu...> - www.iu-bremen.de Online Editorial Services - International University Bremen "The rule still applies. However, this rule will not be enforced." |
|
From: Larry A. <ai...@sp...> - 2003-01-02 05:28:54
|
Piet,
wow. thanks for the detailed review and explanation. I was able to
get ids installed using your steps and new rpms. This was enormously easier
than using CPAN the first times I unsuccessfully tried to install ids on RH
8.0 .
I want to document a few things for other installers.
1) the key was installing all rpm's on one command line.
2) the first time I tried this approach, I got error messages that some
of the modules were already installed and the rpm -Uvh *.rpm failed. So I
deleted the already installed modules with rpm -ev package-name. Then rpm
-Uvh *.rpm worked.
3) I needed to add a "b" to get your step 5 working, as in
htpasswd -bm /usr/share/ids/admin/.htpasswd admin "your lovely password"
good show!
Larry
======
At 03:01 PM 12/31/02, you wrote:
>Date: Mon, 30 Dec 2002 23:00:55 -0800 (PST)
>From: Piet Barber <pie...@ya...>
>Subject: Re: [Ids-devel] installing from new rpm
>To: Larry Airaghi <ai...@sp...>, ids...@li...
>
>I spent Christmas afternoon chasing all of the dependent Perl modules,
>RPMifying each one of them.
>
>1) if you're running rh80, downoad the whole directory of RPMs from:
>http://pietbarber.com/ids/RPMS/ (don't download the ids-0.82-0.i386.rpm --
>delete it if you already have; it's kind of broken in not-so-subtle ways).
>
>2) Make sure you already have ImageMagick-perl*.rpm installed from the
>distribution CD or a mirror of the redhat archive.
>
>3) go into the directory where you downloaded all of the RPMs, and run rpm
>-Uvh
>*.rpm
>
>4) restart your web server (/sbin/service httpd restart)
>
>5) Make sure you supply a good password for the admin:
>htpasswd -m /usr/share/ids/admin/.htpasswd admin "your lovely password"
...
|
|
From: happyman <hap...@co...> - 2003-01-02 04:02:49
|
Yes. Thanx for Jeff's correction..
Only dynamic fastcgi server process is single.=20
however, we can speed ids up a little by share some program blocks.
My patch is located:
http://210.59.224.194/~happyman/ids-fastcgi-big5.patch
Most of my efforts is make IDS handle Chinese BIG5 correctly.=20
Big5 is double-byte and ranges as below:
my $BIG5 =3D '[\xa1-\xf9](?:[\x40-\x7e]|[\xa1-\xfe])';
the 2nd byte contains special chars. like '_' '\' (have problem with =
regular expression)
BTW, The dirty big5 search and match function in idsShared.pm is powered =
by my school bro. Sywang. :)
Enjoy it!
Eric Chiu
----- Original Message -----=20
From: "Jeff Dafoe" <je...@ba...>
To: <ids...@li...>
Sent: Thursday, January 02, 2003 10:24 AM
Subject: Re: [Ids-devel] IDS speed and modperl/fcgi
> I am using ids+fastcgi. The most importnat thing is fastcgi is a
single process,
It's a single process as long as your concurrency is a single =
request.
It's identical to regular CGI in that regards. Unless you modified IDS =
to
be multithreaded.
Jeff
|
|
From: Jeff D. <je...@ba...> - 2003-01-02 02:29:37
|
> I am using ids+fastcgi. The most importnat thing is fastcgi is a
single process,
It's a single process as long as your concurrency is a single request.
It's identical to regular CGI in that regards. Unless you modified IDS to
be multithreaded.
Jeff
|
|
From: happyman <hap...@co...> - 2003-01-02 00:32:40
|
Hi all,
I am using ids+fastcgi. The most importnat thing is fastcgi is a =
single process,
css2 happyman/public_html> ps ax |grep ids
32158 ? S 32:04 /usr/bin/suidperl -U =
/dev/fd/3//home/happyman/public_html/ids/index.fcgi
I made ids runing as its owner using suidperl, so the thumbnails =
too. I don't really care about thumbnail creation time.
It handles very well on my site with 2.7G photos (including =
image-cache). You can link your image-cache dir to
tmpfs (shared-memory filesystem) or install a reverse proxy to increase =
speed. (I did)]
visit my pages on http://photos.happyman.idv.tw/
regs,
Eric Chiu
----- Original Message -----=20
From: "Jeff Dafoe" <je...@ba...>
To: <ids...@li...>
Sent: Wednesday, January 01, 2003 2:48 AM
Subject: [Ids-devel] IDS speed and modperl/fcgi
I think the main "lack of speed" most people are experiencing in IDS =
is
the amount of time it takes ImageMagick to create the thumbs and the =
various
image sizes. The speed at which this operation occurs can only be =
improved
by a faster CPU and possibly a very small amount by a faster hard drive.
FastCGI and modperl are used when a site is expecting a tremendous
amount of traffic, perhaps on the order of one dynamic page requested =
per
second or higher. That is the point when the script and interpreter =
startup
overhead starts to load the server down. Implementing FastCGI and/or
modperl support doesn't make any noteable speed increase to a single =
user.
It just prevents the system from buckling when you get 1,000 visitors /
20,000 page views an hour.
Jeff
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
IDS-devel mailing list
IDS...@li...
https://lists.sourceforge.net/lists/listinfo/ids-devel
|
|
From: Anthony A. D. T. <aa...@ve...> - 2003-01-01 12:17:20
|
>I generally do a 'wget' to do the dirty work of generating those 512 byte >wide images ahead of time, instead of when the visitor gets to the site. I do this too, and have been amazed that wget actually seems to navigate the whole site. I've had miserable experience trying to get it to leech arbitrary web sites - it tends to arbitrarily not follow some links, despite being instructed to recurse. |
|
From: Ashley M. K. <as...@pc...> - 2002-12-31 20:33:48
|
Scott Sawyer wrote:
>For those of us that are coding challenged (me). How is that?
>
The default method is to generate only one preview, 100 pixels:
print "Beginning preview generation...\n";
foreach $file (@FilesToPreview) {
createDisplayImage($previewMaxDimension, '', $file);
print "Created preview for \"$file\"\n";
}
If you want the others, you can augment that. I wanted to have 512,
640 and 800 created, so my code looks like:
foreach $file (@FilesToPreview) {
createDisplayImage($previewMaxDimension, '', $file);
createDisplayImage(512, '', $file);
createDisplayImage(640, '', $file);
createDisplayImage(800, '', $file);
print "Created preview for \"$file\"\n";
}
Please note that I added an extra size on my site. I have both a
'tiny' and a 'small'.
--
W | I haven't lost my mind; it's backed up on tape somewhere.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
IT Director / SysAdmin / WebSmith . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Kevin P. <pfe...@iu...> - 2002-12-31 20:29:54
|
Scott Sawyer writes: > I also notice that for the most part people only look at the 512 sizes > of the images. If the previewmaker could create those as well then that > would solve a lot of the speed issues that I see. Ashley mentioned doing this; it's quite easy. Previewmaker gets its max preview size from the ids.config. Just to try this I made a copy of both, adding -512 to the names, removing most config items from the ids-512.config file and of course changing "previewMaxDimension" to 512. This works fine. I think it's just as easy though to modify the loop in a copy of previewmaker (the one that runs at 3:00 am) to do both image sizes at the same time. Maybe Ashley already has this handy. BTW, the site he mentioned is very fast; I think my problem is the platform I'm using. It cost almost nothing and new machines are cheap these days, so I'll try a faster server before "mucking about" further. :-) -K > I do have though over probably 10k images at this point and that will > eat up a lot of disk space. The whole speed for space problem. -- Kevin Pfeiffer <pfe...@iu...> - www.iu-bremen.de Online Editorial Services - International University Bremen "The rule still applies. However, this rule will not be enforced." |
|
From: Scott S. <ss...@sc...> - 2002-12-31 20:26:18
|
For those of us that are coding challenged (me). How is that? -Scott On Tue, 2002-12-31 at 13:23, Ashley M. Kirchner wrote: > Piet Barber wrote: > > >I generally do a 'wget' to do the dirty work of generating those 512 byte wide > >images ahead of time, instead of when the visitor gets to the site. > > > This can easily be done with the same previewmaker.pl script, by the > way. > > -- > W | I haven't lost my mind; it's backed up on tape somewhere. > +-------------------------------------------------------------------- > Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 > IT Director / SysAdmin / WebSmith . 800.441.3873 x130 > Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6 > http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > IDS-devel mailing list > IDS...@li... > https://lists.sourceforge.net/lists/listinfo/ids-devel > -- Scott Sawyer o: 928 226 0404 Owner c: 602 920 0083 Scott Sawyer Photography http://www.scottsawyer.org Capturing today's moments, forever |
|
From: Ashley M. K. <as...@pc...> - 2002-12-31 20:24:07
|
Piet Barber wrote:
>I generally do a 'wget' to do the dirty work of generating those 512 byte wide
>images ahead of time, instead of when the visitor gets to the site.
>
This can easily be done with the same previewmaker.pl script, by the
way.
--
W | I haven't lost my mind; it's backed up on tape somewhere.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
IT Director / SysAdmin / WebSmith . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Piet B. <pie...@ya...> - 2002-12-31 20:19:03
|
I generally do a 'wget' to do the dirty work of generating those 512 byte wide images ahead of time, instead of when the visitor gets to the site. This may take a long time if you have a lot of images, or a lot of big images, especially on a slow computer. At least the images get stored in the image-cache directory. The command to recursively get up to 8 levels of links from a site is: wget -r -np -l 5 URL (where "URL" is your home page) (You can use the --delete-after option of wget to have the images and files deleted immediately after download) --- Scott Sawyer <ss...@sc...> wrote: > I would concur with that assessment. > > I also notice that for the most part people only look at the 512 sizes > of the images. If the previewmaker could create those as well then that > would solve a lot of the speed issues that I see. > > I do have though over probably 10k images at this point and that will > eat up a lot of disk space. The whole speed for space problem. > > -Scott __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: mike b. <wm...@ar...> - 2002-12-31 20:03:29
|
the tiny patch at the bottom of this mail significantly speeds up album page generation for IDS 0.8 and 0.81, and looks like it would work for 0.82 as well. the problem is that fillDateHash is called in both generateAlbum and sortItems, but it really only needs to be called in sortItems. further, generateAlbum always calls fillDateHash regardless of sort type, whereas sortItems is smarter and only calls fillDateHash when sorting by timestamp. i caught this using the DProf perl profiler, which showed IDS was spending most of its time in Image::TIFF getting timestamps from photos, even when not sorting by timestamp. time trials for before and after the patch is applied, using the default intelligent sort method : rezrov ~/public_html/reality % dprofpp albumpage.dpp Total Elapsed Time = 4.123205 Seconds User+System Time = 4.013175 Seconds rezrov ~/public_html/reality % dprofpp albumpage-optimized.dpp Total Elapsed Time = 1.486758 Seconds User+System Time = 1.486758 Seconds these were taken on an old AMD-K6 300mhz machine, so the improvement is somewhat magnified. it's still worthwhile on a faster machine, however. sorting by timestamp speed is improved as well, since fillDateHash was being called twice per file when sorting by timestamp previously, and now is only called once. apologies if this has already been brought up - i poked through the mailing list archives and piet's patches website and didn't spot anything that looked similar. i had submitted this directly to mo...@mu... about a year ago and had never heard anything back - i imagine it got lost in the shuffle someplace. ---mike biesele http://real.ity.org/ rezrov ~/ids-0.81 % diff -c index.cgi index-opt.cgi *** index.cgi Fri Oct 5 17:15:28 2001 --- index-opt.cgi Sun Dec 16 23:56:22 2001 *************** *** 379,388 **** $imagecounter = 0; my($startcounter) = 0; my ($commentedItems) = 'n'; ! ! foreach my $fileName (@itemsToDisplay) { ! fillDateHash($fileName); ! } @itemsToDisplay = sortItems(@itemsToDisplay); # generate album HTML --- 379,390 ---- $imagecounter = 0; my($startcounter) = 0; my ($commentedItems) = 'n'; ! ! # redundant - fillDateHash is called in sortItems when necessary already ! # ! # foreach my $fileName (@itemsToDisplay) { ! # fillDateHash($fileName); ! # } @itemsToDisplay = sortItems(@itemsToDisplay); # generate album HTML > > I think the main "lack of speed" most people are experiencing in IDS is >the amount of time it takes ImageMagick to create the thumbs and the various >image sizes. The speed at which this operation occurs can only be improved >by a faster CPU and possibly a very small amount by a faster hard drive. > FastCGI and modperl are used when a site is expecting a tremendous >amount of traffic, perhaps on the order of one dynamic page requested per >second or higher. That is the point when the script and interpreter startup >overhead starts to load the server down. Implementing FastCGI and/or >modperl support doesn't make any noteable speed increase to a single user. >It just prevents the system from buckling when you get 1,000 visitors / >20,000 page views an hour. > > >Jeff > > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >IDS-devel mailing list >IDS...@li... >https://lists.sourceforge.net/lists/listinfo/ids-devel > |
|
From: Scott S. <ss...@sc...> - 2002-12-31 19:42:52
|
I would concur with that assessment. I also notice that for the most part people only look at the 512 sizes of the images. If the previewmaker could create those as well then that would solve a lot of the speed issues that I see. I do have though over probably 10k images at this point and that will eat up a lot of disk space. The whole speed for space problem. -Scott On Tue, 2002-12-31 at 11:48, Jeff Dafoe wrote: > > I think the main "lack of speed" most people are experiencing in IDS is > the amount of time it takes ImageMagick to create the thumbs and the various > image sizes. The speed at which this operation occurs can only be improved > by a faster CPU and possibly a very small amount by a faster hard drive. > FastCGI and modperl are used when a site is expecting a tremendous > amount of traffic, perhaps on the order of one dynamic page requested per > second or higher. That is the point when the script and interpreter startup > overhead starts to load the server down. Implementing FastCGI and/or > modperl support doesn't make any noteable speed increase to a single user. > It just prevents the system from buckling when you get 1,000 visitors / > 20,000 page views an hour. > > > Jeff > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > IDS-devel mailing list > IDS...@li... > https://lists.sourceforge.net/lists/listinfo/ids-devel > -- Scott Sawyer o: 928 226 0404 Owner c: 602 920 0083 Scott Sawyer Photography http://www.scottsawyer.org Capturing today's moments, forever |
|
From: Jeff D. <je...@ba...> - 2002-12-31 18:52:54
|
I think the main "lack of speed" most people are experiencing in IDS is
the amount of time it takes ImageMagick to create the thumbs and the various
image sizes. The speed at which this operation occurs can only be improved
by a faster CPU and possibly a very small amount by a faster hard drive.
FastCGI and modperl are used when a site is expecting a tremendous
amount of traffic, perhaps on the order of one dynamic page requested per
second or higher. That is the point when the script and interpreter startup
overhead starts to load the server down. Implementing FastCGI and/or
modperl support doesn't make any noteable speed increase to a single user.
It just prevents the system from buckling when you get 1,000 visitors /
20,000 page views an hour.
Jeff
|
|
From: Ashley M. K. <as...@pc...> - 2002-12-31 18:32:20
|
Kevin Pfeiffer wrote: >Do y'all see reasonably good performance using newer Intel-based machines >(linux)? Something with 1.8 processor and 256-512MB RAM? > See for yourself: http://photos.yeehaw.net/ Server specs: 1GHz Coppermine 512 MB RAM 7200 rpm 60GB Drive. Stock Red Hat 7.3 Apache Stock IDS 0.82 (not running under mod_perl, or any other speed daemon) Read he news section, specifically the Site Stats section. It gives you an idea of how much is on it, and how large the files are. I should also mention that I have previewmaker.pl generate 3 sets of previews when run instead of the default one, 512, 640, and 800. I personally noticed a speed increase when I moved away from my old SGI Challenge which was a much, MUCH slower, 233 MHz RISC processor, with 512 MB and a small 4.5 SCSI drive. But then, who wouldn't? It was a slow beast, even for a RISC. -- M | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. |
|
From: Kevin P. <pfe...@iu...> - 2002-12-31 11:54:25
|
One last comment for the last day of 2002... Eric Chiu mentions modifications he made to use fastcgi. I couldn't find an e-mail address for him, but would be interested to hear about his modifications. Also comments on speed in general. My test server is an 'old' Sparc20 workstation running Linux. It has 384 MB RAM and scsi drives but I think the processor is very slow. Do y'all see reasonably good performance using newer Intel-based machines (linux)? Something with 1.8 processor and 256-512MB RAM? -Kevin -- Kevin Pfeiffer <pfe...@iu...> - www.iu-bremen.de Online Editorial Services - International University Bremen "The rule still applies. However, this rule will not be enforced." |
|
From: Kevin P. <pfe...@iu...> - 2002-12-31 09:50:50
|
Hello ids-dev list!
Ids is up and running here on my test server at IUB; I hope in the next
couple weeks to set up a 'production' version for our students. A couple
questions, but first a thanks for your advice and help (as well as the fix
posted for the search function in 0.82).
1. mod_perl
Someone mentioned having tried this with some success. Index.cgi was kept as
normal cgi. He had a problem with the resized images. Has anyone else
looked at using mod_perl? Any advice?
2. jpegtran system call
It fails with a 256 error. I assume the problem is file permissions. Can
anyone tell me, when I try to rotate an image, does ids use the original
image and then try to save it in the image-cache? Or does it try to replace
the original image?
3. .htaccess
I'm using this to restrict access to the gallery and to the admin script. I
think one could use this to restrict access to specific albums as well (a
desired feature I think). I'll report back after I've experimented further.
4. One last bonus question (I could have sent these separately, but think of
this as the 'digest' version): error log
I have no error log in ids. Do I need to set logging/debugging somewhere or
just touch a new file ('error.txt')?
Thanks again and I wish you "a good slide into the new year"! (as one says
in Germany)
--
Kevin Pfeiffer <pfe...@iu...> - www.iu-bremen.de
Online Editorial Services - International University Bremen
"The rule still applies. However, this rule will not be enforced."
|
7 messages has been excluded from this view by a project administrator.
