[php] Dynamisch laden (sablotron) library *

[creative8500]

De laatste weken heb ik een site ontwikkeld, gebruikmakend van XML en XSL. Omdat alleen de laatste browsers XSL ondersteunen wilde ik het serverside parsen. Geen probleem op mijn localhost, maar de server van mijn hostingprovider zijn DOM XML en Sablotron niet geïnstalleerd.

Op het moment draait de site op een server met een "450 MHz AMD-K6®-2 processor" maar vanaf vandaag worden nieuwe servers met een 1GHz pentium 3 geïnstalleerd. Ik dus vragen of bij die installatie ook DOM XML en Sablotron geïnstalleerd kunnen worden. XML-support lijkt me bij nieuwe server eigenlijk net zo logisch als MySQL-support.

Maarnee: het kost teveel performance:

Deze software kunnen wij niet installeren. Het is ballast voor de server. Als er veel vraag naar was dan zouden we het wel kunnen installeren. Het is prima als je geen serverwide version van Sablotron kunt vinden, die kan wel geïnstalleerd worden. Op de link die jij gaf zie ik alleen serverwide toepassingen. Stel je eens voor hoe vol het op de server wordt als we alle softwareverzoeken zouden inwilligen!

Ik dacht dus aan een andere opzet: de extension niet automagisch laten laden, maar wel op de server zetten, zodat ik het volgende script kan gebruiken:

PHP:

if (!extension_loaded ("sablotron")) dl ("php_sablot.so");

Maar ook dát was niet goed. Zo'n extra extension zou wel mogen, maar dan alleen wanneer hij vanuit mijn eigen root geladen werd. (Lijkt me uiterst onveilig, magoed)

Nu wil ik weten: hoeveel performance scheelt dat nou werkelijk, als je op een P3-1Ghz server een extension extra load? En in de situatie dat ik hem bij elk script handmatig aanroep? Of wie heeft een andere oplossing?

PS: nu geïnstalleerd: xml. standard, session, posix, pcre, mysql, mbstring, ldap, imap, gettext, gd, ftp, dba, db, zlib en apache. Bij de nieuwe server weet ik het nog niet.

edit:
Specs van de nieuwe server: * klik *

[ Voor 5% gewijzigd door creative8500 op 18-08-2003 13:47 ]

[rig0r]

Ze bedoelen neem ik aan de belasting van het parsen van XML en/of XSL parsen. Dat kost idd wat extra cpu tijd, maar op mijn 1Ghz Athlon Thunderbird servertje is het verschil eigenlijk nauwelijks merkbaar. Hangt natuurlijk wel van het aantal bezoekers van je site af. Hoe druk gaat je site naar schatting bezocht worden ? En wat parse je precies ? Wordt er voor elke klik iets geparsed ?

[ Voor 10% gewijzigd door rig0r op 18-08-2003 14:08 ]

[Gert]

Switch gewoon van hoster. Als het een officeel component is dan zal een beetje hoster het wil willen installeren, mits het voor hen gratis is.

[djluc]

Misschien kun je gaan dreigen dat je anders een of andere php template parser met slechte performance gaat gebruiken?

[Soultaker]

Ik ben het met de hoster eens, voor zover ik een goed beeld van de situatie heb. Zij bieden een bepaald pakket aan dat op een gedeelde webserver wordt gerealiseerd. Het is logisch dat ze dan niet met ieder's wensen rekening kunnen houden en tegelijkertijd de betrouwbaarheid en onderhoudbaarheid van hun server kunnen garanderen. Ze bieden jou een bepaald product aan, met bepaalde specificaties, en hoewel je natuurlijk altijd om bepaalde extra diensten kunt vragen, is het begrijpelijk dat ze die niet altijd kunnen leveren. Dan moet je een ander product aanschaffen.

Ik vind de suggesties om dan te "dreigen" met overstappen of de hosting provider te chanteren door processorintensieve software te gaan draaien een beetje onbeleefd, vooral omdat het ze helemaal niet om het gebruik van de server gaat: "Het is prima als je geen serverwide version van Sablotron kunt vinden, die kan wel geïnstalleerd worden." Het gaat ze er dus uitsluitend om dat ze de boel niet op de hele server beschikbaar willen maken (omdat ze zich dan verplichten tot het beheren van het pakket, door middel van regelmatige upgrades en het monitoren van security issues). Voor jou alleen willen ze het dus wel installeren.

Om maar tot een concreet punt te komen, ik snap niet wat je probleem nu is. Ik ken het softwarepakket verder niet, maar ik neem aan dat als je 'm van source build, je gewoon de prefix (of "root", zoals jij het noemt) kunt aangeven, zodat je 'm dus ook in je homedirectory kan installeren. Dan kun je 'm ook zonder problemen laden met dl() in PHP; uit je quotes kan ik niet opmaken dat je hosting provider daar niet accoord mee zou zijn. Als je over een shell account en enige basale UNIX/Linux-kennis beschikt, kun je dat zo zelf regelen.

[creative8500]

rig0r schreef op 18 August 2003 @ 14:07:
Ze bedoelen neem ik aan de belasting van het parsen van XML en/of XSL parsen. Dat kost idd wat extra cpu tijd, maar op mijn 1Ghz Athlon Thunderbird servertje is het verschil eigenlijk nauwelijks merkbaar. Hangt natuurlijk wel van het aantal bezoekers van je site af. Hoe druk gaat je site naar schatting bezocht worden ? En wat parse je precies ? Wordt er voor elke klik iets geparsed ?

Ik denk niet dat ze parsetime bedoelen, want dan zouden ze "nonserverwide" (zoals zij dat noemen) ook niet willen toestaan.
En die site heeft niet zo mega-veel bezoekers. Overigens: ik heb vier, binnenkort vijf klanten bij ze gehost. Zou dat genoeg gewicht in de schaal leggen? I hope so.

