To follow up on this, it might be a problem that was fixed in a more
recent version of PHP. Or at least in the curl code.
I ran a test on a recent Gentoo Linux machine running Apache 2.0.54,
PHP 5.1.4 and Linux 2.6.15 with 10,000 vhosts in one vhost.conf file and
the curl test ran fine. A little slow, but works.
So I'd still appretiate any insight into how I can fix the problem with
my current version. Because that's where the problem is.
From looking through the last few years of bug reports related to
curl, I haven't found anything related to what I am experiencing.
Mark
On Thu, Sep 21, 2006 at 03:28:28PM GMT, Mark Krenz [mark@suso.org] said the following:
>
> I really can't upgrade right now. Basically, I'd be risking breaking
> the machine because I'd have to upgrade to a newer support version of
> Fedora that might have some incompatibilities with some custom packages
> I've setup and end up having way too much downtime. Even if it was at 3
> in the morning. Its easier to just setup a new machine and migrate
> people to it, but I'm not to that point yet. So I'm trying to buy some
> time and figure out why I can't add any more vhosts.
>
> When you say filesize, do you mean the filesize of the vhost.conf file
> that holds the vhost config? If so then that doesn't seem to be the
> case. The vhost.conf file is currently 198K in size and has 315 vhosts.
> It stops working if I have 319 or 320 vhosts.
>
> I'm going to try setting this up on a newer machine with newer
> versions and see if I run into the same problem with the curl functions
> under PHP.
>
> If this helps, this is the curl code that I'm using to test whether
> curl works or not.
>
> <?php
> $ch = curl_init("http://www.cnn.com/");
> $fp = fopen("example_homepage.txt", "w");
>
> curl_setopt($ch, CURLOPT_FILE, $fp);
> curl_setopt($ch, CURLOPT_HEADER, 0);
>
> curl_exec($ch);
> curl_close($ch);
> fclose($fp);
>
> print "Well, it seemed to work because this is the last function
> call<BR>\n";
>
> ?>
>
> When it fails to work due to having too many vhosts turned on, nothing
> is written to the file and my browser just sits there waiting for the
> page to complete. Interestingly enough, things like max_execution_time
> doesn't seem to stop the request after the allotted time. It can sit
> there for 10+ minutes and never stop.
>
> Mark
>
>
> On Thu, Sep 21, 2006 at 02:27:42PM GMT, Richard Quadling [rquadling@googlemail.com] said the following:
> >
> > As you intend to upgrade, would it be worth waiting until after the upgrade.
> >
> > Apache 2.0.59 (not too far behind)
> > PHP 4.4.4 (maybe a little too far behind)
> > Linux 2.6.18 (again not too far behind)
> >
> > Now, there may well be some SIGNIFICANT changes in there.
> >
> > You say that adding / removing a few makes a difference. Is the
> > filesize that you are editing (or that ends up being edited if you are
> > using a web-based tool) significant in size?
> >
> > Say a 64K or some other bounday? It may be that the filesize has maxed
> > out (some developer somewhere thought no-one would EVER need more than
> > 1MB of vhost containers!).
> >
> >
> >
> > --
> > -----
> > Richard Quadling
> > Zend Certified Engineer :
> > http://zend.com/zce.php?c=ZEND002498&r=213474731
> > "Standing on the shoulders of some very clever giants!"
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> --
> Mark S. Krenz
> IT Director
> Suso Technology Services, Inc.
> http://suso.org/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/
