|
Home > Archive > SQL Anywhere for Linux > January 2006 > sqlanywhere module for PHP 5.1.2?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
sqlanywhere module for PHP 5.1.2?
|
|
| Altair 2006-01-18, 8:23 pm |
| Hello,
I am experiencing problems, when trying to compile sqlanywhere module
with PHP 5.1.2.
At first I copy 1.0.8 version to PHP source "ext" dir.
Then I cd sqlanywhere and touch *
then cd to PHP source dir and ./buildconf --force
then ./configure --with-apxs ... --with-sqlanywhere=/opt/sybase/SYBSsa9
and configure script gives me:
configure:111881: checking for SQLAnywhere support
configure:111920: result: no
So this PHP version is not supported yet?
When it is planned to be supported?
Thank you.
Arunas
| |
| David Fishburn 2006-01-20, 9:23 am |
| Altair <altair@pagalba.com> wrote in news:43cec1e0$1@foru
ms-1-dub
of sybase.public.sqlanywhere.linux:
A> I am experiencing problems, when trying to compile sqlanywhere module
A> with PHP 5.1.2.
A>
A> At first I copy 1.0.8 version to PHP source "ext" dir.
A> Then I cd sqlanywhere and touch *
A> then cd to PHP source dir and ./buildconf --force
A> then ./configure --with-apxs ... --with-
sqlanywhere=/opt/sybase/SYBSsa9
A>
A> and configure script gives me:
A> configure:111881: checking for SQLAnywhere support
A> configure:111920: result: no
A>
A> So this PHP version is not supported yet?
A> When it is planned to be supported?
Didn't even know it had been released, the website has Jan 12, 2006.
I will talk to the developer to see what might be different between the
5.1.1 and the 5.1.2 release.
--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).
EBFs and Maintenance Releases
http://downloads.sybase.com/swx/sdmain.stm
Developer Community / Whitepapers
http://www.ianywhere.com/developer
CaseXpress - to report bugs
http://casexpress.sybase.com
CodeXchange - Free samples
[url]http://ianywhere.codexchange.sybase.com/servlets/ ProjectDocumentList[
/url]
| |
|
| I've tested it and got no problems on compilation.
....but my suggest is: use FreeTds or OpenClient it has
better performance
and not so many bugs. this php extenshion is only for toy
web service and
can't serve real load.
>
> I am experiencing problems, when trying to compile
> sqlanywhere module with PHP 5.1.2.
>
> At first I copy 1.0.8 version to PHP source "ext" dir.
> Then I cd sqlanywhere and touch *
> then cd to PHP source dir and ./buildconf --force
> then ./configure --with-apxs ...
> --with-sqlanywhere=/opt/sybase/SYBSsa9
>
> and configure script gives me:
> configure:111881: checking for SQLAnywhere support
> configure:111920: result: no
>
> So this PHP version is not supported yet?
> When it is planned to be supported?
>
> Thank you.
> Arunas
| |
| Greg Fenton 2006-01-22, 8:23 pm |
| Alex wrote:
> ....but my suggest is: use FreeTds or OpenClient it has
> better performance
> and not so many bugs. this php extenshion is only for toy
> web service and
> can't serve real load.
Can you explain how this driver is a "toy" and why you feel it cannot
serve a "real load"?
TDS is not a native protocol to ASA. On top of that, it is not an
efficient protocol. The ASA/PHP module uses dblib directly (it is an
embedded SQL client to the database), and dblib is one of the two native
interfaces that ASA supports (the other is ODBC, dbodbc).
Do you have some type of load test showing that FreeTDS can handle a
better load than does php_sqlanywhere ? If so, we'd love to have
details about it (or get a copy??) so we can address your concerns.
Thanks in advance,
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
| |
|
| > Alex wrote:
has[color=darkred]
>
>
> TDS is not a native protocol to ASA.
it means nothing if server supports it.
> On top of that, it is not an efficient protocol.
on the top of that , the protocol itself it's only pure
theory.
implementation gives final results and tests are
criterion for it.
> The ASA/PHP module uses
> dblib directly (it is an embedded SQL client to the
> database), and dblib is one of the two native interfaces
> that ASA supports (the other is ODBC, dbodbc).
yeap, it's next step what i'm going to test. php module
uses
asa interface...
>
> Do you have some type of load test showing that FreeTDS
> can handle a better load than does php_sqlanywhere ?
sure. it's siege ;)
>If so, we'd love to have details about it (or get a
copy??)
> so we can address your concerns.
smth like siege -c 200 -r 10 -i
it's very easy to obtain results. my testing environment
is:
2 pc, one is for asa 9.02, one is for
apache(1.3.34/2.0.55) +php(4.1.1/5.1.2)
+asa
php(1.0.8)/freeTDS(0.63)/OpenClient ASE 11.9.2
linux (kernels 2.4/2.6 glibc 2.3.2/2.3.4/2.3.5)
4GB RAM, asa 1.5GB cache, 15 GB database, 10GB free space
on
hard disk.
php file for test contains several selects, isolation
level: dirty read.
asa php extension has problem with pconnect,semaphores
leak (may be it's
inherited from asa interface) . it possible to build it
with mpm worker
and perchild but apache even can't start with it.
i've tested asa 9.0.2+apache1.3.34+asa php 1.0.8+
application in c++(uses asa
interface) on one pc.
if system is under workload trough apache, number of
semaphore's
arrays(produced by apache), are growing.
when it reaches value near 200 asa sql server stops to
respond. if apache is
restarted it works for some period of time and stuck
again.
php file for test and c++ application contain several
selects, isolation level: dirty read.
sysctl -a
...
kernel.sem = 50000 32000 1024 1024
...
when i've used freetds/openclient and mysql i didn't see
anything similar.
| |
| Greg Fenton 2006-01-23, 3:23 am |
| Alex wrote:
>
> it means nothing if server supports it.
>
>
> on the top of that , the protocol itself it's only pure
> theory.
> implementation gives final results and tests are
> criterion for it.
No, that is not at all correct. For example, the TDS protocol is *only*
a TCP/IP protocol, whereas the native ASA protocols allow for both
TCP/IP and shmem for communication...network communication to a local
server is going to perform slower than shmem communication (though on
Linux this difference is small).
There are other things about the TDS protocol that does not allow for
efficiency. For example, it does not offer support for the full set of
cursors (both client and server side) that the other ASA protocols support.
>
> sure. it's siege ;)
>
It is not the test harness we would need (I use siege from time to
time), it is the PHP app and associated database schema/test data.
> asa php extension has problem with pconnect,semaphores
> leak (may be it's inherited from asa interface) . it possible to build it
> with mpm worker and perchild but apache even can't start with it.
This could be an issue with the way in which you built the PHP module,
though I wouldn't be too surprised if there are issues with the module
itself...this is why we would like to get feedback on what precisely you
are doing. We cannot simply go to engineering and say "we think
something is slow"...we need to provide a reproducible example so they
know what in partiuclar needs addressing.
> if system is under workload trough apache, number of
> semaphore's arrays(produced by apache), are growing.
The ASA native interfaces communicate via shared memory (shmem) by
default. This mechanism uses semaphores.
See Q#9 at:
http://www.ianywhere.com/developer/...l#UsingDBengine
You likely need to increase the number of semaphores available on your
system.
>
> when i've used freetds/openclient and mysql i didn't see
> anything similar.
It is likely that these mechanisms do not use semaphores (or at least
not in the same way). This is simply a matter of configuring your
operationg system to match the resource requirements of the applications
you have. For example, as the above URL indicates, you will need to
have a few more semaphores than the total number of apache threads that
will be creating connections to the database.
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
| |
|
| > Alex wrote:
>
> No, that is not at all correct. For example, the TDS
> protocol is *only* a TCP/IP protocol, whereas the native
> ASA protocols allow for both TCP/IP and shmem for
> communication...network communication to a local server
> is going to perform slower than shmem communication
> (though on Linux this difference is small).
as i said it's only theory. tests show: asa shmem
realization in php
slower then TDS.
>
> There are other things about the TDS protocol that does
> not allow for efficiency. For example, it does not offer
> support for the full set of cursors (both client and
> server side) that the other ASA protocols support.
yeap, i've read it. but are this features used in php
extension?
>
>
>
> It is not the test harness we would need (I use siege from
> time to time), it is the PHP app and associated database
> schema/test data.
ok, tell me what is right test for asa php extension?
i gave you my environment, same db,same apache, same php
and only asa php/tds is changed.
>
> perchild but apache even can't start with it.
>
> This could be an issue with the way in which you built the
> PHP module, though I wouldn't be too surprised if there
> are issues with the module itself...this is why we would
> like to get feedback on what precisely you are doing. We
> cannot simply go to engineering and say "we think
> something is slow"...we need to provide a reproducible
> example so they know what in partiuclar needs addressing.
i've told time by time about my problems with php
extension
on this forum and got no suitable advice.
pls don't think i've started to make tests from boredom.
i've got problems on one of my production box.
...and i guess it's enough info to perform tests.
>
>
> The ASA native interfaces communicate via shared memory
> (shmem) by default. This mechanism uses semaphores.
>
> See Q#9 at:
>
>
http://www.ianywhere.com/developer/...l#UsingDBengine
i've read it long time ago ;)
>
> You likely need to increase the number of semaphores
> available on your system.
sure, i played with it without success.
btw, there is no hint how many semaphores array and
semaphores itself
should be setup in kernel. in previous letter i wrote
suitable
values, otherwise application fills array from the start.
btw, even if i define only tcp/ip communication in php
code,
php extension continues to use shmem. why?
| |
| Mohammed Abouzour 2006-01-26, 4:56 pm |
| Alex,
When you configure the Linux kernel semaphore set parameters you need to
keep in mind the following factors:
1) The type of connections that you are doing with php (pconnects or
regular connects.
2) The maximum number of apache server processes or the maximum
concurrent number of connections that will be active at any one time.
In your message below you indicate that the ASA Server is running on
it's own machine and that the apache server (and PHP) are running on a
different machine. This means that the ASA PHP driver is connecting via
TCP/IP to the ASA server and not through shared memory. You need to make
sure that the kernel parameters are set properly on the apache machine
(not the ASA machine). Is this the case?
You posted your sysctl -a |grep kernel.sem output to
be the following:
> kernel.sem = 50000 32000 1024 1024
The two numbers that we are of interest to us are 50000 and 1024.
50000 or SEMMSL: is the maximum number of semaphores per semaphore set
1024 or SEMMNI: is the maximum number of semaphore sets
If you are using apache 1.x, you need to make sure that the
MaxSpareServers parameter does not exceed the SEMMNI value. Each
connection (in a single threaded application) will consume one semaphore
set (i.e. one SEMMNI value). The only time the SEMMSL value is useful
is in multi-threaded applications that create multiple connections. Your
SEMMSL value is too high and likely wastes valuable kernel memory, the
default value of 250 should be sufficient.
Apache 1.x is a single threaded application therefore it will be
consuming SEMMNI values and not SEMMSL values.
--
Mohammed
Alex wrote:
> has
> it means nothing if server supports it.
> on the top of that , the protocol itself it's only pure
> theory.
> implementation gives final results and tests are
> criterion for it.
>
> yeap, it's next step what i'm going to test. php module
> uses
> asa interface...
>
>
> sure. it's siege ;)
>
> copy??)
>
> smth like siege -c 200 -r 10 -i
>
>
> it's very easy to obtain results. my testing environment
> is:
> 2 pc, one is for asa 9.02, one is for
> apache(1.3.34/2.0.55) +php(4.1.1/5.1.2)
> +asa
> php(1.0.8)/freeTDS(0.63)/OpenClient ASE 11.9.2
>
> linux (kernels 2.4/2.6 glibc 2.3.2/2.3.4/2.3.5)
> 4GB RAM, asa 1.5GB cache, 15 GB database, 10GB free space
> on
> hard disk.
>
> php file for test contains several selects, isolation
> level: dirty read.
>
> asa php extension has problem with pconnect,semaphores
> leak (may be it's
> inherited from asa interface) . it possible to build it
> with mpm worker
> and perchild but apache even can't start with it.
>
>
> i've tested asa 9.0.2+apache1.3.34+asa php 1.0.8+
> application in c++(uses asa
> interface) on one pc.
> if system is under workload trough apache, number of
> semaphore's
> arrays(produced by apache), are growing.
> when it reaches value near 200 asa sql server stops to
> respond. if apache is
> restarted it works for some period of time and stuck
> again.
>
> php file for test and c++ application contain several
> selects, isolation level: dirty read.
>
>
> sysctl -a
> ...
> kernel.sem = 50000 32000 1024 1024
> ...
>
> when i've used freetds/openclient and mysql i didn't see
> anything similar.
| |
|
| Hello ,
> Alex,
>
> When you configure the Linux kernel semaphore set
> parameters you need to keep in mind the following
> factors: 1) The type of connections that you are doing
> with php (pconnects or regular connects.
> 2) The maximum number of apache server processes or the
> maximum concurrent number of connections that will be
> active at any one time.
>
> In your message below you indicate that the ASA Server is
> running on it's own machine and that the apache server
> (and PHP) are running on a different machine. This means
> that the ASA PHP driver is connecting via TCP/IP to the
> ASA server and not through shared memory. You need to make
> sure that the kernel parameters are set properly on the
> apache machine (not the ASA machine). Is this the case?
sorry if my post was not clear.
i wrote, if i have sql server, c++ application(with asa
interfase) and
apache/php on ONE pc i get problem.
this cocktail is not stable concerning shmem.
if i test 2 pc, sure, it's no shmem communication in
this schema.
but could you advice, why if i defined tcp/ic
communication in connect,
asa php extension starts shmem?
i guess it's inherited from dblib.
>
> You posted your sysctl -a |grep kernel.sem output to
> be the following:
> The two numbers that we are of interest to us are 50000
> and 1024. 50000 or SEMMSL: is the maximum number of
> semaphores per semaphore set 1024 or SEMMNI: is the
> maximum number of semaphore sets
>
> If you are using apache 1.x, you need to make sure that
> the MaxSpareServers parameter does not exceed the SEMMNI
> value.
it is.
> Each connection (in a single threaded application)
> will consume one semaphore set (i.e. one SEMMNI value).
> The only time the SEMMSL value is useful is in
> multi-threaded applications that create multiple
> connections. Your SEMMSL value is too high and likely
> wastes valuable kernel memory, the default value of 250
> should be sufficient.
250 is defult value in kernel and if i use it
apaсhe/php fills up whole
semaphore array on start.
kernel.sem = 250 32000 32 128
ipcs
------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 688129 www-data 777 250
.....
for
kernel.sem = 50000 32000 1024 1024
i have
------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 593002531 www-data 777 1
.....
this is for apache without asa php but with ssl_mod that
uses shmem
kernel.sem = 250 32000 32 128
------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 98304 www-data 777 1
can you explain why is it?
anyway, 50 000 works better but it's not stable too.
[color=darkred]
>
> apache 1.x is a single threaded application therefore it
> will be consuming SEMMNI values and not SEMMSL values.
>
>
> --
> Mohammed
>
> Alex wrote:
> interfaces >> that ASA supports (the other is ODBC,
| |
| Mohammed Abouzour 2006-01-27, 9:23 am |
|
Alex wrote:
> but could you advice, why if i defined tcp/ic
> communication in connect,
> asa php extension starts shmem?
>
> i guess it's inherited from dblib.
The php driver uses dblib internally. Sys V semaphores are used weather
you will be using shmem or TCP/IP.
> 250 is defult value in kernel and if i use it
> apaсhe/php fills up whole
> semaphore array on start.
>
> kernel.sem = 250 32000 32 128
>
> ipcs
> ------ Semaphore Arrays --------
> key semid owner perms nsems
> 0x00000000 688129 www-data 777 250
Before explaining how we allocate semaphores, you need to first
understand what the kernel numbers mean. The four numbers that configure
the Sys V semaphores on the system are as follows:
SEMMSL - The maximum number of semaphores in a semaphore set
SEMMNS - The maximum number of semaphores in the system
SEMOPM - The maximum number of operations in a single smeop call
SEMMNI - The maximum number of semaphore sets
In your example above, SEMMSL=250, SEMMNS=32000, SEMOPM=32, and SEMMNI=128.
These numbers mean that you can have at most 128 (SEMNI) semaphore sets
in the system and *each* semaphore set containing 250 (SEMMSL)
semaphores. When you configure you kernel you need to always make sure
that the following rule holds:
SEMMSL * SEMMNI = SEMMNS
250 * 128 = 32000
Now, when we try to allocate a semaphore set we try to use all the
semaphores in that set. Keep in mind that when we allocate all the
semaphores in a set we are *not* allocating all of the semaphores on the
system, but we are allocating all the semaphores possible for that set
only. With SEMMNI = 128, you can have at most 128 concurrent clients.
> for
> kernel.sem = 50000 32000 1024 1024
>
> i have
>
> ------ Semaphore Arrays --------
> key semid owner perms nsems
> 0x00000000 593002531 www-data 777 1
These parameters are not correct because they violate the rule
SEMMSL * SEMMNI = SEMMNS.
When ASA starts, it tries to allocate 1 semaphore set with 50,000
semaphores, but this fails (because your SEMMNS is only 32000). We fall
back to only allocating 1 semaphore in the array; hence, in your output
nsems = 1.
> this is for apache without asa php but with ssl_mod that
> uses shmem
>
> kernel.sem = 250 32000 32 128
>
> ------ Semaphore Arrays --------
> key semid owner perms nsems
> 0x00000000 98304 www-data 777 1
>
> can you explain why is it?
>
With kernel.sem= 250 32000 32 128, you will be only allowing 128 clients
to concurrently connect, and not 250 as you think. I don't really know
why we would allocate nsem=1 in this case though? Are you sure you have
the correct output?
>
> anyway, 50 000 works better but it's not stable too.
If you want to allow 250 clients to concurrently connect, I would
recommend something like the following:
kernel.sem=128 64000 32 500
These parameters will allow you to allocate 500 semaphore sets each with
128 semaphores. This should allow up to 500 concurrent connection. Can
you please try it and let us know if that works for you?
--
Mohammed
| |
|
| >Now, when we try to allocate a semaphore set we try to use
all the
>semaphores in that set.
yeap, i see. just for info , why is it necessary to use all
semaphores in array?
>Keep in mind that when we allocate all the
>semaphores in a set we are *not* allocating all of the
semaphores on the
>system,
sure
>but we are allocating all the semaphores possible for that
set
>only. With SEMMNI = 128, you can have at most 128
concurrent clients.
nsems[color=darkred]
[color=darkred]
>These parameters are not correct because they violate the
rule
>SEMMSL * SEMMNI = SEMMNS.
it's no correct.
SEMMNS -or- (SEMMSL * SEMMNI)
kernel:
sem.h
#define SEMMNI 128 /* <= IPCMNI max # of
semaphore identifiers */
#define SEMMSL 250 /* <= 8 000 max num of
semaphores per id */
#define SEMMNS (SEMMNI*SEMMSL) /* <= INT_MAX max # of
semaphores in system */
default values.
sem.c
i found only one condition for semmns
function newary
if (used_sems + nsems > sc_semmns)
return -ENOSPC;
i guess, (SEMMSL * SEMMNI) is not mandatory condition. am i
wrong?
>When ASA starts, it tries to allocate 1 semaphore set with
50,000
>semaphores, but this fails (because your SEMMNS is only
32000). We fall
>back to only allocating 1 semaphore in the array; hence, in
your output
>nsems = 1.
as far as asa continue to work it's non-fatal error.
otherwise
asa should log error at least, shouldn't it?
as for me, it's strange behavior. attempt to use all
semaphores and if it
fails be content oneself with just 1. thus, how many
semaphores is it
necessary for normal asa work?
>With kernel.sem= 250 32000 32 128, you will be only
allowing 128 clients
>to concurrently connect, and not 250 as you think.
i never told it.
>I don't really know why we would allocate nsem=1 in this
case though?
>Are you sure you have the correct output?
yeap, moreover, fresh output
100 concurrent users, apache 1.3.34, asa php.
kernel.sem = 250 32000 32 128
0x00000000 1352957987 www-data 600 1
....
0x00000000 1352969731 www-data 600 250
[color=darkred]
>If you want to allow 250 clients to concurrently connect, I
would
>recommend something like the following:
>kernel.sem=128 64000 32 500
>These parameters will allow you to allocate 500 semaphore
sets each with
>128 semaphores. This should allow up to 500 concurrent
connection. Can
>you please try it and let us know if that works for you?
i've tested default values for shmem and 100 concurrent
users.
it's not stable on condition what i wrote. sorry, i have no
time
for tests more.
|
|
|
|
|