@ Gert: het is volledig gratis, en ik ben voorlopig nog niet van plan om een andere hoster te zoeken, tenzij ze echt niet te overtuigen blijken.

Omdat jullie allemaal alleen over parstime beginnen: wat voor perfomance kost het dan eigenlijk, je zo'n extension laad? Alleen geheugen? Of is het praktisch gezien bullshit dat het performance kost als je het installeert op een shared server waar maar 5% deze extension gebruikt?

@ djluc: die tip kan ik niet serieus nemen, aangezien zo'n onderhandelmethode al je krediet verspeelt. Bovendien getuigt het van erg slechte manieren.

[creative8500]

@ Soultaker: omdat ik niet bekend ben met linux, het volgende. Op de site van Sablotron lees ik dat je voor Sablotron-support in PHP, PHP moet compilen met bepaalde opties. Dat zal dan waarschijnlijk serverwide betekenen. Nu ben ik even gaan neuzen op mijn server, kom ik het volgende tegen:

/etc/httpd/php.ini
extension_dir = /usr/lib/apache/php

Ik dus daarnaartoe. Zie ik daar de volgende betanden staan: interbase.so en pgsql.so. Hierop schreef ik het volgende script:

PHP:

if (!extension_loaded('interbase'))
{
    if(dl ('interbase.so')) echo "Interbase: module loaded";
    else echo "Interbase: no go ...";
}

Maar ik krijg helaas de volgende melding:

Warning: U‰åƒìSè: Unable to initialize module Module compiled with debug=32, thread-safety=144 module API=1080755072 PHP compiled with debug=0, thread-safety=0 module API=20010901 These options need to match in /home/sites/site16/users/creative8500/web/load.php on line 5
Interbase: no go ...

Zoals ik zei: ik ben niet met Linux, en (dus) nauwelijks met compilen bekend. Is het mogelijk om Sablotron te compilen met de goeie opties, in die directory, waarop ik hem wel kan laden met dl()?

Dan kun je 'm ook zonder problemen laden met dl() in PHP

Naar ik weet kun je met dl() alleen extensions laden uit de in php.ini ingestelde extension-dir.

Edit: maar nog even ter verduidelijking; ik wil ook nog weten wat nou het performanceverschil is voor en ná het laden van een extra php-extension.

[ Voor 8% gewijzigd door creative8500 op 18-08-2003 15:35 ]

[Soultaker]

creative8500 schreef op 18 August 2003 @ 15:18:
Zoals ik zei: ik ben niet met Linux, en (dus) nauwelijks met compilen bekend. Is het mogelijk om Sablotron te compilen met de goeie opties, in die directory, waarop ik hem wel kan laden met dl()?

Naar ik weet kun je met dl() alleen extensions laden uit de in php.ini ingestelde extension-dir.

Ik vermoedde dat je ook wel een volledig pad zou kunnen geven, maar in de manual zie ik dat je gelijk hebt. Dat is wel weer jammer, natuurlijk; misschien is je hosting provider nog wel bereid een link te maken naar het bestand in je home directory (tenzij ze dat om beveiligingsredenen niet vertrouwen). Zoniet, dan houdt het eigenlijk op (of je moet een hele PHP distributie in je homedirectory willen installeren waar je via CGI van gebruik maakt).

omdat ik niet bekend ben met linux, het volgende. Op de site van Sablotron lees ik dat je voor Sablotron-support in PHP, PHP moet compilen met bepaalde opties. Dat zal dan waarschijnlijk serverwide betekenen.

Ik ken verder Sablotron niet echt, maar in ieder geval staat de installatie daarvan los van die van de bijbehorende PHP extentie. Je moet dus sowieso Sablotron ergens installeren (ergens in je eigen homedirectory, in dit geval), om de extentie te kunnen gebruiken. Dat doe je bijvoorbeeld op de volgende manier:

Bash:

./configure --prefix=~/sablotron
make
make install

Verder moet je dan de PHP extentie compileren, zodat PHP gebruik kan maken van jouw versie van Sablotron. In theorie zou je zo'n extentie ook los moeten kunnen compileren, dacht ik (en dan dus ook los laden), maar ik zou eerlijk gezegd niet exact weten hoe dat gaat. Een makkelijke (nogal lompe) alternatieve werkwijze, aangenomen dat je een shellaccount op de server hebt, is om domweg dezelfde PHP distributie te downloaden als nu al op de server draait en opnieuw te configureren met de gewenste opties (plus de opties die je hosting provider gebruikt, dus in ieder geval de XSLT extentie: "--enable-xslt --with-xslt-sablot=~/sablotron") en de boel opnieuw te compileren. Als het goed is krijg je dan gewoon een dynamische library die compatible is met de versie die op de server draait; de library is namelijk niet afhankelijk van binary compatiblity met de geinstalleerde versie van PHP, maar moet wel dezelfde interfaces gebruiken.

Als het meezit kun je trouwens na het configureren van de PHP source distributie naar de ext/xslt directory gaan en alleen die extentie builden; dat scheelt een hoop tijd (en ruimte). Ik kan echter niet garanderen dat dat goed werkt.

[ Voor 6% gewijzigd door Soultaker op 18-08-2003 15:48 ]

[mbravenboer]

Bash:

./configure --prefix=~/sablotron
make
make install

kleine correctie op de uitgebreide uitleg:

code:

[mbravenb@porkpie tiger]$ ./configure --prefix=~/bla
configure: error: expected an absolute directory name for --prefix: ~/bla

Je moet dus even een volledig path opgeven of de HOME omgevings variabele gebruiken.

[drm]

Configuratie problemen horen in SA :)

Overigens ook je topictitel even aangepast.