php-general Digest 4 May 2011 07:04:13 -0000 Issue 7296
Topics (messages 312653 through 312659):
Re: php to store data
312653 by: Florin Jurcovici
312655 by: Philip Thompson
312656 by: Stuart Dallas
Using SQLite without hosting support
312654 by: Paul M Foster
312657 by: admin.buskirkgraphics.com
312658 by: Paul M Foster
lots of lstats when maintainer-zts is enabled
312659 by: Seth Miller
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Hi.
Create a page containing just:
<?php
phpinfo()
?>
open it in a browser, then see if SQLite appears in the resulting web
page. If yes, you're done - you can use an actual database, although
an embedded one. But this should also mean that you have file write
access from PHP - since SQLite creates databases in files, which it
needs to be able to write. (Although brain-damaged setups where SQLite
is installed but write access to the disk cannot be excluded - you
need to test.)
If you don't have write access to the disk, my guess is that paying
for mySQL is the cheapest solution - and a very good one, actually.
br,
flj
--
Fine counsel is confusing, but example is always clear. (Edgar A.
Guest, The Light of Faith)
--- End Message ---
--- Begin Message ---
On Tue, May 3, 2011 at 5:18 AM, Florin Jurcovici <[email protected]
> wrote:
> Hi.
>
> Create a page containing just:
>
> <?php
> phpinfo()
> ?>
>
> open it in a browser, then see if SQLite appears in the resulting web
> page. If yes, you're done - you can use an actual database, although
> an embedded one. But this should also mean that you have file write
> access from PHP - since SQLite creates databases in files, which it
> needs to be able to write. (Although brain-damaged setups where SQLite
> is installed but write access to the disk cannot be excluded - you
> need to test.)
>
> If you don't have write access to the disk, my guess is that paying
> for mySQL is the cheapest solution - and a very good one, actually.
>
> br,
>
> flj
Paying for mysql (non enterprise) just seems wrong...
~Philip
http://lonestarlightandsound.com/
--- End Message ---
--- Begin Message ---
On Tuesday, 3 May 2011 at 17:50, Philip Thompson wrote:
On Tue, May 3, 2011 at 5:18 AM, Florin Jurcovici <[email protected]
> > wrote:
>
> > Hi.
> >
> > Create a page containing just:
> >
> > <?php
> > phpinfo()
> > ?>
> >
> > open it in a browser, then see if SQLite appears in the resulting web
> > page. If yes, you're done - you can use an actual database, although
> > an embedded one. But this should also mean that you have file write
> > access from PHP - since SQLite creates databases in files, which it
> > needs to be able to write. (Although brain-damaged setups where SQLite
> > is installed but write access to the disk cannot be excluded - you
> > need to test.)
> >
> > If you don't have write access to the disk, my guess is that paying
> > for mySQL is the cheapest solution - and a very good one, actually.
> >
> > br,
> >
> > flj
>
>
> Paying for mysql (non enterprise) just seems wrong...
You're not paying for MySQL, you're paying for the costs of hosting it, which
are not insignificant.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Assume you have a hosting account with PHP5 support, but no SQLite
support. Yes, supposedly SQLite support is standard for PHP5, but
there's no law that keeps someone from compiling PHP5 without SQLite
support.
So assuming that's the case, given that SQLite is a pretty simple
product, is it possible to run PHP5 and use SQLite, even if support for
it is not built in? The dl() function has some restrictions on it which
might prohibit its use, so is there some way to use SQLite in this
situation without resorting to using the dl() function?
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
Paul,
I could be wrong on this but unless you have a dedicated server, you
do not have the recompilation rights if the hosting company is worth
anything.
Richard L. Buskirk
-----Original Message-----
From: Paul M Foster [mailto:[email protected]]
Sent: Tuesday, May 03, 2011 12:36 PM
To: [email protected]
Subject: [PHP] Using SQLite without hosting support
Assume you have a hosting account with PHP5 support, but no SQLite
support. Yes, supposedly SQLite support is standard for PHP5, but
there's no law that keeps someone from compiling PHP5 without SQLite
support.
So assuming that's the case, given that SQLite is a pretty simple
product, is it possible to run PHP5 and use SQLite, even if support for
it is not built in? The dl() function has some restrictions on it which
might prohibit its use, so is there some way to use SQLite in this
situation without resorting to using the dl() function?
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Tue, May 03, 2011 at 02:14:17PM -0400, [email protected] wrote:
>
> -----Original Message-----
> From: Paul M Foster [mailto:[email protected]]
> Sent: Tuesday, May 03, 2011 12:36 PM
> To: [email protected]
> Subject: [PHP] Using SQLite without hosting support
>
> Assume you have a hosting account with PHP5 support, but no SQLite
> support. Yes, supposedly SQLite support is standard for PHP5, but
> there's no law that keeps someone from compiling PHP5 without SQLite
> support.
>
> So assuming that's the case, given that SQLite is a pretty simple
> product, is it possible to run PHP5 and use SQLite, even if support for
> it is not built in? The dl() function has some restrictions on it which
> might prohibit its use, so is there some way to use SQLite in this
> situation without resorting to using the dl() function?
>
>
>
> Paul,
> I could be wrong on this but unless you have a dedicated server, you
> do not have the recompilation rights if the hosting company is worth
> anything.
No, of course not. I have no desire to recompile PHP. But the hosting
company is entirely capable of recompiling PHP without support for
SQLite, if that's their preference.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
I'm attempting to run PHP as an Apache2 module using the worker MPM. I
understand this is not recommended but because of the nature of the application
and traffic on the servers, prefork and CGI have not preformed well for me.
I'm running this in production right now and most of the site is running very
smoothly with the exception of functions such as file_exists.
An strace makes it clear why. For every file, it does a loop like this
lstat("/root", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
lstat("/root/images-medium", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat("/root/images-medium/harbor-view-blues-ryan-merrill.jpg",
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
access("/root/images-medium/harbor-view-blues-ryan-merrill.jpg", F_OK) = 0
This output is from a test VM I created to duplicate the issue in a sandbox. I
created a tiny test script that reads a list of files and does a file_exists on
each.
Subsequent runs of this script does not get any faster. It never caches the
results.
If I remove enable-maintainer-zts from configure, it does not do this. It runs
much more efficiently but of course does not work with Apache's worker MPM any
longer.
I've tried going back to prefork but the server's load spikes well over 200 in
seconds and crashes. I've narrowed it down to pages using imagick but nothing I
do seems to work. Things work OK when I browse the site but going live or
hitting it with ab or siege will take down the box.
FastCGI has given me even worse performance.
The best performance I get is from the worker MPM and mod_php.
I am running PHP 5.2.17 on CentOS 5.6 64bit.
I tested with 5.3.6 and it actually works even with enable-maintainer-zts but
it breaks the current code base. I'm going to push on dev to get our code
updated to work with 5.3.x but I was hoping there was a quick fix somewhere.
Regards,
Seth
--- End Message ---
